漫画ビューア総合スレ Part2

漫画ビューア総合スレです

前スレ
漫画ビューア総合スレ (Part1)
https://egg.5ch.io/test/read.cgi/software/1752914772/

話題多め
画像ビューアー NeeView Part7　【ﾜｯﾁｮｲあり】
https://egg.5ch.io/test/read.cgi/software/1781159107/
https://github.com/neelabo/NeeView/

漫画用画像ビューア マンガミーヤ MangaMeeya 24
https://egg.5ch.io/test/read.cgi/software/1742548602/

【画像/漫画/動画ビューア】mImageViewer 1【mIV】
https://egg.5ch.io/test/read.cgi/software/1782419551/
https://www.mikage.to/mimageviewer/

前スレリンクから
https://github.com/julyx10/lap/
https://github.com/SoraKumo001/quick-image-viewer/
https://github.com/kirinonakar/Uviewer
https://github.com/ggand0/viewskater
https://github.com/p-almighty/Piewer
https://github.com/yasuflatland-lf/gashuu
https://github.com/nalltama/RAIV
https://womanprojects.web.fc2.com/

俺20/40ページ移動で実装することにした
固定方が簡単だし、バグ避けにもなるからね

>>110
ばかたれ、利用者(読み手)の利便性を考えろw
https://egg.5ch.io/test/read.cgi/software/1752914772/756

それはさておき、厳密な計算とか必要ないでしょ
10%スキップして10%戻ったら元のページになれば良いだけ

いや割合移動は大雑把でも計算ないときついぞ？？
単純に画像の場合は割合/総数で計算すればいいだけかな
動画とかは再生時間で割ってるんだろうけどな

開発者ごっこがしたいおじいちゃんを介護するスレに改名してもろて

>>113
テキストエディタでの次の行、前の行移動でのカーソル移動と同じイメージ
設定割合x1, x2, x3 ....で改行があって「行頭」からのオフセットを維持して割合移動する

割合移動を連発している間はオフセット更新はしない、他の操作でページが変わったら
その「行」でのオフセット値に更新する

オフセットは見開きの場合とか考えずに画像の数にする
(この部分が近似、アーカイブ内は整理されていて主に見開き結合済みか主に分離かが偏っている、と仮定)

>>115
通常のページめくり閲覧やユーザー操作での単ページシフトなどで
最初の決め打ち「設定割合x1, x2, x3 ....」が見開きを分断している事が判明したら「改行」ポイントは修正する
可能なら閲覧履歴情報に修正値も記録しておけば2度目以降は最初から正確になっている

>>108
縦につなげて表示したらスクロールできない？
mIVはその動作だし、NeeViewもマウスホイールスクロールを使用するにすればホイールでスクロールできる

>>117
1ページはそのページだけで上下させたいんよ
まぁそういう設定がないって事は自分の使い方が特殊なんだろうね

>>118
特殊もなにも、どのビューアも...、と言う事は
それが使い易いかは自分でも分かってないのでは

IrfanViewにあった記憶
縦に並べてスクロールするんだと画像下端がスクリーン下端に到達してから次ページの画像上端がスクリーン上端に移動する距離が邪魔だから
あったらあったで便利に使う人もいるでしょうな

>>68,72
> FHD画像ページめくりが何fps出るのかの実測も欲しかった

suzuna約30-31fps、NeeViewも約30-31fpsだった
調べたらシステム設定でキー入力のリピートが最大で31Hzになっていてこれでキャップされていると思う

キーを離していないという状態をアプリ側で判断して最速を出している訳ではなさそう

画像の表示はどのソフトも十分速くない？
PDFはソフトによる差が大きいように思う。ロード中にするか待たせるかとか
普通にページめくって読む分には気にならないけどね

動画とかなら割合移動欲しいとは思うけど画像で欲しい人いるんだなｗ
tubeのやつを使ってみたけどかなり使いやすくてそこだけはさすがYouTubeだなとはおもったｗ

ユーザーペインの肝要な部分を聞き取るより先に
プログラミング的な落とし込みに会話が進みがち

>>122
> 画像の表示はどのソフトも十分速くない？
十分の捉え方次第だね
レジストリいじって125Hzリピートにして4K60Hz画面で

miv(egui)/viewskater(egui)は平均50-52fps止まり
gashuu(slint)は平均60fps出る

他高速なneeview/suzunia/qview/quickviewer/slapは平均60fps出る

番外
massigra 21fps
RustMangaReader 15fps

失格
uviewer キーリピートでページ移動しない

>>125
https://github.com/ggand0/viewskater-egui
FPSオーバーレイがあって瞬間的に55-56fpsは出ているけど
今回の計測は555枚の画像でのタイムから平均を取った

>>126続き
キーリピートをレジストリで125Hz(8ms間隔)に設定してもwin32k.sysの制限でリピート生成は64Hz(15.625ms)になるそうなので
125Hzでキー送信するアプリを用意して計測し直した
画面の60Hz以上なので1フレームタイムで2回描画していることになるけど(Lap以外は)見た目はスムーズ

gashuu/neeview/qview 114fps
quickviewer 113fps
(lap 110fps ただしカクカク)
suzunia 102fps

114fps=(555-1)/4.85の様に0.05s精度でキー送信時間を設定して
554回のページ移動が完了する秒数を見つけて計算した
lapはカクカクだけど最終ページに飛ぶことは飛ぶのでその時間で計算した参考値

>>125
mIVのスレで作者がページ送り引っかかる事があるんで直すって言ってるな

キー入力
fps
描画枚数
体感
統一基準を出してもらわないと判断できないです
1枚1枚表示しているか確認したのですか？
高速ページ移動で描画スキップさせるのは体感向上のテクニックでしょうし
そもそも今どきFHD程度で遅いとか速いとか重要なのかな

画像の高速切替は光過敏性発作を引き起こす可能性があるから
画像・映像を扱うアプリ開発者は気をつけような

>>128 楽しみです

>>129
本当に描画をしているのかを調べるのは凄く大変だと分かった
RTSSでfpsが取れるかやって見たらeguiは数値が出るけどegui自体がオーバードローしてない
SlintとWPFはPresentMonで取れたけどAIが言うにはWPFが内部で合算してPresentしているので
オーバードローしていてもそのfpsは分からないと、Slintは何のAPIがさえ分からない(PresentRuntime=Other)
Qt系とsuzunaはGDI描画らしくPresentMonでデータが取れなくてAPIをフックすると言われて放棄した

という事で何を基準にするのが正確かを考え直すと

新基準
1. (ページ送り)キー処理に漏れがなく (554回送信で最終ページに到達する)
2. 描画は一部スキップしても良いけど全スキップや明らかに引っかかりや止まるのはダメ
(体感向上のテクニックとして見た目20-30fps位に落ちていても良しとする)

この基準内でキー送信出来る上限レートを探る事にする

そこで>>127の数値を振り返ると125Hzで送っている設定なのに114fpsと計算値が出るのは変だなと思い調べたら、キー送信するアプリ側のスリープ処理が単純過ぎてGUI更新のせいで125Hzで送信出来てない事が判明したので手直し中

自分が納得するまで試してから数字は出すけどneeviewやsuzuniaは凄い数値が出そう

FHD画像でやっているのは良くあるCPUペンチと同じ考え方、表示は4Kにしている

>>131
やっとキー送信アプリ側の手直しと検証アプリが出来た
https://i.imgur.com/Ses7cD5.png

>>132
右側がキー送信アプリで2000~2200Hz位までは正確に遅れる
左側が検証アプリで1900Hz位までは遅延なく受け取れて2000~2200Hzはわずかに遅延するけど受け取り漏れは無い(つまり送信アプリでのキー送信漏れも無い)

>>131
suzunia 1400 Hz
このレベルでは554回ページ送りが一瞬ではあるのの
1500Hzではカクツキが目立ち始め2000Hzでは全スキップで最終ページに飛んだ

>>127の後に20260813にアップデートした時に設定を弄ってしまった
たぶん変えた場所は今回はアンシャープマスクOFF、性能プリセット高スペック

>>131
neeview 260 Hz
270 Hzでは成功したりページ送り処理漏れが発生することがあり不確実だった

>>131
qview 70 Hz
確実なページ送りではキー送信レートここまで落ちた(検証5回)
114 Hzでも一見したところはスムーズにページ送り出来ていたが
ページ送り処理漏れが1~2個発生することが多い

>>131
gashuu 200 Hz
フルスクリーンがなさそうなので最大化で代用した
もっと送信レートを上げて2000 Hzでも処理漏れは無いけどグルグルマークが出たり全スキップになったりして体感が良くなかった

>>131
quickviewer 80 Hz
qviewと同じく処理漏れが発生しやすい
今回は80Hzで5回連続成功した(正直これで確実かどうかまでは分からない)

>>131
Lap 5 Hz未満
5 Hz程度でもページ送り処理漏れが1~2個発生する
30 Hz程度までは3個程度処理漏れ
60 Hz程度は一見スムーズだけど10個程度処理漏れする

>>131
viewskater-egui 40 Hz
45Hzで処理漏れが出た

>>131
mImageViewer 5 Hz未満
>>128の通り直すそうなので現バージョン(v2.13.0)での計測にそれほど意味はないけど
5 Hz程度でもページ送り処理漏れが1個発生する

>>131
おまけ
Massigra 21 Hz
2000Hzでも処理漏れはない、ただし描画スキップもないのでキー送信が終わった後にページ送りが続く

suzuniaの中の人です。さきほどスレの存在に気付きました。
上の方で触れられている「割合ページ移動」「ゴミ箱に入れるときも確認ダイアログを出す」は対応しました。

このアプリの売りである「速度」とは具体的に、起動速度や画像デコード速度、プリフェッチ範囲辺りが想定でした。
（オプションで「本の残り全ページをキャッシュ上限まで先読みし続ける」という設定がありますので、メモリに余裕があればon推奨です）

皆さんが気にされている？プリフェッチ済みページの切替速度は正直ノーマークでした。ので、この機会に手を入れました。

次の表示用画像まで裏で作り置きしてページ送りを転送だけにする改修で、手元の環境で4K表示、切替 6ms→2.4ms くらいまで削減しました。

連打向けには連打中だけ描画品質を落として高速化するオプション(既定オフ)も追加しました。

>>143
対応お疲れ様です。まず割合移動について、20に設定で5回で末尾移動と動作確認できました。
実装していただきありがとうございます。

現状での困った点としては下記があります。方針に沿うのであれば検討いただけると助かります。
・起動時のペンギン画像の非表示設定
　→カラーが派手なので単色にしたい

・ページスライダーの下部表示
　→タイトルバー下は使い辛く、また視認性も悪い。他ビューアと同様に目盛りありのスライダーでは駄目か

・プレイリストの実装
　→本棚(フォルダ管理)の不採用は同意する。
　しかし複数を連続して読みたい場合は、ミーヤでいうプレイリストがあると助かる。
　画面の圧迫については個々に広げればいいと思うが方針に合わないか

・(zipではなく)フォルダでも2ページ表示
　→フォルダをDDすると単ページとなり、表示の選択がグレーアウト
・D&Dでビューアをアクティブにする設定

使わないくせに手当たり次第いろんなソフトに大量に要望出して後でじっくり選ぼうとしてて草
同じやつだろこれ

>>143
使ってほしいならDLページにスクショ置くべき
あの1枚だけじゃ試してみるかって気にならない

DLページ開いてる時点でDLするでしょう
今は機能拡充に専念して欲しいわ

今のところはAlt+1などにキー割り当てしてもエラー音になるのが不満くらい

試しに起動はする
でも書庫なしはソフト側からこちらを足きりしてるからなあ

>>147
DLページつーか配布ページな
そんくらいわかるだろアスペかよ

>>149
自己紹介乙
DLページに画像や動画貼れるの知らなかった?

>>148
何もしなくても書庫内画像見れてるけど7zipにパスを通しているからかな

>>145
同じ事思った、>>144 = >>96だよね
ペンギン消せるのにろくに設定見ない人なんだと思う

>>143
最速ビューアおめでとうございます

>>131,132
キー処理漏れ発生と連射スピードに相関があるのかもしれないけど
根本は処理漏れが発生する時点でビューアのバグでしょう

俺の考え方、使い方こそ正義だ！みたいなやーつ

>>131
乙
検証したあなたも凄いけど
何百、何千fpsでキーを受け付けるソフトも凄いね

自作ファイラ+suzunia 8/5版でも自作ファイラ+Leeyesより起動が速くなって望む動作になったからこれでいいや
いままでありがとなkenji

suzuniaさんはタイトルバー隠した全画面表示だと最小化のオプションがないのが気になる
ちょっとしたときに裏行ったりするときに不便
win+Dは効いたがwin+Mは無効だったし

>>131
ページ送りは、処理自体の速度差はあるけど、間に合わなかったとき
キーの押した回数を優先して表示はせずにページを進めるのがよいか、
途中のページを表示して間に合わないキー入力をキャンセルするのか、
はどちらが正しいというわけでもなく、作りが違うのかも

デジカメ写真やPDFだと、NeeViewはファイル名とロード中だけでて
画像が出るまでは毎回待たされる
suzuniaはフル画質さっと表示されて速い
画像が画面に出るまでの時間で比べたらかなり差がでるんじゃないかな

win+Dで最小化しても他で作業しようとすると強制的にsuzuniaがフォーカスするのか
ブラウザとかは最大化したままwin+Dですべてのウインドウを最小化した場合は他のウインドウがフォーカスできるのに
開きなおしたら最大化したままで復帰もできる

・ペンギンは消せます。
・プレイリストに代表される「書庫の管理」系UIは、今のところ対応予定はありません。
将来的に実装予定はありますが、期待しているものとは異なるインターフェースになる可能性があります。

指摘頂いた以下の修正を行いました。ありがとうございます。
・「画像・フォルダでも2ページ表示にする」設定の追加
・「ドラッグ＆ドロップでウインドウをアクティブにする」設定の追加
・全画面表示時に最小化/最大化/閉じるボタンが消えるバグ
・操作割り当てで「ALT+通常キー」が効かないバグ
・ページスライダーが見にくい問題（通常のスライダーを用意する予定はありません）

私が求めているわけではありませんが通常のスライダーをつけないのは画像が縮小されるのが嫌だとかそういう理由なの？
開発ポリシーは支持したいけど参考までに理由は知りたいです

>>141
v3.0.0が出た
検証頼む

>>162
mImageViewer v3.0.0
特に変わらないと思う(設定が必要?)
AI関連は無しにしてキャッシュ系は最大値、ビューワモードは複数ウィンドウにしてます
これにするとメインウィンドウのサムネ表示との連動がないので

入力速度␣平均処理漏れ数(5回計測)
5 Hz␣1個
30 Hz␣1個
40 Hz␣2.6個
50 Hz␣8.2個
60 Hz␣19.7個
100 Hz␣228.2個
2000 Hz␣549.8個

低速度でも1個漏れるのは多分バグ
30Hz越えで漏れ数が増えるのは処理速度限界突破でしょうか(バグと呼ぶかは諸説あり)

>>163
mImageViewer作者です。詳しい検証ありがとうございます。

コードを確認しました。
mImageViewerは、キーを押しっぱなしにしたときのリピート入力を、
すべて回数として蓄積する作りにはしていません。

押しっぱなし中は、各ページを飛ばさず順番に見せつつ、
読み込み待ちで引っかからないよう、通過中はサムネイル画質で表示します。
キーを離すと、その時点で実際に表示していたページをフル画質へ切り替えます。

今回のツールが、キーを押したまま任意の間隔でリピート入力を送り、
最後の入力直後にキーを離す方式であれば、
最後のリピート入力とキーを離した情報が同時に処理されることがあります。

この場合、最後のリピート分まで進めると、キーを離した後に次のページへ
移動する動きになるため、その1回は実行しないようにしています。
低い頻度でも1回ほど差が出るのは、この動作による可能性が高そうです。

また、処理速度を超える入力についても、後からまとめて移動し続けないよう、
未処理のページ送りをキューへ溜め込まない設計です。
そのため、高い頻度では入力回数との差が大きくなります。

>>164
> キーを押しっぱなしにしたときのリピート入力を、
リピートだと64 Hzがシステム限界なので
キー送信アプリでは、SendInput APIで押す、離すをセットにして高速に呼び出してます

>>165
詳しい説明ありがとうございます。

毎回 SendInput で「押す→離す」を送っている方式であれば、
先ほど書いた「最後のリピートとキーを離した情報が同時に処理される」
という説明とは別の原因がありそうです。

高い頻度で差が増える点は現在のページ送りの仕組みで説明できますが、
5Hzで554回送った場合にも平均1回ほど欠ける点は、
こちらの通常のキー操作では再現できていません。

開始時のフォーカス切り替えか、どこか一度だけページの表示確定に
200ms以上かかっている可能性などは考えられますが、
現状の情報だけでは特定が難しそうです。

検証アプリを公開可能でしたら、こちらでも同じ条件で確認してみます。

>>166
確認よろしくお願いします

ダウンロード期限：2026年11月23日(月)
https://96.gigafile.nu/1123-b14d5d9d903ece99395b0aa05dbd6adb7

ソース一式の他、binフォルダにビルド済みexeとslint_cpp.dllを同梱しています
Slint SDK(含むdll)オリジナルはここにあります
https://github.com/slint-ui/slint/releases/download/v1.17.1/slint-compiler-Windows-AMD64.tar.gz

Key / Shortcutはボタンを押すと入力出来ますがCtrlなどのキー入力はバグっていて上手く行きません
フリー版AIが直してくれないので放置してますが直してもらえると嬉しいです

>>167
C++用のビルド済みSDKはこちらでした
https://github.com/slint-ui/slint/releases/download/v1.17.1/Slint-cpp-1.17.1-win64-MSVC-AMD64.exe

上記インストーラーexeが何所までやってくれるのか分かりませんが自分は手動で解凍して
cmake用の環境変数 Slint_DIR を 解凍先\lib\cmake\Slint に設定しました

そもそも意味あるベンチマークかもわからないのに速攻で作者飛びついてて草
落ち着けよ

そもそも1000hzとかで切り替えられて何なの？
高速でページ送りしたい時でも、10hzくらいあれば十分なんだが

>>66-67の流れで分かるんだけど、「.Netだと遅い/あるいは何かしらの問題がある」と信じている人が一定数いるんだよね

suzuniaがそうであるように、実際はそんなことないのに

suzuniaはネイティブアプリじゃないの?
設定アプリが.netアプリ
違った?

.net c#なら早いけどね
昔の.netで語る人が多いからね

Windows は Win32 API 直書き、macOS は AppKit 直書き。どちらも NativeAOT で、GUI フレームワーク (WPF / WinForms) を使いません

suzuniaのgithubとかいてある

NativeAOTって.Netのことだよ？
>Native AOT（Ahead-Of-Time）とは、.NET アプリケーションのビルド時に、中間言語（IL）からOS固有の機械語（ネイティブコード）へ完全にコンパイルする技術です。

どこかのアプリが「.Netのせいで起動が遅い」とか書いたのを鵜呑みにしてるのかな？

>>167
ツールとソースの公開ありがとうございます。
おかげで原因を特定できました。

A. 5Hz / 1秒 / Max Countなし
B. 5Hz / 1秒 / Max Count=5

で確認すると、どちらも5回キーを送信しますが、修正前のmIVは
Aでは5ページ、Bでは4ページ進みました。

Aでは5回目の送信後も次の周期まで約200ms待ってから、
キー送信ツールが自身のウィンドウを前面へ戻します。
Bでは5回目を送った直後に前面へ戻るため、mIVが最後の入力を
処理する時点ではフォーカスが外れていました。

mIVは、フレーム単位で描画するときに、それまでのキー入力を判断して
動作をするような作りになっています。
このキー入力判断時に、自身がフォアグラウンドでなければ処理をしない、
というロジックがありました。
この判定は、フルスクリーンを別ウィンドウで扱うようになった際に、
別ウィンドウでの入力誤処理を防ぐために追加したものでした。
その後のリファクタリングでキー処理全体の入口へ移され、今回の
入力まで処理しない状態になっていました。

これがBパターンのときに影響し、１回分の処理が減る原因となっていました。
キー入力時点の配送先を基準に処理するよう修正し、修正後はBでも5ページ
進むことを確認しました。次のリリースに反映します。

通常操作では見つけづらいタイミングのバグでしたので、
再現条件を絞った検証とソース公開、大変助かりました。
ありがとうございます。

なお、mIVは通過するページを1枚ずつ順番に表示する方針です。
表示速度を超える連打は、後から実行するために蓄積しないため、
レートを上げると押した回数より進むページ数は少なくなります。

ただし、表示されるページの順序自体は飛びません。
1ページ目から100ページ目まで進める入力をした場合、
100ページ目へ届かないことはあっても、途中のページを飛ばして進むことはありません。
こちらは意図した動作です。

動作検証には影響しませんが、ツール側で1点だけ気づいたところがあります。
Max Count指定時のActual Rateは、最初の送信から最後の送信までを経過時間として
「送信回数÷経過時間」で計算しているようです。

N回の送信間隔はN-1区間なので、表示値がN/(N-1)倍になります。
例えばBでは設定5Hzに対して約6.24Hzと表示されます。

.netのNativeAOTは知ってるけど
c++で書いてもNativeでAhead of timeだし
どっちが正解かわからない
まぁ、作者答えてくれるやろ

>(本体に静的リンク) .NET ランタイム
MacOSばんだとこんなこと書いてあるし
正解は.netのNativeAOTかもね

今ならCsWin32辺りでWin32やら呼んでるのかな

てっきりC++とかで書いてるのかと思った

>>163
v3.1.0来たぞ

suzunia、「外部プログラム起動」機能が無いという指摘を見落としていたので追加しました。
その他いくつかのバグ修正や小さい機能追加を行っています。

さて。実はsuzuniaは「.NETは何故か遅いと勘違いされているから、最速の画像ビューアを.NETで作ろう」が立脚点になっています。
当然.NETで作られています。
このスレの反応を見ても分かりますが、この意図（.NETで最速の画像ビューアを作る）は達成されたと見て問題無いかと思います。
（機能不足に関する突っ込みも多いですが当然の話で、機能を目的としたアプリではそもそもないから、なんですね。
　いま現在、いつの間にか多機能なアプリになってしまいましたが、これは単純に私が凝り性だからというだけで、言ってみればただの蛇足です）

>>67「.net 終了」なんかは自演じゃないかと自分で疑うくらいに狙い通りの反応ですし、
>>172「suzuniaはネイティブアプリじゃないの?」と、ネイティブ実装と勘違いする程度には高速であることも証明されました。
しかもこのレスは「.NETは遅い」という間違った思い込みがあるからこそ出てくる発言で、二重の意味で期待通りでした。

という感じで、まあアプリを使う側からしたらこんなどうでもいいことは考えずに、
Meeyaの代替としての一つの選択肢が出てきた、相性が合えば使い続ければいいし合わなければゴミ扱いする、で良いのではないでしょうか。

>>181
改めて最新をDLしてみたが操作にスクロールの設定がない
幅に合わせた場合にないと致命的でドラッグ移動出来るとはいえチャタリングでも起きたらページ移動しちゃう
付随してドラッグ終了→ページ移動した際にウインドウ位置が遷移する前の位置にとどまって本来後に読むべきコマを先に読まされることになる
ページ移動したらウインドウ位置のリセットを設定でONOFFさせてほしい

幅に合わせた場合WEB閲覧の様に縦読み型でもいいのかもね
確か前スレで誰か話題出してたし

このスレでsuzuniaの存在を初めて知りました。全ての動作が軽量で小気味いいです（NeeView比）
マウスジェスチャーがあれば完璧なのですが、実装は難しいでしょうか？

起動が重い（遅い）ってだけで8割方は.netかで終わってしまうからなぁ

>>176,177
お役に立てて良かったです、N/(N-1)倍の件見落としてました

>>180
試してないけど変更内容と仕様から判断して30Hzだと思う

じゃあ何で他の.NETアプリは遅いの？

おじいちゃん、質問は一回チャッピーに聞いてからって言ったでしょ（言ってない

c#じゃないから
.netが遅いって言う人は昔の.net Frameworkのアプリの話でしょ
.net c#でAIにサンプルレベルでもいいからメモリに積極的にキャッシュするタイプの画像ビューアーを作ってもらえば.netでも速いとわかる

c#使ったけど遅かったぞ
チャッピーも仕方ないと言ってた

>>186
計測して30Hzでした

mImageViewer v3.1.0
入力速度␣平均処理漏れ数(5回計測)
30 Hz␣0個
35 Hz␣0.8個

>>181
意図が達成されたそうですが更なるスピードアップはありそうですか？
場合によっては送信ツールの改良をしないといけないと思ってます

個人的には起動後のNeeviewはトップクラスに高速だと思いますが
>>184 小気味いいです（NeeView比）
とある様にsuzuniaが更にその上を行っているのは自分も感じました

今回の基準でのキー送信ツール計測が良い指標になるのではないかと思ってます

「偉そうなこと語りやがってカスが」みたいな反応が来るかと覚悟していたのに、普通に受け入れられてて笑いました。

>>182
スクロールというか、ズーム周りは作ってる途中で時間切れが来て、それ以降何も弄ってないんですよね。
実装が中途半端で終わっていることは自覚しているので、いずれ改修します。

>>184
右クリック+上下左右のシンプルなマウスジェスチャーは既に対応しています。
右クリック+複数方向の真面目なマウスジェスチャーは、要望の声がもっと多く届けば。

>>187
私から言えるのは「そのアプリが遅いのは.NETのせいではない。suzuniaがその証拠」までです。これ以上は、空気を読んで。

>>192
今のところ、律速の要因が画像デコードに集中していて不可侵なので、これ以上のチューニングは不要と考えています。
プリフェッチのアルゴリズムが少し雑だなと思う部分はあるのですが、まあ目的は達していますので。

しかし皆さん、起動速度はあまり気にしないんですね。私はここが重要ポイントなので、Meeya代替が見当たらなくて困っていたのですが。

都度閉じるタイプのビューアの人は起動時間も気にするかもしれないがファイラ併設型だと一度起動したらそのまま次の本を選ぶだけだから起動よりはページの表示時間の方が重視されるのかと

起動が速いアプリはそれ以外も速いから
起動が遅いのはただデメリットでしかない

トレードオフだよ
suzuniaはページスライダーや情報ウィンドウのように
ユーザーへの情報や状態のフィードバック表示が弱い(デザインや一体感)

起動が遅くても全キャッシュしてページ移動が速いほうがいいね
ミーヤでもキャッシュの設定でそうしている

ミーヤはページ移動も遅くは感じないが…

>>131あたりからの流れでミーヤの計測ないな？
どのくらいだったんだ

>>199
公式配布が無いのでmeeyaは持ってないです

>>194,197
(.netでの)目的は達成とのことで(他言語を含めて)起動の早いUIを探してるのならSlintは良さそうです
公式サンプルのgalleryが40msで起動します
https://i.imgur.com/dL3WqPS.png
https://i.imgur.com/xM168yK.png
https://i.imgur.com/HTuAIa7.png
https://i.imgur.com/sAyFUQh.png

>>132,167もSlint製で40ms弱で起動します

>>201,202
40msで起動とは空のウィンドウではなく内容の描画された画面の起動です

suzunia-20260818は初回起動しただけのデフォルト状態(ペンギン付)で起動時間45msでした

QTだと150msくらい
サムネイル描画も向いてないみたいだからビュアの作成には使わんほうが良い

suzuniaの目的は「.NETは遅くないことを証明する」なので、45msと40msで争っても仕方ないので正直どうでもいいかなって思います。
起動に数秒掛かる異常なアプリが「.NETのせいです」って言い訳できないようにしたいだけなので。

起動時にライセンスチェックとか通信しちゃう系だと関係なく起動遅そうとは思う

suzunia haruhi no yu-utsu

>>206
でもこれって、デブのせいでリレーが遅いっていうのを、走れるデブもいるからデブが原因ではないって言ってるだけだと思うんだよね

>>206
.net製アプリが遅いのはコンポーネントとか利用するからだってのは周知なんよ
それらを利用する事で「簡単に」作れる事がウリなんだから

あんたのは「速くなるように設計してそれが目的になったアプリ」なんだからそれで他のと比べて速く無かったら文句の対象にはなるって話

目的が達成されても「あんたの作ったアプリが特別早いだけ」って査定にしかならんのよ
他のよく使われてるユーザーの多い大多数のアプリは遅いまんまなんだから

周知ではないですね。例えば >>67 「.net 終了」といった、".NETな時点で駄目だ"という反応が分かりやすい証明になっています。
なんというか、噛みつきたいだけのレスに対応するのはこれで最後にしますね。