漫画ビューア総合スレ 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/

>>66
いいかなっておもったけどepub内の文字の大きさ変えれないのか
あとフォルダー内移動もできなさそう

Kinoppyの方が小説見るには使い勝手いいんだよな

>>77
meeyaの方が使い勝手よくない？
まあフォルダー内の書庫ファイルが多いと次の書庫がめっちゃ読み込み遅くなるって致命的な
バグがあるけど

軽くてmeeyみたいにフォルダ自体の削除とフォルダー内ファイル削除どっちもあるの
がいいんだけどな
色々使ってみたけど他のはフォルダー内ファイル削除機能しかないんだよな

書庫内の削除とかメンテナンスなんて頻繁にやらんし
そもそも自分で作った書庫を書庫化した後にメンテナンスするの？

ビュアに削除機能を持たせるのは推奨しないけどな
キー一つで削除とか怖くて使えん

>>88
デフォでオフ

>>88
確認のウィンドウでも出してくれれば

>>88
強制じゃなければあったら楽

>>88
他の例があるので分からんでもない

987 名無しさん＠お腹いっぱい。 2026/07/30(木) 13:29:42.78 ID:i3bL6g9L0
もっさりしてて困ったのが、ファイルを複数選択して削除したら選択してないつもりだったものも選択されたままで削除されてしまったこと。
ゴミ箱も空にしてから気づいたから終わってた。

>>66
suzuniaの場合は、ゴミ箱の時にも確認ダイアログを出す選択肢は有っても良い

ファイル操作
✅ファイル制御を許可する
「ファイルの削除」などのファイル操作メニューを有効にします。誤操作を防ぐため既定はオフです。
✅ファイル削除時にゴミ箱に入れる
ファイルを削除するとき、完全に削除せずゴミ箱へ移動します。オフにすると直接削除されます。
✅直接削除するときは確認ダイアログを出す
ゴミ箱を使わずに直接削除する際、確認ダイアログを表示します。

>>66
>>82-83
epubにはwebviewを使っているから技術的には簡単に解決できるけど設定画面がどんどん増えて行くな
早いうちに設定検索を付けないと文句出る

設定や履歴等のjsonファイルはサブフォルダに置かないといけない
いつも上書きアップデートで躓く人がチラホラ居るので

>>88
単にゴミ箱送りなんだからエクスプローラーの戻すで簡単に一つ前に戻せるぞ

>>88
ファイラーもキー一つで確認無しにゴミ箱だぞ

suzunia、neeview、mimageviewを試した
結論から言うとミーヤ使用続行。全般的にはプレイリストと割合移動がどれもない

なぜどれもデフォルトフォルダを求めるのか。
空のプレイリストがあって、複数zip放り込めばその分登録されて、ビューア閉じたらリセットされる。
それだけで良いのになんでそれすらできないのか理解できない

suzunia　デフォの鳥サムネが気持ち悪いのに無効にできない、プレイリストがない。固定ページ移動はあるが割合移動がない

neeview　割合移動がない。「プレイリスト」名称の機能はあるがこんなのはプレイリストでもなんでもない

mimageview　根本的に漫画ビューアを誤解してるくさい。というか日本人が作ったかも怪しいレベル。
表示は？プレイリストは？操作設定のページ移動は？画像フルスクリーンてなに？なんで動画があんの？
列だのタグだのようやく消したと思ったら今度はなにも設定できないという。
これで400MBって本当になんなのこれ

>>96
> デフォルトフォルダ
何それ？異世界用語？

クセ強人間は自分で作るしかない

＞空のプレイリストがあって、複数zip放り込めばその分登録されて、ビューア閉じたらリセットされる。

なんで毎回無駄な作業をするのが好きなの？
お気に入りをぶち込んでプレイリストを作るは理解出来るけど、毎回リセットされる意味が分からない。

デフォルトというかなんか別の表現したかった系？？
重度のMeeya依存症なのはわかったｗ
割合移動なんてミーヤにあったっけ？？？

>>96
>>空のプレイリストがあって、複数zip放り込めばその分登録されて、ビューア閉じたらリセットされる。

NeeViewはD&Dやコンテキストメニューの「NeeViewで開く」or「送る」で可能
一時フォルダ配下に一時プレイリストが生成されてそれが本棚として開かれる仕組み。NeeView終了時に一時フォルダごと破棄される

割合移動についてもスクリプトを書けば可能（NeeViewはスクリプト次第で「何でも可能」と言ってもいいほど）
実際のところ「使いこなし」の問題に過ぎない

> 実際のところ「使いこなし」の問題に過ぎない
ほんそれ

「デフォの鳥サムネ」なんか初回起動の設定で普通に無効にした

＞空のプレイリストがあって、複数zip放り込めばその分登録されて、ビューア閉じたらリセットされる。
えっ
駄目なの？
エクスプローラーからドラッグアンドドロップのOSのUXにあう方法でしょ
何が無駄な作業なの？

割合移動って何？

>>66
https://github.com/suzunajp/suzunia-release/releases/tag/v20260812
> 一旦、当初の想定で考えていた機能は全て揃った版
suzunia, 1週間足らずで完成したってよ

>>96
プレイリスト機能は想定外

>>104
10%, 20%とか設定して全体ページ数(例200なら) +20とか+40 毎にジャンプするのでは
Youtubeの数字キーみたく割合絶対位置ジャンプもあると良いね( 1で10%の位置、5で50%の位置など)

見開きでも1ページ表示でも割合だと計算しなといけないし
20ページスキップとかの方が実装は簡単かな

>>105
YouTubeにそんな機能あったんだなーｗ いつからなんだろ？

suzuniaシンプルで使いやすいけど
縦に収まってない時にホイールで普通にスクロールできる設定ないのかな
どのビューアもホイールがページ送りなんだよね

>>96
現行世代四天王、あと一つは？

>>106
実装が簡単とか利用者には関係ない話
固定ページスキップは使いづらい
理由は前スレ756

俺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させてほしい