堕天使の煉獄

先日のビューを回転とかさせると、ジェスチャー時のアナウンス表示まで回転してしまってGraphicsViewに描いたら駄目じゃんの件。

最初はビューの回転をGraphicsSceneの方でアイテムを回転する方向に書き換えようと思ったのですが、そうか……Sceneの方で回転やらなかったのはアニメgifなどの動画形式がScene内のGraphicsItem(の派生クラス)の回転だとコストが高すぎる。
フレーム毎に毎度拡大縮小回転かける感じになってしまうので。
んで回転に関してはGraphicsViewに任せることにしたんだっけか。
じゃあこの案、没～。

Mainwindowに移すか？
と思ったけど、GraphicsViewのマウスイベントと競合する感じでなんかうまくイベントが受け取れない……。
描画も更新のタイミングが駄目なのかうまく描画されず。
コレも駄目っぽい。

んー、なんかビューの変更に影響しない描画方法ってのやっぱあったような気がするんだよなぁ。

ってことで調べてみたのだけども。

GraphicsViewの描画部分QPainter* pで

p->resetTransform();

を追加するだけでおｋでした。

これでビューの回転やらリセットした状態で描画出来るようになったので、普通に描けるように。

やっぱあったね……。
随分遠回り。

んで、そこまで来た所で、ああコレ前に使ったじゃん……ってなったり。

むかーしに作ったwiz風3Dダンジョンのマップ作成ツールで、座標系をwizと同じく、左下を0，0の原点にしてｙ軸は上方向が+になるようにsetScale(1,-1)で垂直方向に反転したかんじのビューに設定して。

んでそこにツールチップ的なの描画する際に、そのままだと文字とかまで反転しちゃう～ってので、その時にもresetTransformやってたわと……。

一度昔に解決した問題でまた悩むとかとっても無駄な時間を……ｗ


気を取り直して、カタログ表示部分を作り始める。

表示周りの外堀をガリガリ組みはじめたのだけども。
仮に表示部分のサイズを決めるところで、どうしようかなと。

問題は、サムネイルの画像サイズをどうするかというところで。

画面の解像度によって（いまは4Kとかもあるしね）サムネイルのサイズも変えたい感じもあるぽ。
画像サイズとメモリ使用量や読み込み速度、描画スピード辺りはトレードオフなのだけども、結構好みの部分もあるしで。

んで、当初の予定だと、パスから適当なファイル名生成して、フォルダ一つに1つキャッシュファイル作成して～て感じだったんだけども。

サムネ画像のサイズ変更のたびにキャッシュ全部作り直しだし、そもそもそんなにキャッシュ要るかな？　という根本的なところから見直したほうがいいような感じもしてたりで。


んで、他のツールはどうなってるんだろ？
ってことでsusieは現物ないのでわからない。
でもおぼろげな記憶だと、サムネ画像のサイズは固定だったかな？
Thumbs.dbとか標準的なフォーマット踏襲してる感じだったし。

マンガミーヤを見てみると、

サムネイル表示（1画面）
サムネイル表示（8列）
サムネイル表示（カスタム）
表紙サムネイル

の三種類あって。

サムネイル設定のとこ覗いてみると、縮小に使うフィルタ選択はいいとして。

保存設定てのがあって、保存しないのと画像フォーマット指定して保存するオプションがある。

カスタムサムネイルのところを見てみると
[行x列]=[8x9]: バッファサイズ=1800x2528
予想メモリ使用量: 13.65[MB]

というヒントが表示されたり。
サムネイルサイズ指定に対してどんぐらいメモリ喰うのか指標をだしてくれるんだね。

幅が200高さが300に設定されてる状態なんだけど
バッファサイズが1800x2528てのは？？

8*9だと計算合わないな。
そして一枚の大きいサイズの画像をバッファとして用意してる感じなのか。
なんかdirectXのテクスチャサイズの制限てきなアレ？
そんで描画の高速化も考えられてる感じっぽいですね。ドローコール減らす的な。
まあこのへんは最適化の話な感じなのでQtだとあんま関係ないかな。
Qtにほとんど丸投げ部分なので。

んで、リストの枚数が多い場合、画面サイズもといバッファサイズ超えたらもう一個分取得する感じなのかな。
大量にリストあるとき、画面スクロールした後で非同期読み込みしてるけど、スクロールもどしても再読込しないのでその都度バッファの開放はしてないっぽいですね。


なるほど、サムネファイル作らないで、メモリ上に置くだけで、保存はしない。
その方向のがいい感じですね。
その方式だとサムネのサイズも設定で変えても問題ないし。

そもそも、そんなカタログ機能って頻繁に使わない……くない？　個人的にはあんまり使ってないです。

たまーに大量の画像の中からあの画像何処だっけ？
って探す時にサムネ表示して見つけるために使うぐらいだったりで。

タスクマネージャでメモリの増減も見てみたけど、サムネ作ったあとも別のフォルダとか別の書庫に移動しない限りは作成したサムネはメモリ上に持ってるみたいですね。
で、別の場所に移動したら開放って感じで。

ふむう。

全部メモリに読み込んでキャッシュは保存しない方向で作る感じにしようかな。


オンメモリでも、キャッシュファイルに書き出す時でも同じなのですが、考えるべき点は、大量のリストの場合どうするかですね。

せいぜい数十～数百程度ならいいんですけど、数千～数万とかになると、一気に読んだり、全部保存したり大変ですしね。
そういうところまで一応考えて設計しないと駄目な部分なんだけど。

まあとりあえず組んでみてから考えるかｗ

実際に作ってみて、メモリどのくらい喰って、どのタイミングで開放するべきとかは現物見ながら考えよう。


なにげにまだデバッグモードだけどもメモリ消費量どうなってるかなと見てみたら、実行時画像ロード済みで20MBちょいぐらい。
拡大するともりもり使用量増えていく感じ。

綺麗に拡大縮小するために元画像を実際に拡大したpixmap持ってるからなぁ。
でもまあ特にムダに大きいってこともない感じぽ。

サムネ用の小さいサイズとはいえ、QImageの容量はどんなもんなんだろうね。
QImageじゃなくて小さいjpgとか生成してそれをバイナリで持つとかのが小さく出来そうだけどどうなんでしょね。
所詮サムネなので、画像が判別できればいいわけで。
そこまで画質にこだわらなくてもいいわけだし。
低画質にも限度はあるけどその限度は個人の感覚によるところではあるんだけども。

でも今の時代、数百MB程度ならメモリ喰っても普通なとこあるし、富豪的に作るほうがいいんだろうなぁ。

とりあえず、「完璧を目指すよりまずは終わらせろ」だよね。


それよりも、デバッグビルドしたらCPU100％にがつーんと毎回逝ってることに愕然としたｗ

おもにclang関係が重いんだろうけど、ビルド負荷重すぎだろと。

わりと最新のCPUでもそんなんなるとかいう記事どっかで見た気もするな。
ガッツリCPUパワー占有する感じみたいね。

clangのなんかいろんなプラグインとか取り込んで、便利になった部分もあるけど、かなり重くなったよなQtの開発環境。

以前の古いPCだと、clangbackend.exeとかいうプロセスがメモリもCPUも爆食いしてハングが頻発して使い物にならなくてclangのプラグイン切ってたけど。

しかしもう2月も終わりか。
ちょっと開発ものんびりしすぎかな。

もちっと気ぃ入れてさっさと終わらせないとな。

プロゴルファー猿 全153話とか見てる場合じゃないぞ（ぉ