堕天使の煉獄

ほんとはこゆのは年末にやる物なんだろうけど、実際には年末にはなんにもしてなかったりで。
単に、ＰＣをスリープから復帰させたらｃｐｕファンの音がなんかひかっかってるるような音出してたので（しばらくすると音やんだけど）ちょっとケースの中のぞいてみたら結構埃たまってきてるなということで、ＰＣのケースの中掃除ついでに周辺から部屋全体まで拡張でプチ大掃除することに。

結果……腰いてぇ。運動不足だなぁ……これは。

ＰＣ置いてあるラックの下は絨毯みたいな埃が積ってたものの、ＰＣのケースの中は思ったほど埃はいってない。ＣＰＵファンも、ぼちぼち埃ついてるけど、うわこれやべぇっってレベルにはほど遠いぐらいだったりで。
うーん。
雪降ってて特に寒い日だったから、ファンのふけが悪かっただけなのかな？
とりあえずブラシ付きの掃除機で掃除。

……特に何かしでかした記憶が無くても、電源コードから全部外して清掃した後って、初回の電源投入は未だに緊張する一瞬だなぁ。こればっかりは慣れない。真っ黒な画面とか青い画面しかでなくなっちゃったらどうしようっていう。

が、とりあえず普通に起動。それほど影響ありそうな量には見えなかったけど、結構影響あったのかＣＰＵファンの音もかなり静かに。

しかしこのZALMAN　CNPS2XというＣＰＵファン。
価格.comの評価は両極端で製品的にも当たり外れがあるっぽいのか不安な感じだったのだけども。とりあえず日記のログみると2015年04月に取り付けたのでもうふた夏越えてるけど特に問題無く使えてるしよかったなと。
でも掃除してておもうのが、やっぱこれ作りがちゃっちいなぁ……。玩具みたいなんだよな。
掃除の最中にぶっ壊しそうなチープな作りにドキドキ。

てかファン変えてから清掃するの初めてのような気がするので、もう約二年近くであの埃の量かと思うと、意外に少なかったなという印象。

そんなこんなでＰＧ続き。

麻雀じゃなくて、また書庫編集ソフトの方。



前回ちょっと弄ったところで、以前から残るTODOリストメモには「冗長なディレクトリを除去処理」の文字が。

それまでは書庫内ファイルのファイルパスで単純にソートしただけの単一のリストで管理していたのだけども。

処理的には

1．ツリーの最下層のディレクトリの中身が空ならそのディレクトリは削除。

2．ルートにはファイル無し、ディレクトリは一つしかない。その場合ディレクトリを消去。（以降のディレクトリとフォルダのパスはすべて一つづつ階層繰り上げ）

の二種。

どちらも再帰的な処理が必要になるぽ。
1の場合だと、末端ディレクトリ消去した場合、その上のフォルダが新しい末端フォルダになるので。

そのような再帰的な処理をしようと思うと、末端ディレクトリには、一個上のディレクトリの情報が必要になる。2の場合は逆に一個下のディレクトリの情報が必要になる。
１の場合は、親は必ず一つだけど、2の下部ディレクトリは複数ある。

階層深度と上と下への参照をもったリンクリストがいるのかーとなんだかめんどくさい感じに。

で、とりあえず出来たー。

これで一応UnifyZipというフリーの書庫整理ソフトで出来る事は殆ど自前で出来る感じに。冗長ディレクトリ除去も当然再圧縮無しで出来るので自前のが高速だし。
あとはzip以外の書庫からみんなzip変換して統一するという機能がつけばUnifyZipに頼らなくても良くなるんだけど……
そうなると結局アーカイバDLLを使う必要が出てくるんだよなぁ。rarとかver違いとかあってめんどくさいし。でも別の書庫に変換するだけならそれほど手間でもない感じですけど。
でも、それならUnifyZip使えばいいじゃん……という気もしてたりする。
別の書庫形式への変換は結局、解凍→圧縮を行うので自前でやろうが処理速度は変わらないし。
UnifyZipでも出来るけどあえて自前でやってる処理は、再圧縮無しなので高速化出来るというメリットありきだったりするので、処理時間変わらないなら別に作る意味ないかなと。
でもあと一つだけとなると全部自前で完結させたいという欲求も出来てたりもする。
むーん。


ついでにほかにもいろいろと弄る。

これは以前から気にはなっていたのだけども、QGaphicsView/Sceneはものすごく便利なのだけど、とにかく拡大縮小が汚い。処理時間掛かっても高品質な拡大縮小できるオプションないのかよと調べたのだけども見つからない。そのときに見つけた記事によると、どうも高品質かつ高速な拡大縮小にはＧＰＵの機能を使う必要があるが、クロスプラットフォームで同様の動作を保証するためにその辺のルーチンを一部の環境依存にするわけにはいかないし、ソフトでチューンしても、その後の環境依存で引っかかる可能性もある感じで、高品質な拡大縮小はサポートしていない。という事情があるらしいっぽい？

そんな事情らしいということは判ったけど、書庫内画像のプレビューで、拡大縮小が汚いのはやっぱストレス溜まる……。

なんか方法ないのかね。と思い出すたびに検索してたりして。

で、結局今回、妥協案で解決した……。

結局QGaphicsViewの拡大縮小は使わずに、QGaphicsScene内のQGaphicsItemに登録する画像を直接事前に拡大縮小するという方向に……。

まあこの方法は、今回のようにviewには常に画像一枚しか表示させないという限定条件の中でこそ可能な感じの解決法ですけど。

つまり単純にSceneに登録する表示用画像を、元画像を倍率にあわせて拡大縮小処理をしたあとSceneに登録する。倍率変更あったらまた拡大縮小前の元画像から拡大縮小処理をしたあとSceneに再登録する。
というだけの事。
当然、縮小はそうでもないけど拡大は150％を越えたあたりからかなり重たくなるぽ。GPUではなくバイナリ直のＣＰＵ処理で拡大縮小処理してる感じなので。

今時画像の拡大縮小にハードウェアサポート無しと言うのもなんだかなーという気もするのですが、クロスプラットフォーム向けの弊害と言う奴なのか。
うーんでもそう考えると、GPUサポート有りなQGaphicsItemみたいなのないのかなぁ。

……あ。

この日記書きながら調べ物してたらもっとマシな解決法っぽいものが。
QGraphicsPixmapItemにsetTransformationModeメソッドがある。これQt::SmoothTransformation指定すれば、QGraphicsPixmapItemに設定した画像をQGaphicsViewが拡大縮小表示するときにハードウェアサポートありでやってくれるようになるのでわ？
QPixmapはバイナリのピクセルデータ保持クラスなのでPixmapの拡大縮小機能はバイナリレベルの処理だけど、QGraphicsPixmapItemに登録したものは描画用アイテムなので、そうか、本来はこうするべき物だったのか？

とワクテカして試してみたら……変化無しぃｗ

結局もとの、登録するQPixmapを倍率変更毎にCPUで拡大縮小処理して再登録～の処理に戻す……。

まあ、拡大の時にちょっと引っかかる感じに重くなるけど、それ以外ではそこまで気になるほどではない感じなので、まあこれで良いか……。

でも以前の方法は汚いけど高速なので、従来の速度重視と品質重視のモードを選択出来る様にしてみたり。


てか、ほんと外人さん製ツールに多いんだけど、拡大縮小にbilinearとか使わない、汚い画像で満足できる感性が判らない。大昔のフォトショップもそうだったけど。

でもまあ、上にも書いたけど、この方法は今回のケースの場合のみ有効で、本来のQGaphicsView/Sceneの用途的に、多種多様なアイテムを追加したSceneをViewで拡大縮小できるようなものだとこの方法は使えない（事もないけど、それぞれのアイテムの再登録が倍率変更毎に毎回起るってのはなぁ）ので、やっぱＧＰＵで高品質な拡大縮小サポートしてほしいなぁQGaphicsView……。

はふー