堕天使の煉獄
2025-03
08
00:47:04
アウアウア
気がついたら3月入って一週間たってたり。
しばらく根詰めてPGやってたので、ちょっと息抜きで色々と他事やってたり、積んでた本とか読んでたらなんか時間があっという間に過ぎてたり……。
一度歩みを止めるとトルクがなさ過ぎて再始動がとても鈍いんですよね最近。
とりあえずさっさと終わらせて次に行きたい所なので、頑張って作業再開。

サムネイルのカタログ表示、別スレッドで読み込みな感じの。
なんかテストに手頃で、かつ出しても良い画像がそれなりの枚数ある所てので、昔のお絵かき用ワークのフォルダを使ってテスト。
なにげにまだこの頃、アナログでコピー紙にシャーペンで描いてた時代ぽ。
なので画像フォーマットがBMPでクソでかい(30MBとか)ファイルもいっぱいあったのだけども。
なんでBMPかといえば単純にスキャナでスキャンした画像だからです。
そこから写真屋でレベル補正とかかけて線画をくっきり出した……後の画像ですね右側の画像は。
この頃は、そこからsaiで線画をペン入れしてた頃かな。
ほとんどなぞるだけの単純作業で、作業感あってあんまり創造性のない作業な気がしてあんまり好きじゃなかった作業だったなぁ。
ここ最近は線画から全部フルデジタルに移行しちゃったので、アナログで絵なんてもう何年描いてないだろうか……。
閑話休題。
別スレッドでのサムネ画像作成、実行してみたら一枚ずつぺぺぺ……と画像が表示されるの想像してたんだけども、一瞬で20枚ぐらいがぺっと表示されたあと、一瞬間をおいて残りが表示されたり。
試しに設定したのが80*100サイズのサムネなんですけど(上の画像はブログ貼り付けようにちょびっと縮小してるので実サイズではないです)30MB位あるBMPなんかも複数枚あるのにわりと一瞬で表示されてなんかエラく速いなと。
一応一枚ごとに表示をupdate()してるしてるのですが、間隔が短すぎて一気に表示されてる感じっぽい。
それとも別スレッドからのシグナルの受け渡し間隔の問題??
んでメモリ使用量もサムネ画像のサイズが小さすぎたのか、ほとんどわからないぐらいの微増しかしてないっぽい。
なんか思ったよりも読み込み速すぎて、逆になんかコレジャナイ感がw
んで、今回はQt6から入った新機能のPromiseモード(QPromise)を使ってみる初テストだったりもする。
途中で中断したり再開したりが簡単に出来るので、大量のリストがあった場合には、一括で最後までサムネ作成しないで一旦止めて。
スクロールバーでスクロールした時に再開する感じとか出来そうだなと思ったのですが。
表示部分はQListViewで、flowモードってのにしてるのだけども。
HTMLとかのレイアウトでやるようなやつですね。
画面の端に来たら自動で折り返す感じのやつ。
それと順次ロード待ちの組み合わせ、なんか相性悪いというか、めちゃ複雑な感じになりそうで、ちょっとどうしようか悩み中。
ウェブページみたく、ページ切り替えできっちり区切りついた感じだったらまだやりやすいんですけどね。
イメージ的にはアドオンとかである、何ページもある内容で、スクロールバーを下に持ってくと次のページを現在のページの下部に続けて読み込んで表示するヤツ。
あんな感じだとページ単位で読み込み済みと未読込の管理もしやすいんですけどね。
大量にある時に、スクロールでずっと下部に移動したら移動後の場所のページを読み込み始めるけど、その間の部分は未読込のままとか出来るし。
それがflowレイアウトで、かつサムネイルの画像サイズも設定で可変とかなると、ウィンドウのリサイズでページ単位が変更されたりしてしまうので、困った感じになってしまうんだけども。
でもページ切り替えってのもなんかそれはそれで微妙な気もするしなぁと。
んー。
とりあえず、一度に読み込む最大件数だけ設定して。
もっと読み込むかは最大件数に達する毎に選択(コンテキストメニューからとかで)させる感じでいいかなぁ……それが一番面倒なさそう。
別スレッドなのでバックグラウンドで読み込み続けるにしても、流石に数万件とか読み込ませ初めたら止まらないってのはマズイものね。
しかし、シグナル・スロットで別スレッドで動いてるのを簡単に制御出来るこの仕組みは素晴らしいですね。
昔はもっと低レベルなQThread使って、ほんとにこのやり方でええんかいって感じなのでやってたので。
それに比べたらQtConcurrentの高レベルなスレッド周りはとてもシンプルに組めて楽でよいです。
プチ中断する前というか、中断する契機になったのが、この別スレッドでまわす関数の中身で、範囲ベースのfor文書く所で、そういえばなんかc++23とかでrangeてのあったよね。あれもうvc++でも使えるんだっけか?
って言うところから、最近のvc++のc++2xの対応状況調べ始めたところでかなり長い時間調べ物してた所為で気持ちが途切れちゃったってのがあったり。
でもまあ、色々と収穫もあったので無駄ではなかったんですけどね。
cpprefjp - C++日本語リファレンス
ttps://cpprefjp.github.io/
ここは個人(数人の有志?)がやっているようで、コンパイラの実装状況とか最新の情報が常にあるってわけでもないのですが、幅広く網羅しているので新しく入った新機能とか調べるときには大体ここ見れば済むって感じでお世話になっております。
が、vc++の対応状況は全然実態と違うんですよね。
といってもここの人が悪いわけでもなく。
基本的に、c++latestはまだ正式対応という感じじゃないっていう扱いみたいで、一応使えるのに対応表では未対応表記……ってのがとてもめんどくさい。
そして、rangesはc++20以降いくつも機能が追加されてるんだけども、vc++の方も順次対応を進めてる感じでvc++のバージョンの何処から何が使えるようになるのか。
最新版だと何処まで使えるのか。っていうのがとても把握しづらくて……。
対応表を見ただけだと使えないと諦めてたものが、実はc++latestだとあっさり使えるとか結構多くて、なんだよもう……って感じになるのが多すぎる……。
んで結局vc++の少し前のバージョンから更新リストをずーっと見直して、あ、これもう使えるんじゃねーかとかそんなんで数日費やしてたり。
んで結果として、rangesは一応現時点では実装が完了してるらしい。
ただ、まだまだ内部の最適化は継続中……みたいな感じらしいんですけど。
でもとりあえず動くらしい。
以前調べた時は中途半端に対応途中だったので、使えるものと使えないもの調べるの面倒になって、全部終わってから使おうって感じで見送ったので。
ようやく使えるようになったんだーってのを今回知れたのは収穫だったかな。
んでQt上で実際に使ってみた所、特に警告とかも波線とかも出たりせず、すんなり使えたり。
解析がclang使ってるからですかね。
まだc++11~17辺りだと、vc++だともう使えるけどQt Creatorの方では対応してなくて警告出たり、酷いのだとその部分以降ハイライタがぶっ壊れたりとか面倒な感じになったこともあったなぁ。
その辺clangに投げる方向に進んだのは慧眼だったんだなぁと。
てかコンパイラの対応表みてると、clangは先進的で突っ走ってるけどここ何年かはgccがきっちり追従してるのが変わったなぁとか。
c++11~17ぐらいまでは結構gccは対応遅かった印象なので。
それどころかc++26だとgccのが先に対応してるのとかあるし。
逆に最近はvc++がかなり微妙だったりで。
c++23の言語機能の方、ここ数年まったく進んでなかったりするし。
if constevalいつになったら使えるねん……。
でもc++23の標準ライブラリ機能の方はほぼ実装済みみたいで、そっちに全部のリソースつぎこんでる感じなんですかね。
c++26の方はまだぜんぜん白紙っぽいですけど。
ていうかinspectはまだ来ないのかなぁ。
次世代のswitch case文とも言うべきinspect。
CEDEC 2024『ゲーム開発者のための C++17~C++23, 近年の C++ 規格策定の動向』
ttps://www.docswell.com/s/cpp/5XEY92-cedec2024#p1
今回色々調べてた時に出てきたスライドなんだけども、新旧包括的に網羅されてるので、復習と新規の両方学べてとてもいいスライドでした。
……ただ、新規の方はvc++で対応してるのか調べながら見てたので全部見終わるのにえらく時間かかった……。
optionalのモナドとかもう使えるのかぁ……いつの間に。
めっちゃ種類あるのなrangeアダプタ。
便利だけども、空で使い分けられるかと言うと……どっかに一覧まとめて置いとくとかしないと適宜に使いこなせなさそうw
んで、ここの最後の方でちょっとinspectにも触れられてたんだけども。
なんかC#とかっぽく「as」キーワード入れたりとか「let」とか、書き方のところで意見が割れてたりとかでごちゃごちゃやってるらしい……。
んでc++29になりそうとか……うぐぅ。
とりあえずまあ現状c++で欲しいのは「inspect」と「c++26では削除されるcodecvtの代替」の2つが筆頭ですかね。
後者はほんとどうにかして欲しい。
だから未だにc++は文字周りダメダメだよねと言われるんだよ(ぉ
Qtでもunicodeの相互変換はできるけど、shift-jisが切られちゃって変換するのに困る感じになっちゃってるんですよね。
未だにzipフォーマットの中身の文字はshift-jis多いんだよ……。
まあwin環境に限ればWinApiで文字コード変換辺りはなんとかなってるけども。
でもできれば環境依存コードなWinApi使わないで済ませたいですよね。
そんな感じで、susie代替のビューワ、あとは細かい設定周りと設定画面のui辺り作ったらとりあえず完成かな。
んでも画像ファイルへの関連付けの仕方がwin10以降? から変わったけど、関連付けたファイルのアイコンの設定とかどうやるんだろね。
その辺まだ全然調べてもないや。
いまウチのpcだと、とりあえず代替で使ってた画像ビューワに設定して以降、bmpもjpgもpngもみーんな同じアイコンになっちゃってるんだよな。非対応のavifだけ違うアイコンになってるけど。
拡張子で細かく分けるのとかは、新しい関連付け方式の方だとどうやって設定するんだろね。
できればタイプ別で同じアイコンでも色違いとかにしたいなぁ。
そのへんも調べとかないとな。
しばらく根詰めてPGやってたので、ちょっと息抜きで色々と他事やってたり、積んでた本とか読んでたらなんか時間があっという間に過ぎてたり……。
一度歩みを止めるとトルクがなさ過ぎて再始動がとても鈍いんですよね最近。
とりあえずさっさと終わらせて次に行きたい所なので、頑張って作業再開。

サムネイルのカタログ表示、別スレッドで読み込みな感じの。
なんかテストに手頃で、かつ出しても良い画像がそれなりの枚数ある所てので、昔のお絵かき用ワークのフォルダを使ってテスト。
なにげにまだこの頃、アナログでコピー紙にシャーペンで描いてた時代ぽ。
なので画像フォーマットがBMPでクソでかい(30MBとか)ファイルもいっぱいあったのだけども。
なんでBMPかといえば単純にスキャナでスキャンした画像だからです。
そこから写真屋でレベル補正とかかけて線画をくっきり出した……後の画像ですね右側の画像は。
この頃は、そこからsaiで線画をペン入れしてた頃かな。
ほとんどなぞるだけの単純作業で、作業感あってあんまり創造性のない作業な気がしてあんまり好きじゃなかった作業だったなぁ。
ここ最近は線画から全部フルデジタルに移行しちゃったので、アナログで絵なんてもう何年描いてないだろうか……。
閑話休題。
別スレッドでのサムネ画像作成、実行してみたら一枚ずつぺぺぺ……と画像が表示されるの想像してたんだけども、一瞬で20枚ぐらいがぺっと表示されたあと、一瞬間をおいて残りが表示されたり。
試しに設定したのが80*100サイズのサムネなんですけど(上の画像はブログ貼り付けようにちょびっと縮小してるので実サイズではないです)30MB位あるBMPなんかも複数枚あるのにわりと一瞬で表示されてなんかエラく速いなと。
一応一枚ごとに表示をupdate()してるしてるのですが、間隔が短すぎて一気に表示されてる感じっぽい。
それとも別スレッドからのシグナルの受け渡し間隔の問題??
んでメモリ使用量もサムネ画像のサイズが小さすぎたのか、ほとんどわからないぐらいの微増しかしてないっぽい。
なんか思ったよりも読み込み速すぎて、逆になんかコレジャナイ感がw
んで、今回はQt6から入った新機能のPromiseモード(QPromise)を使ってみる初テストだったりもする。
途中で中断したり再開したりが簡単に出来るので、大量のリストがあった場合には、一括で最後までサムネ作成しないで一旦止めて。
スクロールバーでスクロールした時に再開する感じとか出来そうだなと思ったのですが。
表示部分はQListViewで、flowモードってのにしてるのだけども。
HTMLとかのレイアウトでやるようなやつですね。
画面の端に来たら自動で折り返す感じのやつ。
それと順次ロード待ちの組み合わせ、なんか相性悪いというか、めちゃ複雑な感じになりそうで、ちょっとどうしようか悩み中。
ウェブページみたく、ページ切り替えできっちり区切りついた感じだったらまだやりやすいんですけどね。
イメージ的にはアドオンとかである、何ページもある内容で、スクロールバーを下に持ってくと次のページを現在のページの下部に続けて読み込んで表示するヤツ。
あんな感じだとページ単位で読み込み済みと未読込の管理もしやすいんですけどね。
大量にある時に、スクロールでずっと下部に移動したら移動後の場所のページを読み込み始めるけど、その間の部分は未読込のままとか出来るし。
それがflowレイアウトで、かつサムネイルの画像サイズも設定で可変とかなると、ウィンドウのリサイズでページ単位が変更されたりしてしまうので、困った感じになってしまうんだけども。
でもページ切り替えってのもなんかそれはそれで微妙な気もするしなぁと。
んー。
とりあえず、一度に読み込む最大件数だけ設定して。
もっと読み込むかは最大件数に達する毎に選択(コンテキストメニューからとかで)させる感じでいいかなぁ……それが一番面倒なさそう。
別スレッドなのでバックグラウンドで読み込み続けるにしても、流石に数万件とか読み込ませ初めたら止まらないってのはマズイものね。
しかし、シグナル・スロットで別スレッドで動いてるのを簡単に制御出来るこの仕組みは素晴らしいですね。
昔はもっと低レベルなQThread使って、ほんとにこのやり方でええんかいって感じなのでやってたので。
それに比べたらQtConcurrentの高レベルなスレッド周りはとてもシンプルに組めて楽でよいです。
プチ中断する前というか、中断する契機になったのが、この別スレッドでまわす関数の中身で、範囲ベースのfor文書く所で、そういえばなんかc++23とかでrangeてのあったよね。あれもうvc++でも使えるんだっけか?
って言うところから、最近のvc++のc++2xの対応状況調べ始めたところでかなり長い時間調べ物してた所為で気持ちが途切れちゃったってのがあったり。
でもまあ、色々と収穫もあったので無駄ではなかったんですけどね。
cpprefjp - C++日本語リファレンス
ttps://cpprefjp.github.io/
ここは個人(数人の有志?)がやっているようで、コンパイラの実装状況とか最新の情報が常にあるってわけでもないのですが、幅広く網羅しているので新しく入った新機能とか調べるときには大体ここ見れば済むって感じでお世話になっております。
が、vc++の対応状況は全然実態と違うんですよね。
といってもここの人が悪いわけでもなく。
基本的に、c++latestはまだ正式対応という感じじゃないっていう扱いみたいで、一応使えるのに対応表では未対応表記……ってのがとてもめんどくさい。
そして、rangesはc++20以降いくつも機能が追加されてるんだけども、vc++の方も順次対応を進めてる感じでvc++のバージョンの何処から何が使えるようになるのか。
最新版だと何処まで使えるのか。っていうのがとても把握しづらくて……。
対応表を見ただけだと使えないと諦めてたものが、実はc++latestだとあっさり使えるとか結構多くて、なんだよもう……って感じになるのが多すぎる……。
んで結局vc++の少し前のバージョンから更新リストをずーっと見直して、あ、これもう使えるんじゃねーかとかそんなんで数日費やしてたり。
んで結果として、rangesは一応現時点では実装が完了してるらしい。
ただ、まだまだ内部の最適化は継続中……みたいな感じらしいんですけど。
でもとりあえず動くらしい。
以前調べた時は中途半端に対応途中だったので、使えるものと使えないもの調べるの面倒になって、全部終わってから使おうって感じで見送ったので。
ようやく使えるようになったんだーってのを今回知れたのは収穫だったかな。
んでQt上で実際に使ってみた所、特に警告とかも波線とかも出たりせず、すんなり使えたり。
解析がclang使ってるからですかね。
まだc++11~17辺りだと、vc++だともう使えるけどQt Creatorの方では対応してなくて警告出たり、酷いのだとその部分以降ハイライタがぶっ壊れたりとか面倒な感じになったこともあったなぁ。
その辺clangに投げる方向に進んだのは慧眼だったんだなぁと。
てかコンパイラの対応表みてると、clangは先進的で突っ走ってるけどここ何年かはgccがきっちり追従してるのが変わったなぁとか。
c++11~17ぐらいまでは結構gccは対応遅かった印象なので。
それどころかc++26だとgccのが先に対応してるのとかあるし。
逆に最近はvc++がかなり微妙だったりで。
c++23の言語機能の方、ここ数年まったく進んでなかったりするし。
if constevalいつになったら使えるねん……。
でもc++23の標準ライブラリ機能の方はほぼ実装済みみたいで、そっちに全部のリソースつぎこんでる感じなんですかね。
c++26の方はまだぜんぜん白紙っぽいですけど。
ていうかinspectはまだ来ないのかなぁ。
次世代のswitch case文とも言うべきinspect。
CEDEC 2024『ゲーム開発者のための C++17~C++23, 近年の C++ 規格策定の動向』
ttps://www.docswell.com/s/cpp/5XEY92-cedec2024#p1
今回色々調べてた時に出てきたスライドなんだけども、新旧包括的に網羅されてるので、復習と新規の両方学べてとてもいいスライドでした。
……ただ、新規の方はvc++で対応してるのか調べながら見てたので全部見終わるのにえらく時間かかった……。
optionalのモナドとかもう使えるのかぁ……いつの間に。
めっちゃ種類あるのなrangeアダプタ。
便利だけども、空で使い分けられるかと言うと……どっかに一覧まとめて置いとくとかしないと適宜に使いこなせなさそうw
んで、ここの最後の方でちょっとinspectにも触れられてたんだけども。
なんかC#とかっぽく「as」キーワード入れたりとか「let」とか、書き方のところで意見が割れてたりとかでごちゃごちゃやってるらしい……。
んでc++29になりそうとか……うぐぅ。
とりあえずまあ現状c++で欲しいのは「inspect」と「c++26では削除されるcodecvtの代替」の2つが筆頭ですかね。
後者はほんとどうにかして欲しい。
だから未だにc++は文字周りダメダメだよねと言われるんだよ(ぉ
Qtでもunicodeの相互変換はできるけど、shift-jisが切られちゃって変換するのに困る感じになっちゃってるんですよね。
未だにzipフォーマットの中身の文字はshift-jis多いんだよ……。
まあwin環境に限ればWinApiで文字コード変換辺りはなんとかなってるけども。
でもできれば環境依存コードなWinApi使わないで済ませたいですよね。
そんな感じで、susie代替のビューワ、あとは細かい設定周りと設定画面のui辺り作ったらとりあえず完成かな。
んでも画像ファイルへの関連付けの仕方がwin10以降? から変わったけど、関連付けたファイルのアイコンの設定とかどうやるんだろね。
その辺まだ全然調べてもないや。
いまウチのpcだと、とりあえず代替で使ってた画像ビューワに設定して以降、bmpもjpgもpngもみーんな同じアイコンになっちゃってるんだよな。非対応のavifだけ違うアイコンになってるけど。
拡張子で細かく分けるのとかは、新しい関連付け方式の方だとどうやって設定するんだろね。
できればタイプ別で同じアイコンでも色違いとかにしたいなぁ。
そのへんも調べとかないとな。
Sun
Mon
Tue
Wed
Thu
Fri
Sat
01
02
03
04
05
06
07
08
■
■
アウアウア
09
10
11
12
13
14
■
■
ドツボにはまりすぎてへん
15
16
17
18
19
■
■
なんか妙に時間かかったな
20
[春分の日]
21
22
23
24
25
26
27
28
29
30
31
total:2110225 t:204 y:76
■記事タイトル■
■年度別リスト■
2025年
2025年12月(0)2025年11月(0)
2025年10月(0)
2025年09月(0)
2025年08月(0)
2025年07月(0)
2025年06月(0)
2025年05月(0)
2025年04月(0)
2025年03月(3)
2025年02月(8)
2025年01月(3)
2024年
2024年12月(1)2024年11月(2)
2024年10月(1)
2024年09月(2)
2024年08月(1)
2024年07月(1)
2024年06月(5)
2024年05月(2)
2024年04月(1)
2024年03月(6)
2024年02月(4)
2024年01月(3)
2023年
2023年12月(3)2023年11月(1)
2023年10月(2)
2023年09月(3)
2023年08月(3)
2023年07月(3)
2023年06月(7)
2023年05月(8)
2023年04月(2)
2023年03月(1)
2023年02月(2)
2023年01月(3)
2022年
2022年12月(4)2022年11月(3)
2022年10月(1)
2022年09月(3)
2022年08月(3)
2022年07月(2)
2022年06月(1)
2022年05月(3)
2022年04月(2)
2022年03月(2)
2022年02月(1)
2022年01月(6)
2021年
2021年12月(8)2021年11月(3)
2021年10月(4)
2021年09月(6)
2021年08月(2)
2021年07月(1)
2021年06月(3)
2021年05月(2)
2021年04月(2)
2021年03月(3)
2021年02月(1)
2021年01月(4)
2020年
2020年12月(3)2020年11月(7)
2020年10月(2)
2020年09月(3)
2020年08月(1)
2020年07月(3)
2020年06月(7)
2020年05月(5)
2020年04月(8)
2020年03月(4)
2020年02月(2)
2020年01月(4)
2019年
2019年12月(1)2019年11月(1)
2019年10月(2)
2019年09月(1)
2019年08月(3)
2019年07月(2)
2019年06月(2)
2019年05月(2)
2019年04月(4)
2019年03月(1)
2019年02月(7)
2019年01月(1)
2018年
2018年12月(1)2018年11月(1)
2018年10月(5)
2018年09月(1)
2018年08月(5)
2018年07月(1)
2018年06月(1)
2018年05月(1)
2018年04月(2)
2018年03月(2)
2018年02月(1)
2018年01月(1)
2017年
2017年12月(2)2017年11月(1)
2017年10月(2)
2017年09月(5)
2017年08月(8)
2017年07月(2)
2017年06月(1)
2017年05月(1)
2017年04月(3)
2017年03月(5)
2017年02月(7)
2017年01月(8)
2016年
2016年12月(7)2016年11月(2)
2016年10月(3)
2016年09月(7)
2016年08月(8)
2016年07月(10)
2016年06月(17)
2016年05月(6)
2016年04月(8)
2016年03月(10)
2016年02月(5)
2016年01月(10)
2015年
2015年12月(7)2015年11月(7)
2015年10月(13)
2015年09月(7)
2015年08月(7)
2015年07月(5)
2015年06月(4)
2015年05月(5)
2015年04月(2)
2015年03月(4)
2015年02月(1)
2015年01月(7)
2014年
2014年12月(12)2014年11月(8)
2014年10月(4)
2014年09月(6)
2014年08月(7)
2014年07月(4)
2014年06月(2)
2014年05月(5)
2014年04月(4)
2014年03月(8)
2014年02月(4)
2014年01月(8)
2013年
2013年12月(15)2013年11月(8)
2013年10月(3)
2013年09月(3)
2013年08月(8)
2013年07月(0)
2013年06月(0)
2013年05月(0)
2013年04月(0)
2013年03月(0)
2013年02月(0)
2013年01月(0)
■レス履歴■
■ファイル抽出■
■ワード検索■
堕天使の煉獄
https://rengoku.sakura.ne.jp
管理人
織田霧さくら(oda-x)
E-mail (■を@に)
oda-x■rengoku.sakura.ne.jp

