site logo
新規投稿
*オープンクローズ
 + 
#
thilmera project - forum
不具合
New 設定の表示順序について

みどり 表示順序欄で調整できる「下部の余白」が正しく機能する項目とそうでない項目があります。 再現手順 1. thilmera7_0b181.zipをDLして新規フォルダに解凍してthilmera7-win

 みどり 早速の対応ありがとうございます。 普段利用しているフォルダにもテスト版を上書きしてみましたが、表示順や余白の位置も今までと同じ位置になっていて問題ありません。 ②は仰るとおり設定欄で一覧表示する順番

 Gakuto Matsumura - Developer ありがとうございます。 順序の表示順はともかく、余白に関して内容が一致していなかったのは明らかなバグなので、Rev.1として更新しておきました。 元々、構想としてはもっとグラフィカルに入れ替えでき

25 20:02[3 New]みどり
要望
GeForceRTX Super Resolution Quality Levelの表示要望

retsam もし可能でしたらGPUの表示項目として、GeForceRTXの現在のSuper Resolution Quality Level(1~4)を表示可能に出来ないでしょうか。 検討いただけると幸いです

 retsam 最近のドライバでレベルの自動設定が追加され、動画再生中はNVIDIACP内でアクティブ/非アクティブと現在の適用レベルが表示されるので、可能性があるかと思い要望させていただきました。

 Gakuto Matsumura - Developer NVIDIAのコンパネの件は承知していますが、改めてNvAPIとnvmlのライブラリの最新の内容を、特定の語句ではなく全て確認しましたが、ニュアンスが近いものはディスプレイにおけるハイパーサンプリング

18 21:17[3]retsam
報告
[0ch] 0b180Dr22REV16更新後、横幅が小さくなった

横レス 0chにて、DEV12→DEV16更新後、thilmeraメインウィンドウの表示位置及び横幅などが勝手にリセットされました。 (x,y,hが 0、wが50に変更された模様) モニタ2枚(サイズ違い)の

 Gakuto Matsumura - Developer すみません、ini_history不具合の状況下で、前と後のiniの保持とても助かります。 ただ、古い方のiniでロードしても、正しく幅は137となり、確認できませんでした。 新しいiniは、中身自

 Gakuto Matsumura - Developer こちら、ミスによりテストと同一バージョンで配信してしまいましたが、ch0にて、このテスト版に加えて、可能性として心当たりのある部分の調整をしたものを更新しています。

15 22:01[3]横レス
報告
[0ch] ini_historyフォルダ内に xxxx.backup1900-01-00-000000.iniしかない

横レス #1023 の報告の際、ini差分を取るため ini_historyフォルダをみたところ、デフォルトの14日分が保存されているのを期待したら、以下のファイルしかありませんでした。 (DEV16へのアッ

 横レス 確認ありがとうございます。 テスト版にて、ini_historyフォルダに ini ファイルのバックアップが再起動時の時刻で生成されることが確認できました。 _ 別件(サイズ等のリセット)について

 Gakuto Matsumura - Developer こちら、必ず再現されるというわけでもない印象だったでしょうか? ひとまず、そうなりえる心当たりのある部分を修正したものを、ch0にて更新しておきました。 ちょっとこのテスト版と同じバージョンとして

15 21:59[3]横レス
要望
「時:分:秒 年、月、日、曜日」を独立してフォントサイズを調整したい

thila 「時:分:秒 年:月:日:曜日」これらだけ独立してフォントサイズを大きく調整したいという要望です。 離れた場所からでも見やすくしたい。 windowsで多数ある時刻を大きく表示する手段の中で、よいも

 thila ①日付時刻を除く、そのほか全体はこれまで通りドットフォントで表示したい。 ②一方で、日付時刻の部分は、ドットフォントとOSフォントどちらでも構いません。 この2つを実現するシンプルで理にかなった最適

 Gakuto Matsumura - Developer こちら、ひとまず現バージョンでの不具合収拾のターンでは保留とさせてください。 現状、たとえばドットフォントの中に、OSフォントで必ず表示させる。というのを混ぜることはできますが、行の高さは例外なく固

01/29[3]thila
報告
レイヤード表示時の文字枠が真っ白になる現象について

ナセル=フェレロ バージョンいくつからかはわかりませんが、レイヤード表示時に文字枠が真っ白になる現象を発見しましたので、ご報告いたします。 不具合かどうか判別がつきませんでしたので、項目を報告とさせていただいております

 Gakuto Matsumura - Developer こちら、頂いたiniにて再現され、修正は試みましたが、根本的なソフトウェア描画ルートにおけるレイヤードの計算処理部分とアルファブレンドの双方を作りなおさない限り、まず解決しそうにないことがわかりました

 ナセル=フェレロ 早速の調査ありがとうございます。 レアケースであり、かつ修正が非常に困難であるとのこと、了解いたしました。 将来的な修正の時が来るまで、ご提案の通り、色に2以上の値を指定して対応することにいたします。

01/28[2]ナセル=フェレロ
要望
GPUの温度取得

西東北南 thilmera7では温度表示され難いノートPC用GPU(内臓外付け問わず)について、GPU-Z等では温度を取得出来るケースが散見されます(調べた限りではCPU温度等とは独立の温度計の様です)。 これ

 西東北南 Intelプロセッサー搭載機について、取り敢えず9台分程情報を取ってみました。 [appended] zip

 Gakuto Matsumura - Developer とりあえず、どれ一つとっても、取得そのものがそもそも失敗するか、取得してもall0が返っているかのどちらかなので、何かしら今までにない手法などが必要になる、全く新しいアプローチが必要であるようです。

01/27[35]西東北南
不具合
論理ドライブ表示の不具合・文字枠の太さについて

さた いつもお疲れ様です。 ①#1001の不具合が、描画モード:ハードウェアで再発します。 ②個人的な要望になってしまうのですが、レイヤード使用時の文字枠の太さを、フォントの倍率設定から独立してカスタマ

 Gakuto Matsumura - Developer ちょっと、やってみたらできないかな…と夢みた結果。 まぁ、100回や200回程度のデバッグでこんな根本的なものが実用レベルにできるわけなさそう。

 さた わかりやすく解説&検証していただき本当にありがとうございます。 かなり険しそうですね… 実用上の問題は無いので、文字枠オフにして使用してみます。

01/20[7]さた
不具合
Radeonで消費電力が表示されない

bnmr Win7でRadeonの消費電力が表示されなくなりました。 あまり自信はないですが、0b180r6では表示されていたと思います。 Win10機でもAPU(6800U)のGPU消費電力がうまく表示され

 bnmr HWinfoと並べてみたところ、SVI3 TFNとほぼ同じみたいです。 もしかしたら、極一部のAPU搭載機(SteamDeck等)でしかきちんと取得できないのかもしれません。

 Gakuto Matsumura - Developer こちら、現行のch0にてプレテスト中のものをrev13に展開して、安定した後に取り掛かりますが、正直一人で頑張ったところで答えがなさそうな感じですね。 提案できる点としては、CPUなどのローデータを

01/07[21]bnmr
質問
Radeonのサポートのご支援について

すのー 年末のお忙しい中、アップデートのリリースお疲れ様です。 0b180にて、Radeonが再サポートされ、取得できる値が増えたことをこちらでも確認いたしました。 一方で、以前からRadeonの一部情報が他

 Gakuto Matsumura - Developer とりあえず、hotfix6に、Radeon系のGPUレポートの温度が変になる事への修正のみ適用しておきました。 まぁ、内容についてはじっくり理想形へと調整していけたらと思います。

 すのー かしこまりました。 表示する内容については、私からのサンプル1つだけで決めるのは良くないと思っていたところ、先日友人がRX7600を購入したことを思い出し、情報収集の協力を依頼したので、このデータを確

2023/12/26[11]すのー
質問
常時稼働のサーバー上で稼働し続ける方法はありますか?

patipati 先日はTeamsへのアップデート対応頂き、ありがとうございました。 サーバーOSなどの問題などで、質問してよいのか、憚られましたが、タイトルの通り SVOS(WindowsSV)にて常時稼働(バックグ

 Gakuto Matsumura - Developer コードサイニング証明書のやり取りやら、アップデーターの要件やら、次回の正式リリース準備やらでヒーヒーいってるので、とりあえず来週に予定しているリリースには間に合いませんが、まずはどんなものを想像してい

 patipati 正式リリース及び、バージョンアップ直前の、大変な状況の中お返事いただき、ありがとうございます。 自身の現環境では、GUIがあり、CUIのみで運用しているWindowsSVはありません。(CUI環境下

2023/12/19[2]patipati
要望
ワイヤレスマウスのバッテリー残量表示

あんころ 大変素晴らしいソフトでいつも重宝しております。 厚かましい要望で、技術的に可能かすら分かりませんが、ワイヤレスマウスのバッテリー残量を表示することって出来ないでしょうか? Logicool製のG502

 Gakuto Matsumura - Developer こちら、ちょっとやそっとでは解決しなさそうで、可能かどうかも不明なので、とりあえず現状は半年かかっている次期バージョンの正式リリースを先にさせてください。 次期リリース後に落ち着いたら、改めて下調べ

 あんころ ご連絡ありがとうございます。 お手隙の時にでも検討進めて頂ければ十分です。 よろしくお願いします。

2023/12/16[15]あんころ
質問
マウスオーバー時の操作

犬飼 マウスオーバー時に非表示にしていますが、こうするとシルメラの操作ができなくなります。タスクバーのアイコンを右クリックしても項目が出ず操作不能です。どうすればいいでしょうか。

 Gakuto Matsumura - Developer すみません、"wnd_over_hide = on;"の間違いです。

 Gakuto Matsumura - Developer そういえば忘れていましたが、本体がデッドロック(お互いの終了待ちが発生して無限に待機してしまう)系統のバグが特定の環境で残っている可能性があり、マウスオーバー非表示はそれがでる可能性のある機能なので、

2023/12/03[7]犬飼
報告
Disk I/Oについて

熊倉 実際は書き込み読み出ししていないドライブレターが表示されているように見えます。 できるだけ無駄ディスクアクセスが無くなるようにwindowsを調整してシルメラでモニターしていたのですが、Windows

 Gakuto Matsumura - Developer なるほど。 質問ありがとうございます。 こちら、シルメラが何かしら事実にないドライブアクセスを示している。ということではないです。 0%については小数点切り捨てなので0%とでていますが、ここにE

 Gakuto Matsumura - Developer 書き忘れてましたが、シルメラで採用しているCrystalDiskInfo由来のSMAR取得機構の内部では、デバイスドライバを通したアクセスを各ドライブにしているので、それの内容もアクティビティの中に出

2023/10/17[2]熊倉
テスト
CrystalDiskInfo風のGUIのテスター募集

Gakuto Matsumura - Developer 現在のテストDEV13は、コア部分を含む多くの書き直しや多くの修正がされています。 ・CrystalDiskInfo風のGUIのテスト版。現状CDIに存在しない機能の開発テスト:テスター募集 G

2023/08/03[0]Gakuto Matsumura - Developer
報告
報告とはちょっと違うかもなんですが

龍牙 襄 ここしばらく(すいません、具体的にどういうタイミングからかはわかりません)、CPU使用率が100%で張り付いてしまいます。 PCの起動時から100%でほぼ落ちることはありません。 ただ少々妙なのはタス

 龍牙 襄 すいません。あの後PCを落として離れていました。 タスクマネージャーのCPU使用率の一覧の上位を取ってみました。

 Gakuto Matsumura - Developer あまり不確かなことは言いづらいのですが、見たところIOBit Malware FighterとAvast Serviceという、セキュリティ対策ソフトが2つ以上動いている状態なのではないかと思います。

2023/07/06[7]龍牙 襄
雑談
0b178にアップデートされた際の気づき・質問など

SleepyF 1. 第一階層グループの左から呼べるなど、デザイン変更は概ねよい感じです。 左ペインに第0階層(?)表示がないのは最初少し戸惑いました。慣れの問題かも。 スクロールバーは以前の色・幅の方が好みでし

 SleepyF 設定窓の左ペインや、ソフトウェア描画に関する対応など了解しました。 クリティカルバグの発見につながったのは良かった(?)かもしれませんが、軽い素人レベルの感想を書いたら、あれこれ掘り返す形になっている

 Gakuto Matsumura - Developer いえいえとんでもない。 今回も「こうなります」「うん確かにそう作った…」だったので、こういう所がユーザーに無駄なハードルを課してる部分なんだろうなと… 率直な意見とてもありがたいです。 「予備知識な

2023/05/03[19]SleepyF
要望
Bluetoothデバイスのバッテリー残量の監視は可能でしょうか?

ますお 初めまして。いつもThilmera7には助けられています。 負荷ごとに踊るように変動するCPU使用率のグラフは眺めているだけで癒されます。 さて表題の件ですが、Bluetoothデバイスのバッテリー

 ますお 早速試していただけるとは、確認遅くなって申し訳ありません。 これは…難しすぎますね… 他にバッテリー残量表示するものがあるかな?と検索したところBluetooth Battery Gadgetというフ

 Gakuto Matsumura - Developer そうですね。 Bluetoothのサービスやドライバを完全に弄らない限り、実用に耐えるものはなかなか難しいかもしれません。 手持ちのデバイスが、Classicでは列挙できるが中身はとれないヘッドフォ

2023/03/29[3]ますお
テスト
CPUスレッド数128環境でのテスト

Gakuto Matsumura - Developer CPUスレッド数が65以上のCPU(AMD threadripperの128スレッド)のテスト 該当のCPUをお持ちの方、テストをお願いします。 テスト項目: ・設定のその他>ストレスCPUをオンに

2022/08/24[0]Gakuto Matsumura - Developer
報告
ディスクI/Oの%表示が変?

ANACOSTIA (自動アップデートにより、)いつからか、PC自体がアイドルに使い状態の時でも、[ドライブ]→[ディスクI/O]の%表示の数値(ディスク(ドライブ)のアクティビティ率。転送速度ではなくビジー状態の割合

 Gakuto Matsumura - Developer とりあえず2002-2005年くらいのデータはでてきましたが、やっぱり中身が殆ど私の作曲した曲の話とかですね。 しかも整形スクリプト書かないととてもではないがどこからどこまでが本文かわからん… 20

 Gakuto Matsumura - Developer 認知される切っ掛けになったvectorの初登録が2009/07/20なので、2009/07/20から2009/10/14の3か月弱の間は多分vector上の掲示板が本体ですね。 vectorのコメント

2022/07/27[18]ANACOSTIA
*オープンクローズ
 + 
#
thilmera project - forum
不具合 設定の表示順序について
#1027
New みどり - 2251@uPwZl2PtPwPP2J0wttf0m0/XwuZwg 返信 2024/02/25 15:36
表示順序欄で調整できる「下部の余白」が正しく機能する項目とそうでない項目があります。

再現手順
1. thilmera7_0b181.zipをDLして新規フォルダに解凍してthilmera7-win64.exeを起動
2. 設定→表示順序を開く
3. 「メモリ」の優先度と余白の数値を変更する
 (これは問題なく動作してる)
4. 「ディスクI/O」の数値を変更する
 (優先度を増減させると表示位置は変わるが、余白を増やしても変化がない)
5. 「論理ドライブ表示」の数値を変更する
 (論理ドライブ表示は初期設定OFFなので優先度を増減しても何も変わらないが、余白を増やすと「ディスクI/O」の下に余白ができる)
6. 「論理ドライブ表示」の余白を増やした状態で「ディスクI/O」の優先度を増減してみる
 (実際は「論理ドライブ表示」の余白ではなくて「ディスクI/O」の余白だということが確認できる)

「ディスクI/O」や「論理ドライブ表示」以外にも下部の余白が正しく機能していない項目が複数あるので、全項目に対して確認していただきたいです。

この表示順序欄には実際に見えている項目だけを表示したほうが良いと思います。表示していない項目の順序を入れ替えたいとは思わないでしょうし。(もしくは実際に表示している項目だけを表示するか全項目を表示するかをON/OFFで切り替えられるようにするとか)

また、各項目の優先度を設定するのではなく、各項目をドラッグ&ドロップで入れ替えられるようになると直感的に分かりやすくなると思います。ドラッグ&ドロップできないとしても、優先度を変えてから設定欄を開き直すと各項目の表示順序が実際と同じ並びに入れ替わっていると良いなと思います。

さらに、各項目の余白は下部だけでなく上部も設定できるほうが便利だと思います。各項目が実際と同じ並び順で表示されているのであれば余白は下部だけでもいいと思うのですが、特定の項目の上に余白を作りたいときその上の項目を一覧から探さないといけないのが面倒だと感じました。

New Gakuto Matsumura - Developer 返信 25 17:16
報告ありがとうございます。

余白、そんなのもあったなと忘れてましたが、確認したところ設定上の番号がそのまま設定先の番号になっていたらしく、順序の項目表示と異なる場所が設定先になってました。

① 余白指定の欄が実際の参照先とずれているバグ
余白の設定を、項目名と同一の参照先(スロット番号)に合わせたテストを作成しました。


> 優先度を変えてから設定欄を開き直す
こちらはメインウィンドウの話ではなく、設定欄の方で、現在の順序指定の順番で出てきてほしいということですよね。

試しにこれもテストにて作ってみました。
開いた時(設定ウィンドウ上の設定項目が生成された時)の優先度順(実際に処理される順番とほぼ同等)で並ぶようにしました。

以下テストにて確認して頂けると助かります。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240225-171540.zip



> 表示順序欄には実際に見えている項目だけを表示
それぞれの項目が実際に表示されているかされていないかは、設定内容ベースだと判断が難しく、特定の設定がオンかオフならば表示されるされないという単純なものでもないので、ちょっと実現方法を検討してみます。

恐らく、項目の対象となる分類が、最終的に実際のウィンドウに描画を行ったかどうかを一定期間記録するような方式になるかなと思いますが、対象外フレームではスキップされたりするので、実装ベースを確認しながら確認してみます。

あと、消してしまうと今度は表示切り替えしたのに欄がない!となるのも難しいですね。
なにせキーマップやホットキーでも表示の切り替えがあったり、ハードウェアの状況により消えたり出たりするので…


> 各項目の余白は下部だけでなく上部も設定できるほうが便利
考えてはみますが、現行でもかなり設定欄も実際の中身も複雑なものになっているので、増やす場合にUIの構造をどうするか考えないと、見た時点で「うわー」となる人が増加しそうです。
何かしら完全に作りなおす事も含めて検討してみます。

完全に余白設定の存在そのものを忘れてました…

New みどり - 2251@uPwZl2PtPwPP2J0wttf0m0/XwuZwg 返信 25 18:59
早速の対応ありがとうございます。
普段利用しているフォルダにもテスト版を上書きしてみましたが、表示順や余白の位置も今までと同じ位置になっていて問題ありません。

②は仰るとおり設定欄で一覧表示する順番のことでこれも問題ないと思います。

③は実際に描画された項目だけが設定欄に一覧表示されるのが理想的だと思いますが、今まで要望がなかったのでしょうからそこまで(描画を監視して一定間隔で記録)しなくてもいいのかもしれません。
表示順序欄に全項目を一覧表示するか、それとも(実際に描画しているかは関係なく)各設定がオンの項目だけを一覧表示するかのチェックボックスorスイッチを追加して切り替えできるようにするだけでもいいと思います。

④は②の並び替えで必要性が減ったので実装しなくても問題ないと思います。

設定のUIに関しては見た目と利便性のどちらを重視するかとか好みの問題もあるので何とも言えませんが、個人的にはスライダーを多用しているのが独特だなぁと感じます。
メモリ設定の「K,M,G 単位変更」のように数値以外の選択はプルダウンメニュー(htmlでいえばselectタグ)みたいなので選べるようにしたほうが分かりやすいと思います。

New Gakuto Matsumura - Developer 返信 25 20:02
ありがとうございます。

順序の表示順はともかく、余白に関して内容が一致していなかったのは明らかなバグなので、Rev.1として更新しておきました。

元々、構想としてはもっとグラフィカルに入れ替えできたほうがいいというのはあったのですが、設定ウィンドウのUI上でどう作っていくのかは、対象の項目が今表示されているかを含めて改めて考えてみますね。

プルダウンメニューはなかなか難しく、ごく一部で項目が多すぎるために、OS標準のメニューにて設定する項目とかもありますが、プルダウンやメニューはまだ作れていない部分なので、最終的にどれをプルダウンにするかはともかく、そちらもToDoに追記しておきます。
update
返信

要望 GeForceRTX Super Resolution Quality Levelの表示要望
#1026
retsam - 2247@uPwZP1ZPwwGPP01tX10wlu1Xf2XwmZ2 返信 2024/02/17 22:43
もし可能でしたらGPUの表示項目として、GeForceRTXの現在のSuper Resolution Quality Level(1~4)を表示可能に出来ないでしょうか。
検討いただけると幸いです

Gakuto Matsumura - Developer 返信 17 23:33
ありがとうございます。

一応、NVIDIAコンパネ上のRTXのSuper Resolutionが、アクティブとなる状態にできるようにはしてみましたが、軽く調べた限りで、このSuper Resolutionの情報を取るような明確な手段が見つかりませんでした。

ちょっと改めて調べてはみますが、現時点で取れるものなのかは不明です。
Intel Arcの方はまさにそれそのものっぽいのが見つかりました。

retsam - 2246@uPwZP1ZPwwGPP01ttPwt/lXuPwXPXJ/ 返信 18 11:32
最近のドライバでレベルの自動設定が追加され、動画再生中はNVIDIACP内でアクティブ/非アクティブと現在の適用レベルが表示されるので、可能性があるかと思い要望させていただきました。

Gakuto Matsumura - Developer 返信 18 21:17
NVIDIAのコンパネの件は承知していますが、改めてNvAPIとnvmlのライブラリの最新の内容を、特定の語句ではなく全て確認しましたが、ニュアンスが近いものはディスプレイにおけるハイパーサンプリングというものくらいでした。

これはSuper Resolutionではなく、NVIDIA Image Scalingというモニターにおける倍率指定の方のようです。

Super Resolutionの方は、GPUの情報を取得するライブラリとは全く異なる、DLSSなどの、ガッチガチに超解像度に関するエリアにあるらしいです。

こちらでは、SuperSampling、VideoSuperResolution、ImageSuperResolutionなどが定義名に含まれるものがあるので、多分このあたりだとは思うのですが、現状では正直、NVIDIAの標準的に存在するライブラリに、これの状態をくださいな、といったら数値が返ってくるような簡単なものではなさそうな印象です。

調べるにしても、いずれ対応するにしても、単に追加すればすぐできる類ではなさそうなので、こちらは将来的に対応できるか検討していく、という感じになりそうです。
update
返信

報告 [0ch] 0b180Dr22REV16更新後、横幅が小さくなった
#1024
横レス - 2213@pAEf4Ihy 返信 2024/02/15 13:40
0chにて、DEV12→DEV16更新後、thilmeraメインウィンドウの表示位置及び横幅などが勝手にリセットされました。
(x,y,hが 0、wが50に変更された模様)
モニタ2枚(サイズ違い)の環境で、左:メイン、右:サブ、メインで右上固定で使用しています。
DEV16の ini (本コメントに添付)とDEV12 のini を添付します。
また、ini_history フォルダの中身がおかしなことになっているので、別途報告します。

[appended] ini

横レス - 2213@pAEf4Ihy 返信 15 13:43
DEV12での ini を添付します。


[appended] ini

Gakuto Matsumura - Developer 返信 15 17:26
すみません、ini_history不具合の状況下で、前と後のiniの保持とても助かります。

ただ、古い方のiniでロードしても、正しく幅は137となり、確認できませんでした。
新しいiniは、中身自体が0,0,50,0という、初期値+最低保証値となっていました。

念のため、#1025における以下にて、再度確認をお願いします。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240215-171928.zip

Gakuto Matsumura - Developer 返信 15 22:01
こちら、ミスによりテストと同一バージョンで配信してしまいましたが、ch0にて、このテスト版に加えて、可能性として心当たりのある部分の調整をしたものを更新しています。
update
返信

報告 [0ch] ini_historyフォルダ内に xxxx.backup1900-01-00-000000.iniしかない
#1025
横レス - 2213@pAEf4Ihy 返信 2024/02/15 13:57
#1023 の報告の際、ini差分を取るため ini_historyフォルダをみたところ、デフォルトの14日分が保存されているのを期待したら、以下のファイルしかありませんでした。
(DEV16へのアップデート直後に作られたバックアップの模様)

thilmera7.backup1900-01-00-000000.ini
thilmera7.upd.channel.backup1900-01-00-000000.ini
thilmera7key.backup1900-01-00-000000.ini
thilmera7uac.backup1900-01-00-000000.ini

なお、気付いたのがDEV16の更新時であり、いつからこの状態かは不明です。
(ini は #1023 と同じのため省略します。)

Gakuto Matsumura - Developer 返信 15 17:22
報告ありがとうございます。

こちら、たしかにそのようになっていました。
いつの時点からかの、設定をロードするタイミングを移動しなければならなかった修正の影響で、全体で共通とする時刻の取得がされる前の内容でファイル名が決定されていたようです。
メイン、サブのリリース、デバッグ全てその状態だったので、結構前からかと思います。

こちら以下にて修正しました。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240215-171928.zip

横レス - 2213@pAEf4Ihy 返信 15 19:43
確認ありがとうございます。

テスト版にて、ini_historyフォルダに ini ファイルのバックアップが再起動時の時刻で生成されることが確認できました。

_
別件(サイズ等のリセット)については、しばらく様子を見ます。
取り急ぎ、ご連絡まで。

Gakuto Matsumura - Developer 返信 15 21:59
こちら、必ず再現されるというわけでもない印象だったでしょうか?

ひとまず、そうなりえる心当たりのある部分を修正したものを、ch0にて更新しておきました。

ちょっとこのテスト版と同じバージョンとして出してしまったので、このテスト版のままの場合は更新をお願いします。
update
返信

要望 「時:分:秒 年、月、日、曜日」を独立してフォントサイズを調整したい
#1011
thila - 2244@gzcx1M/S 返信 2024/01/26 15:16
「時:分:秒 年:月:日:曜日」これらだけ独立してフォントサイズを大きく調整したいという要望です。
離れた場所からでも見やすくしたい。

windowsで多数ある時刻を大きく表示する手段の中で、よいものがなかなか見つからなかったため、シルメラで代用したいと考えました。

フォントサイズ設定オプションで、これら日付時刻秒についてのみ独立して大きくしたり、小さくしたり自由にできる感じです。

可能であればよろしくお願いいたします。

Gakuto Matsumura - Developer 返信 01/26
こちら、ドットフォントとOSフォントどちらを想定していますでしょうか?

thila - 2244@gzcx1M/S 返信 01/26
①日付時刻を除く、そのほか全体はこれまで通りドットフォントで表示したい。
②一方で、日付時刻の部分は、ドットフォントとOSフォントどちらでも構いません。

この2つを実現するシンプルで理にかなった最適な構成でかまいません。
お任せします。

Gakuto Matsumura - Developer 返信 01/29
こちら、ひとまず現バージョンでの不具合収拾のターンでは保留とさせてください。

現状、たとえばドットフォントの中に、OSフォントで必ず表示させる。というのを混ぜることはできますが、行の高さは例外なく固定という仕様であるため、そのあたり含めて、複数のフォントとフォントサイズが混在できるような仕組みが必要な気がします。

日付に関しても、非常に多くの表示パターンがあるので、作るならば、根本的にそれぞれの項目の文字サイズを、無段階は難しいとしても、大・小から選べる。というような感じがよいかと思います。


主要なバグの修正が収まった後、あらためて作っていきます。
update
返信

報告 レイヤード表示時の文字枠が真っ白になる現象について
#1013
ナセル=フェレロ - 2130@t3z6EJ/S 返信 2024/01/26 23:44
バージョンいくつからかはわかりませんが、レイヤード表示時に文字枠が真っ白になる現象を発見しましたので、ご報告いたします。
不具合かどうか判別がつきませんでしたので、項目を報告とさせていただいております。
もし不具合でしたら、ご対応いただけますと幸いです。

◆現象について
カラー設定の「base background1」がRGB値 0,0,0の時に限り発生。
裏側のウィンドウや要素などが明るい色の場合、その明るさ度合いに応じて白くなっていきます。
「text」が明るい色もしくは白(255,255,255など)の場合、最終的に文字が読み取れなくなります。
ただし、最低でもRGB値の内どれか1項目でも1以上ある場合は白くなりません。

◆確認した現象
・裏側のウィンドウ等が明るい場合で、「base background1」0,0,0の場合
バー、バー背景にかかっていない部分(裏側のウィンドウが見える場所)の文字枠が白くなる。
明るさによって発生の度合いが変化、特に白に近いほど真っ白になっていく。
バー、バー背景などにかかっている部分は通常通り暗い縁がついて読みやすいまま。
※テキストなど部分的に暗いものが重なっていると、重なっている形に合わせて文字枠が暗くなっています。

・裏側のウィンドウ等が暗い場合で、「base background1」0,0,0の場合
バー、バー背景にかかっていない部分(裏側のウィンドウが見える場所)の文字枠は暗く表示されている。
※テキストなど部分的に明るい部分が重なっていると、重なっている形に合わせて文字枠が明るくなっています。

・裏側のウィンドウ等が明るい場合で、「base background1」0,0,0ではない場合
特に問題なく「base background1」の指定色またはその近似色で縁がついていて見やすい状態が維持されています。

・裏側のウィンドウ等が暗い場合で、「base background1」0,0,0ではない場合
特に問題なく「base background1」の指定色またはその近似色で縁がついていて見やすい状態が維持されています。

◆添付ファイル
・ブラウザで背景が真っ白(#ffffff)の時のThilmeraのスクリーンショット
・ブラウザで背景がダークグレー(#666666)の時のThilmeraのスクリーンショット
・Thilmeraの設定ファイル
※スクリーンショットは、右側の端にスクロールバーがThilmeraに重なっています。

[appended] zip

Gakuto Matsumura - Developer 返信 01/27
こちら、頂いたiniにて再現され、修正は試みましたが、根本的なソフトウェア描画ルートにおけるレイヤードの計算処理部分とアルファブレンドの双方を作りなおさない限り、まず解決しそうにないことがわかりました。

判明した問題が発生するメカニズムとしては、レイヤードにおける背景色が、OSのレイヤード計算に必要な減算の結果、最終がALL0のドットになってしまい、色が一切ない完全な透明ピクセルとして処理されてしまう。というものです。

たしかに確認した限りでは、いずれかのRGB値が2以上の場合は発生しないものでした。

「ソフトウェア描画+レイヤード+背景色の指定がALL0+文字枠」でのみ発生する特殊なケースなので、将来的にはなんとかしたいと思いますが、0b180系の修正に組み入れると、根本的な手直しによる副作用の修正が終わらなさそうなので、現段階ではすみませんが、背景色を0,0,2などにしてしのいでもらえると助かります…

ナセル=フェレロ - 2130@t3z6EJ/S 返信 01/28
早速の調査ありがとうございます。
レアケースであり、かつ修正が非常に困難であるとのこと、了解いたしました。
将来的な修正の時が来るまで、ご提案の通り、色に2以上の値を指定して対応することにいたします。
update
返信

要望 GPUの温度取得
#997
西東北南 - 2234@PPwZl1Pw2g1GPP20uw1Z201lJu2X1/Z 返信 2024/01/16 02:09
thilmera7では温度表示され難いノートPC用GPU(内臓外付け問わず)について、GPU-Z等では温度を取得出来るケースが散見されます(調べた限りではCPU温度等とは独立の温度計の様です)。
これらをGPU温度として取得して表示する事は出来ないでしょうか?

Gakuto Matsumura - Developer 返信 01/16
ノートPC用GPU(内臓外付け問わず)というのが、NVIDIAなのか、AMD Radeon Graphicなのか、AMD Radeonなのか、Intel HDなのか、Intel Arcなのかによって全く異なるので、まずは具体的にハードウェアのどれのことで、どんな情報であるのかを教えて下さい。

Gakuto Matsumura - Developer 返信 01/16
ひとまず、レポートウィンドウのGPU情報の結果をコピーしたtxtファイルと、そのうちのどの部分のことか。
加えて、GPU-Zなどのスクリーンショットなどから、見えているどの情報のことを言っているのかをzipファイルなどにして添付して頂けると助かります。

西東北南 - 2234@PPwZl1Pw2g1GPP20uw1Z201lJu2X1/Z 返信 01/16
現在同様の状況を確認しておりますのは
HD Graphics P530
HD Graphics 620
Quadro M2000M
Radeon Vega 8
です。
P530+M2000Mの環境でのthilmera7スクリーンショット、GPU-ZでのM2000Mのスクリーンショット、上記四種のGPU(PC3台分)のGPU情報テキストを共有致します。
例としてM2000Mの物を載せましたが、全てのGPUについて、GPU-Z上で温度が表示されておりました。

[appended] zip

Gakuto Matsumura - Developer 返信 01/16
とりあえず、HD Graphicsはともかく、他は見たことすらないので、当然それらのハードウェアの報告があったのはこれが初めてかと思います。

Intel HDは、まず下調べから初めていますが、今のところ有益な情報は見つかっていません。

Quadraは多分NVIDIAのごついやつですよね。
こちら、system32以下に、nvapiやnvmlといったライブラリは存在していますか?

Radeon Vega 8は、多分AMD Radeon Graphicsですよね。
こちら、system32以下にatiadlxxやatiadlxyのライブラリは存在していますか?

西東北南 - 2234@PPwZl1Pw2g1GPP20uw1Z201lJu2X1/Z 返信 01/16
Quadroはごついやつ、のMXM(ノートパソコン用規格)版です。Radeonは仰る通りCPU内蔵版です。
どちらもwindows/System32直下にはございませんでした。

Gakuto Matsumura - Developer 返信 01/16
なるほど。

どちらも、それらのライブラリがない場合、温度の取得ができるルートは現状、存在していません。

正式なライブラリ以外から、全く別の手段で取得する方法があると思いますが、実機があってもできるか謎ですし、無い場合確認の手段が無いので、一応本来のライブラリなしに取得する手段などは調べてはみますが、QuadroとRadeonは、それぞれのドライバ付属のライブラリがあれば普通にとれそうな気はします。

Gakuto Matsumura - Developer 返信 01/16
GPUレポートの中身をみるかぎり、Radeon Vega 8については単位が化けてますが、79℃とでています。

Gakuto Matsumura - Developer 返信 01/16
NVIDIA Quadro M2000Mに関しては、少なくともライブラリは存在しているらしき結果になっています。

こちらのテスト版にて出力される、"debug_log.GPU.txt"を添付してほしいです。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240116-040642.zip

ライブラリがないと取れるはずのない一部のデータがレポートに出ているので、どこまでいっていて、どこでつまっているのかが解決できたら、取れはするものならば解決するかもしれません。

西東北南 - 2234@PPwZl1Pw2g1GPP20uw1Z201lJu2X1/Z 返信 01/16
ご提示頂いたファイルで取得したデバッグログを添付致します。

[appended] txt

Gakuto Matsumura - Developer 返信 01/16
ありがとうございます。

なんだろう…見たことない挙動してますね。
理論上、ここまでいけてれば普通に出るはずなんですが、とれている部分から先にログ出力のポイントを増やしました。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240116-050433.zip

ちょっと一度寝ます。

西東北南 - 2234@e1qilg1c 返信 01/16
お疲れ様です。
新たに取得したデバッグログを添付致します。

[appended] txt

Gakuto Matsumura - Developer 返信 01/16
ありがとうございます。

ここまでくると、あとは成功した中身がどうなっているかくらいのような…

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240116-111144.zip

こちらの結果と、"thilmera7.ini" を下さい。
もしログにはてでいて、かつ表示されない場合、設定ファイルがあれば理由がわかるかもしれません。

西東北南 - 2234@e1qilg1c 返信 01/16
こちら、出力したログ、及びその際のthilmera7.iniになります。

[appended] zip

Gakuto Matsumura - Developer 返信 01/16
どうやら、温度取得は正しく成功して、かつ0が返ってきているようですね。

優先、予備1が共に0となっているようです。
予備1でも0がかえってきた場合に、一時的にレガシーをさらに呼び出すようにしました。
少なくとも成功しなかったとしてもレガシーで何と返るかはログにでるはずです

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240116-133926.zip

Gakuto Matsumura - Developer 返信 01/16
すみません、ログ出力フラグ忘れてビルドしてました。
こちらでお願いします。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240116-134330.zip

西東北南 - 2234@e1qilg1c 返信 01/16
出力されたログファイルです。>すみません、ログ出力フラグ忘れてビルドしてました。
>こちらでお願いします。
>repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240116-134330.zip

西東北南 - 2234@e1qilg1c 返信 01/16
こちらです(フェッチエラーで送信出来なかった)

[appended] zip

Gakuto Matsumura - Developer 返信 01/16
ありがとうございます。
レガシーからは温度が取れているようなので、再編成して、優先、ライブラリ、レガシーの3種のうち、有効と思われるものを選択し、上位でとれずに下位でとれる場合、上位をスキップするようにしてみました。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240116-165045.zip

恐らくNVIDIAの温度は復活すると思います。
あと、温度の他のファンとワット数は、ログへの追加などをしています。
結果をみて、取れそうならば調整していきます。

Gakuto Matsumura - Developer 返信 01/16
以下IntelHD向けのログを追加した分になります。
Intel HDに関しては、古いノートを出して調べようとしましたが、Win8.1であったため機能そのものがなく、直接試すことができない状態になっています…

DEV6GPULOG
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240116-231957.zip

西東北南 - 2234@2PPZX/Zg0GG0f/221fZgPJJmgw2t/Jf 返信 01/17
こちら、231957の方のログファイルになります。
画面上ではnvidiaの温度表示復活を確認出来ました。

[appended] txt

Gakuto Matsumura - Developer 返信 01/17
ありがとうございます。

NVIDIAのQuadraについては、温度とクロック数はとれていて、ワット数とファンは失敗日してますが、gpu-zのスクリーンショットでもワット数やファン速度は項目自体がなかったので、おそらく元々取れないのだと思います。
Quadraに関してはこれでOKかなと思います。

Intel HDの方は、いくつか施策はしましたが、やはり取得は成功して、かつ温度0が返ってきていました。

Intel HD Graphicsの温度もgpu-zなどでは取れている状態でしょうか?

あと、他の環境におけるVega 8の方でも、同様にテストによるログを作成してほしいです。

西東北南 - 2234@PPwZl1Pw2g1GPP2022w1wJt/0tJ2lZ2 返信 01/17
こちら、GPU-Z上でのHD Graphicsセンサーデータです。
CPU温度とは別にGPU温度を取れている模様です。

西東北南 - 2237@BS3Hqiem 返信 01/17
こちらはVega 8搭載機で、最後にご提示頂いたファイルを実行したログになります。

[appended] txt

Gakuto Matsumura - Developer 返信 01/18
> こちら、GPU-Z上でのHD Graphicsセンサーデータです。
> CPU温度とは別にGPU温度を取れている模様です。
成功しているのに全て0を返しているやつが、もし正常に取れていたら、とれる情報の項目もこんな感じですね…
OSのバージョンはWin10以降か未満かどちらでしょうか?


Vega 8の方は、こちらは上記のIntel HDで想定しているものがとれていない方で、温度とクロック数はとれているようです。ファンとワット数は0。

あと、ことごとくライブラリの呼び出しはエラーがかえってきて、最も古いものすらエラーとなっているようです。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240118-002033.zip

とりあえず、こちらのテストでは、最終結果がどうなったかのログと、ライブラリとは別由来のデータが有効、かつライブラリ由来がない場合に結果を上書きするようにしました。
NVIDIAの時の修正と、補正する側される側が逆のパターンになります。

西東北南 - 2237@BS3Hqiem 返信 01/18
こちらログファイルです。
exeファイルを実行した所、画面上でも温度が表示されました。

[appended] txt

Gakuto Matsumura - Developer 返信 01/18
ありがとうございます。
Vega 8のほうはよさそうな感じですか?

温度は別由来で補正。クロックはライブラリ由来。
それぞれ単位(50度なのに5度とか500度とか5000度とかになってたり)がおかしくなければ実用には耐えれると思います。

これで、Quadraと、Vega 8はOKなので、あとはIntel HDがなぜかこのVegaではとれているのに取れてないという謎やつですね。
Intel HDの機体の方はOSのバージョンはどうなっていますか?

Gakuto Matsumura - Developer 返信 01/18
過去のログファイルを見ると、OSのバージョンが足りてないければ到達していないものがあったので、何かしらの他の問題のようです。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240118-234817.zip

とりあえず今度はIntel HD Graphicsをターゲットにしたログ出力を増やしました。
ここが解決すればGPU3種クリアとなるので、もう少しお付き合いお願いします。

西東北南 - 2234@PPwZl1Pw2g1GPP20uPfumZwmttuutfPw 返信 01/19
はい、見た限りVega 8は大丈夫そうです。
こちら、HD搭載機で出力したログファイルになります。
併載しているQuadroの温度は出ましたが相変わらずHDの方は無しです。
OSは19045.3930(22H2)です。

[appended] txt

Gakuto Matsumura - Developer 返信 01/19
こちら、そうでした。
全て成功していて、エラーも返ってきていないのに、中身は0。という問題だったのを失念していました。

ちょっと確認と試すべき方向性がわからないので、一度win8.1の古いIntelノートにデュアルブートでwin10をいれたので、こちらで一度確認と試せるものを試したら、改めてどうするか考えます。

見るのはgpu-zさんでいいんでしたっけ。

西東北南 - 2234@Wtjm1qVX 返信 01/19
はい、TechpowerのGPU-Zをインストールして参照しております。

Gakuto Matsumura - Developer 返信 01/20
こちら、古いIntelHDノート実機に無理やりWin10をいれて実験してみたところ、そもそも今回のアップデートによるミスではなく、過去今まで取れた事は一度もない。ということがわかりました。

gpu-zさんの中身がどうなってるのかはわかりませんが、それ以外のいくつかのHW情報系をみても、そもそも取れてませんでした。

西東北南さんの環境ではエラーがでていなくて0が返っているのに対し、このテストしたIntelHDノートでは明確なエラーを返しているので、同一の問題かはわかりませんが、ちょっと修正を行う、という程度の調査と難易度ではなさそうな感じです。

恐らく、ざっと調べた限り、レガシーなIntel HDでなければ問題なく出るような気はするのですが、これがIntel HD(UHD)の全てで見れていないのか、レガシーのみの問題なのかによって、今後の方向性も変わりそうです。

ひとまず、今回の0b180のリフレッシュ更新としては、Intel HD、またはレガシーなIntel GPUへの対応は一旦保留とさせてください。

現行ラインナップのIntel UHDで見れてるのか見れてないのか知りたいなぁ…

西東北南 - 2234@BS3Hqiem 返信 01/20
了解致しました、調査ありがとうございます。
タイミングを見て他のintel系CPUマシンにもthilmera7を入れてみて、何件か結果が纏まりましたらいずれご報告させて頂こうかと思います。

Gakuto Matsumura - Developer 返信 01/20
ありがとうございます。

今回の0b180シリーズへの修正としては、なるべくトラブルを収束させる方向に行く必要があるので、0b180シリーズの修正ができたら、改めてch0の方でこちら進めていきます。

どのみちドットフォントの日本語を含めた全てのキャッシュの生成なども計画しているので、そのあたり、枠と枠の幅の件も含めてトータルで作っていきます。

西東北南 - 2214@BS3Hqiem 返信 01/27
Intelプロセッサー搭載機について、取り敢えず9台分程情報を取ってみました。

[appended] zip

Gakuto Matsumura - Developer 返信 01/27
とりあえず、どれ一つとっても、取得そのものがそもそも失敗するか、取得してもall0が返っているかのどちらかなので、何かしら今までにない手法などが必要になる、全く新しいアプローチが必要であるようです。

UHD Graphics 600台は失敗してないが全て0。
HD Graphics系はそもそも失敗していて取得自体走ってない。
update
返信

不具合 論理ドライブ表示の不具合・文字枠の太さについて
#1004
さた - 2238@2PPZXgfZ22m0Z/XZ0ul2PGmmJ0Gf2g 返信 2024/01/20 18:16
いつもお疲れ様です。

①#1001の不具合が、描画モード:ハードウェアで再発します。

②個人的な要望になってしまうのですが、レイヤード使用時の文字枠の太さを、フォントの倍率設定から独立してカスタマイズできるようにする事は可能でしょうか?

Gakuto Matsumura - Developer 返信 01/20
①が再現されるのが、どのバージョンであるのかを教えて下さい。
現行の最新テストでハードウェア描画を確認してみましたが、再現はされませんでした。

現行最新は、DEV20となっています。

②に関しては、まずどのモード(ハードウェア描画なのかソフトウェア描画なのか)の何フォント(OSフォントかドットフォントか)を何の倍率(x1なのかx2なのか)でつかっていて、それの枠を具体的にどうしたいのかを教えて下さい。
それぞれで形式も内容も異なります。

Gakuto Matsumura - Developer 返信 01/20

さた - 2238@2PPZXgfZ22m0Z/XZ0ul2PGmmJ0Gf2g 返信 01/20
①本当にすみません。DEV18のままでした。修正ありがとうございます。

②について、私が色々と勘違いをしておりましたので一旦整理させてください…

普段はソフトウェア描画を使用しております。
フォントは03x05.bmpで倍率は2倍です。

ハードウェア描画に設定している時にフォントン倍率を2倍・3倍等に設定しても、文字枠の太さが変わらないのですが、ソフトウェア描画に設定していると文字枠の太さも2倍・3倍になります。(画像を添付しています。)色も薄くなっていると思います。

使用する方によって異なると思いますが、私はフォントの倍率を変更しても文字枠の太さを細いまま維持してほしいなと思っています。
なので、「倍率に合わせて文字枠も太くする」のような設定がほしいな、という要望でした。
これについては、ハードウェア描画に設定することで解決できました。

それを踏まえて、ソフトウェア描画に設定している時に文字枠も太くなるのが正しい動作なのか確認したいです。

さた - 2238@2PPZXgfZ22m0Z/XZ0ul2PGmmJ0Gf2g 返信 01/20
重ねてすみません、スクリーンショットの画像がDEV14を使用してしまっていますが、私の環境のDEV20DSKLOGでも再現できました。

Gakuto Matsumura - Developer 返信 01/20
ややこしくてすみません。

ハードウェア描画はDirect2Dという、既存のプラットフォームの上で動くもので、対してソフトウェア描画は全て自前のコード上でドットを計算して出力するものです。

前者は画像のオブジェクトや図形で書くのに対し、後者は全てCPUで完結したメモリ計算となります。

ハードウェア描画とソフトウェア描画は、だいたい似たような感じになる事を目指しはしたが、やってる事や内容は根本から全く異なるルートを1から別々に作成しているという感じになります。

色が薄い、というのに関しては、レイヤードにおいては、ソフトウェア描画とハードウェア描画では、半透明やブレンドだけでなく、計算方法も最終的に指示する色(RGB値)そのものも全く異なるので、こちらも現状、色の濃さくらいは多分調整できそうな気はしますが、どんな設定と色においてもハードウェア描画とソフトウェア描画を同一にするのは、受け付けてくれる値そのものが異なる点からもかなり困難です。

どちらか正しいのか。に関して確認したところ、元々は倍率に関わらず1pxの周囲で、0b180系のソフトウェア描画における文字枠の新仕様で今回の形になっています。
調整はしてみようとはしましたが、恐らくここは一日や二日でできるような規模ではない上に、幅の調整をできるようにするとなると、ソフトウェア描画もハードウェア描画も根本的に作り直し、となるので、0b180のリフレッシュとしては見送りかな…と思います。

ハードウェア描画は作ってはみたけど、既存ユーザーには不評。かつだいたいのケースでソフトウェア描画より総合的な負荷(CPU+GPUの総計)が高いです。
ハードウェア描画の利点は、綺麗である事と、最初からレイヤードの区別がない。くらいしかアドバンテージがないのが現状です。

今後ハードウェア描画の方は、逆になるべく負荷をかけたくないGPU側の負荷を増やすことになってしまうので、0b180系からはハードウェア描画でなくソフトウェア描画がメインストリームに戻っていて、今後はソフトウェア描画のさらなる高速化を進めていく予定となっています。

レイヤードと非レイヤードも別物ですし、OSフォントとドットフォントも別物です。
ソフトウェアかハードウェアかも含めると、2の3乗分が全て異なる。ということになります。

今回の幅などの話に関しては、ソフトウェア描画+レイヤード+ドットフォント+倍率2以上の設定が揃わない限り、そもそも画面に出てきません。

Gakuto Matsumura - Developer 返信 01/20
ちょっと、やってみたらできないかな…と夢みた結果。
まぁ、100回や200回程度のデバッグでこんな根本的なものが実用レベルにできるわけなさそう。

さた - 2238@2PPZXgfZ22m0Z/XZ0ul2PGmmJ0Gf2g 返信 01/20
わかりやすく解説&検証していただき本当にありがとうございます。
かなり険しそうですね…

実用上の問題は無いので、文字枠オフにして使用してみます。
update
返信

不具合 Radeonで消費電力が表示されない
#992
bnmr - 2218@uPwZZ1Z2gwwPP/GZ0ww10Xtu0t1twwl 返信 2023/12/29 03:45
Win7でRadeonの消費電力が表示されなくなりました。
あまり自信はないですが、0b180r6では表示されていたと思います。

Win10機でもAPU(6800U)のGPU消費電力がうまく表示されません。(%表示)
以前はWattage ASICが表示されていたと思います。

[appended] zip

Gakuto Matsumura - Developer 返信 2023/12/29
すげぇ。話の本筋と関係ないですが、ADLの結果でCPUの温度、ワット、クロックがとれてる結果初めてみました。ワットとクロックは見る限り使えるか謎ですが、温度は多分完璧…。
箱は用意されてはいるけど、多分とれはしないんだろうなぁ…と思ってましたが、とれる環境が存在するならば、ややこしいカーネルドライバやらRyzenMaster周りを全部ぶち抜いて、非管理者権限からGPU情報経由でAMD-CPUの温度出せそうですね…
ちょっと実際にデータが出る環境がある、ということが判明したのは滅茶苦茶でかいので、今後ここも実装していきます。

本題の方、原因は、Wattage SOC の数値が優先されるが、有効フラグがあるのに中身が0。となっているため、結果としての0は数値とれなかった扱いとなる感じかと思います。
ここ、確かにハンドリングとしては問題なので、少なくともメインに表示する数値は、優先度+中身が0ではないを条件に変更してみました。

以下テストをお願いします。ログ出力を含みます。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win32_win64_20231229-125813.zip

bnmr - 2218@uPwZZ1Z2gwwPP/GZ0ww10Xtu0t1twwl 返信 2023/12/29
確認の失敗:FV1 で7,10共に起動しませんでした。

少し検証したところ、Wattage GFXはたまにそれっぽい数字を返しますが、Watt CPUは負荷時に2~3wになるだけで、あまり役に立たなそうでした。

Gakuto Matsumura - Developer 返信 2023/12/29
そのエラーは単純にネットワークドライブなどの、セキュリティ上動作しない場所に配置されているのが原因だと思われます。

元々のリリースが置かれている場所と同条件(ローカルの固定ドライブ)な場所に移してもう一度試してみてください。

bnmr - 2218@uPwZZ1Z2gwwPP/GZ0ww10Xtu0t1twwl 返信 2023/12/29
ちゃんと起動しました

[appended] zip

Gakuto Matsumura - Developer 返信 2023/12/29
ログ見る限りでは、直せていそうな感じですが、表示の方は直っていますか?

bnmr - 2218@uPwZZ1Z2gwwPP/GZ0ww10Xtu0t1twwl 返信 2023/12/29
ちゃんと動いているみたいです。
Wattage GFXは乱高下してあまり良くなさそう...

Gakuto Matsumura - Developer 返信 2023/12/29
ちょっとそこまでいくと、修正というよりは次のバージョンにむけての新たな調整の開始のようなものになるので、現状できることとしては、どの数値を採用するかを手動で指定する詳細オプションのようなもの…しか思いつきませんでした。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win32_win64_20231229-182057.zip

まずは現状はこれで今回は凌ぐ。という感じでどうでしょうか?

Gakuto Matsumura - Developer 返信 2023/12/29
まぁ、正直乱高下する一番の原因は、パッシブモードかつ更新レートがあまりにも速すぎるからだと思います。

Gakuto Matsumura - Developer 返信 2023/12/29
更新タイミングはかえたくない。ということなら、もしかしたらパッシブでなくすだけで一発で解決しそうではあります。

Gakuto Matsumura - Developer 返信 2023/12/30
ch0=DEV更新しました。DEV6
一応単体テスト用のコピーは以下になります。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win32_win64_20231230-004945.zip

bnmr - 2218@uPwZZ1Z2gwwPP/Gf20Xmfw/m0fw1f1 返信 2023/12/30
DEV6で設定を変えたりして試しましたが、むしろCPU電力と近い結果になりました。
ゲームでは瞬間的に40wを超えた直後に3wまで落ちたり、かなり不安定です。

[appended] zip

Gakuto Matsumura - Developer 返信 2023/12/30
ええと、まず話を整理させてください。

>DEV6で設定を変えたりして試した
これは各スロットどれを選んでも望む数値は得られなかった。といことでしょうか?
つまり、追加した設定である、ADL detailのWattage Slotを1から4まで全て試したが、どれも望む数値ではなかった。ということですか?

冒頭でWattage ASICを出したい。という話がありましたが、元々のメンテ無し時代はそもそもルートの稼働すらできなかったため、たしかにそれを優先していましたが、これがAPUにおけるパッケージの電力であるらしい。というのは知っています。

なので、ASICを参照する優先度は最も低いものとなります。
手動でASICを選んだ場合、他アプリのCPUと同等になるのはとても正しい挙動です。

あと、前回尋ねていた、パッシブを切ったら一発で解決するのでは?というのは確認されましたでしょうか?

前バージョンはパッシブ状態ではないため、これをオフ(デフォルト設定ではオフです)にして直らず、かつ前バージョンでは正しく表示されている。ということなのか、それとも元々のバージヨンでもできていなかったものを今改めて検討しているという話なのか、どちらでしょうか?

すなわち、緊急のバグフィックスなのか、今後の要望なのか。ということになります。

Gakuto Matsumura - Developer 返信 2023/12/30
とりあえずGFXのワット数に関しては、まず真っ先にパッシブログをきってもそうなるか、を試してください。

bnmr - 2218@uPwZZ1Z2gwwPP/Gf20Xmfw/m0fw1f1 返信 2023/12/30
設定の変更で試したことは、パッシブログ・取得する数値・更新頻度 です。

結果は
・更新頻度は関係なし
・パッシブログは有効/無効どちらも変化なし
・ASICは一番まとも(ちゃんと動く)

といった感じでした。

Gakuto Matsumura - Developer 返信 2023/12/30
CPUのワット数に近い結果となる。というのは、ASICの話ではないという事でしょうか?

CPUのワット数に近いのがどのスロット指定かはわかりますか?

bnmr - 2218@uPwZZ1Z2gwwPP/Gf20Xmfw/m0fw1f1 返信 2023/12/30
GFX Wattageです、Radeon softwareのCPUとほぼ同じでした。

bnmr - 2218@uPwZZ1Z2gwwPP/Gf20Xmfw/m0fw1f1 返信 2023/12/30
もしかしたらRadeon softwareでGPU電力がASICなのは、GFX Wattageがまともに動かないから、なのかもしれません。

すのー - 2220@PPwZZ1PwZ/lPPu0Pm0mm2fmPt0mJ/2m 返信 2023/12/30
横レス失礼いたします。
私は3700X+5500XTという構成ですが、AMD SoftwareのCPU Powerは、HWiNFOのCPU Core Power (SVI2 TFN)と一致しています。
Wattage GFXはGPUユニット全体ではなく、GPUのシェーダーユニット単体での値ではないかと予想しておりますが、Wattage GFXはCPU Powerとどれくらい近いですか?

Gakuto Matsumura - Developer 返信 2023/12/30
>ASICは一番まとも

こちらの実機では、どこのモニターにも接続されてない稼働率0%のAPUのASICのワット数が、RyzenMasterのCPU本体ワット数と同じものを示しているので、少なくとも私の環境ではASIC=CPUのワット数でした。

ただ、このあたりはAPUの問題で、単体グラフィックボードはまた別の話。
さらには環境によりばらばら。かつ他アプリでもバラバラのようなので、ひとまず「アップデート由来の混乱を防ぐ」という意味で、デフォルトを旧バージョンと同じ順序に戻し、暫定では手動にてスロットを選ぶ。ということにしました。

このあたり、私の方ではRadeon software的なのが10月に入れたばかりでよくわかってないですが、AMD Softwareというのは入ってますが、とくにショートカット見当たらずなかなり初歩的な所で、実機で比較しようにもどれかわからん…という状態です。

まぁ、0b180のリリースチャネル修正はこのくらいにして、今後じっくり納得のいくクオリティにしていくために意見とテストをしていけたらなと思います。

正直私本人が良いのか悪いのかを認識できる範囲外なので、引き続きご協力いただけると助かります。

bnmr - 2218@uPwZZ1Z2gwwPP/Gf20Xmfw/m0fw1f1 返信 2023/12/30
HWinfoと並べてみたところ、SVI3 TFNとほぼ同じみたいです。
もしかしたら、極一部のAPU搭載機(SteamDeck等)でしかきちんと取得できないのかもしれません。


Gakuto Matsumura - Developer 返信 01/07
こちら、現行のch0にてプレテスト中のものをrev13に展開して、安定した後に取り掛かりますが、正直一人で頑張ったところで答えがなさそうな感じですね。

提案できる点としては、CPUなどのローデータをそのまま出すと目でみて追えない内容になるのを、平均をとるなどしている仕様に、ADLにおけるワットもなども追加するモードなどがあれば、一応GFXが高リフレッシュレートで変動が激しすぎて参考にならない。という問題は解決できると思います。

現状、設定によれば、数ある瞬間値の中のたまたま更新するフレームの値が出る。という内容のような感じなので。

このあたりは今回久方ぶりにルートそのものの動作確認を再開したために、確認とチューニングが未成熟であるが故ですね。
update
返信

質問 Radeonのサポートのご支援について
#985
すのー - 2220@PPwZZ1PwZ/lPPu0/mfGfgZfGJG1mu0J 返信 2023/12/25 15:38
年末のお忙しい中、アップデートのリリースお疲れ様です。
0b180にて、Radeonが再サポートされ、取得できる値が増えたことをこちらでも確認いたしました。
一方で、以前からRadeonの一部情報が他のモニタリングソフトと嚙み合わないことがあり、
0b180でもその点は変わっていなかったため、もしかすると実機でのテストができないのではと思いまして、
もしご必要であれば調査やテストのお手伝いをいたしますので、ご連絡ください。
私が現在使用しているのはRX 5500 XTです。ご参考になれば幸いです。

Gakuto Matsumura - Developer 返信 2023/12/25
おお、ありがとうございます。

Radeonの実機がないのはその通りで、現状何でテスト再開したのかというと、3000番台の内臓GPUが一切ないAMD CPUから、7000番台のCPU内臓のAMD Radeon Graphicsにて、確認できるようになったため、「Radeon系のデータを取るルート」という大枠がやっとまともに確認できるようになった感じです。

現在の新しい世代のバージョンでは、GPU情報というものを追加していて、比較的新しいものの場合に、現状把握している配列に対するリストが出るようにしています。

このあたり、どこが何の数値で、単位があってるのかも謎ですが、パフォーマンス系のデータとして、現状とれている値はここに列挙されるようになっています。

なにかしらそこに、この数値こそ見たいもの。あるいはこれらの中から選択したい。というようなものがあれば、GPU情報のレポートの内容と、どれが何で、どういう情報を期待しているのかを教えてもらえれば、すでに取れている分に関してはいくらでも調整はできます。

Gakuto Matsumura - Developer 返信 2023/12/25
Radeon系はあまりにも種類が多く、それぞれあるデータと無いデータがある印象なので、これ一つ買えば全部カバーできるようなものがなく、そのあたりは普段使いの使用感と、具体的に求めている値がどれで、すでに取れているか。取れているとしたらどれがほしいか。単位が何なのか等は、AMD本家が出しているオープンソースを眺めて推測する域を出ていません。

すのー - 2220@PPwZZ1PwZ/lPPu0lJ1guPl0uwXtlXPX 返信 2023/12/25
ひとまず私の方で取れるレポート情報を添付いたします。

単位が間違っていそうなのはMax Memory Frequency(Over Clock)くらいなので、ほぼ問題ないと思います。

一方で、取得した温度が一番上のTemperature以外全て11.0℃なのは正しく取れていない感じがします。
ただ、私のRX 5500 XTも最新モデルではないので、Memory Temperature、VRM Temperatureは取得できずGPU-Zなどで0℃となってしまう部分はあります。
しかし、Hotspotはレポートでは正しく取れていないのに対し、メインの温度表示ではAMD Softwareと同じ値が取れているので、レポートでの取得が変かなと思います。

また、0b180以前から感じていた部分として、おそらくディスクリート特有だと思うのですが、Clock GFXとVoltage GFXが0になります。
これについては、動作クロックが回路ごとに独立して、部分的に止めることで省電力化をしていると思われるので、0になることが正しいと思います。
AMD Softwareでも無負荷時に0を指すので、問題ないと思います。

現状私が認識できているのは以上です。

Gakuto Matsumura - Developer 返信 2023/12/25
なんだろう、ライブラリ由来の数値が-30℃のオフセットでもされてるんですかね…
41℃となっているのはDXGI経由の温度なので、ライブラリの中身に何かしらの計算が必要…?

一応データの箱自体は符号あり(負の数がある可能性がある)なので、もしかしたら30度以下になるとマイナスいくのかもしれませんが。

えらいややこしい仕様のやつがあるんですね。

Gakuto Matsumura - Developer 返信 2023/12/25
あ、すみません。
自前の環境で問題ないから気づいてませんでしたが、関数へ渡すバイナリを64bitにしないと、0クリアされてない場合にゴミが入って化けるのを完全に忘れてました。

ちょっとこちらで温度の系統の再確認をお願いしたいです。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20231225-171155.zip

すのー - 2220@PPwZZ1PwZ/lPPu0lJ1guPl0uwXtlXPX 返信 2023/12/25
ベンチマークソフトでGPUに負荷をかけて値の変化を見てみましたが、レポートの11.0℃の温度表示は変化がありませんでした。
また、Temperatureとして表示されているのはタスクマネージャーと同じくGPUのEdgeの温度と一致しています。
他の値では、Wattage ASICが単位Wで取得されているのを、メインのTDP表示で1Wを0.1%として表示しているのを見つけました。

すのー - 2220@PPwZZ1PwZ/lPPu0lJ1guPl0uwXtlXPX 返信 2023/12/25
上記のはテストビルドのものではないです。入れ違いになってしまい申し訳ありません。
テストビルドの方でレポートを確認したところ、Temperature Maxが11.0℃なのを除いて正しく取れていると思います。
Temperature Maxは名前を見るにTjMax的なものを指しているんですかね?

すのー - 2220@PPwZZ1PwZ/lPPu0l2GmlGX0flXZ/G/l 返信 2023/12/25
GPUのBIOSの情報を確認してみたところ、EdgeのThermal Limitが110℃だったので、
スケールが違っただけで取得した値は正常だと思われます。

Gakuto Matsumura - Developer 返信 2023/12/25
なるほど。頼むから統一してくれ案件ですね。

私の環境ではてでこないので、それこそ単位がわからないやつですねこれ…
Radeonは全てこうなんでしょうか。
NVIDIAを考慮せずに変更するとえらい温度になりました。

Gakuto Matsumura - Developer 返信 2023/12/25
とりあえず、hotfix6に、Radeon系のGPUレポートの温度が変になる事への修正のみ適用しておきました。

まぁ、内容についてはじっくり理想形へと調整していけたらと思います。

すのー - 2220@PPwZZ1PwZ/lPPu0G1wJfJ2wJtZJ20w/ 返信 2023/12/26
かしこまりました。
表示する内容については、私からのサンプル1つだけで決めるのは良くないと思っていたところ、先日友人がRX7600を購入したことを思い出し、情報収集の協力を依頼したので、このデータを確認したのちに改めてご連絡したいと思います。
update
返信

質問 常時稼働のサーバー上で稼働し続ける方法はありますか?
#977
patipati - 2193@pCsxm+0y 返信 2023/12/18 17:17
先日はTeamsへのアップデート対応頂き、ありがとうございました。
サーバーOSなどの問題などで、質問してよいのか、憚られましたが、タイトルの通り
SVOS(WindowsSV)にて常時稼働(バックグラウンドでのサービスなど)を行い、常時死活監視を行いたい(1時間おきのSVの稼働状態の監視)のですが、サービスとして動かすのは可能でしょうか?

自身が知見が少ないため、稚拙な質問かもしれませんが、宜しくお願い致します。

Gakuto Matsumura - Developer 返信 2023/12/18
コードサイニング証明書のやり取りやら、アップデーターの要件やら、次回の正式リリース準備やらでヒーヒーいってるので、とりあえず来週に予定しているリリースには間に合いませんが、まずはどんなものを想像しているのかを教えて下さい。

GUIを持たない場合もあるWindows Serverにて、サービス稼働上で取得したCPUやらメモリやらの情報を、Teams(ステータス投稿群)に投げるようなもの?がほしいという事でしょうか。

こなかったらたぶん落ちてますね的な。

内容として具体的にどんな情報を取得したいのか。
その情報をどんな形で受け取りたいのか。

これらを踏まえて、サービス稼働を前提とし、かつ何かしらの送信ができるような形にできるかは、まずは作ってみて実際に試していく感じになります。

一応、サービスのクローンランという、メンテしたの10年ちかく前だよねみたいなやつは、基本的にメモリブレーカー専用(WindowsのVPSでメモリオーバーすると固まるから強制的に消す要件)なので、やるなら明確に何を目標とするのかを確認し、実現できるかどうかはやってみてから考える感じになります。

patipati - 2193@pCsxm+0y 返信 2023/12/19
正式リリース及び、バージョンアップ直前の、大変な状況の中お返事いただき、ありがとうございます。

自身の現環境では、GUIがあり、CUIのみで運用しているWindowsSVはありません。(CUI環境下は完全に意識の外でした)

弦生様が想定されてる通り、Teamsやメールにステータス投稿チャネルを作成し、そちらに通知が飛ぶようにが希望でございます。

WIndowsServer2023DCを使用。1時間おきにTeamsにステータスを投稿してほしいのですが、CPU、メモリの温度及び使用量、ストレージ容量の使用率のなどを 設定した閾値を超過した場合に投稿または、1時間おきなどに投稿ができればありがたいと考えております。

直近のリリースで今すぐという希望ではございません。
お忙し中、恐縮ではございますが、ご検討頂ければ幸甚です。
宜しくお願い致します。
update
返信

要望 ワイヤレスマウスのバッテリー残量表示
#972
あんころ - 2202@wPwZ/XtmPXGwPPtZG10um/w//Jf02P2 返信 2023/11/26 01:35
大変素晴らしいソフトでいつも重宝しております。
厚かましい要望で、技術的に可能かすら分かりませんが、ワイヤレスマウスのバッテリー残量を表示することって出来ないでしょうか?
Logicool製のG502Xを使用しており、残量確認の為にGHUBを立ち上げて確認するのが億劫なのでthilmera側で表示できないかなぁと。ご検討よろしくお願いします。

Gakuto Matsumura - Developer 返信 2023/11/26
うーん、正直よくわからないですね。

少なくとも汎用的なBluetoothのバッテリー残量とかの場合は、今年のいつだったかの話で、ドライバレベルのものを作成して、ごりごりBluetoothの端末と直接通信に割り込むものを作る(多分法人専用の署名が必要)以外に現状は方法なさそう。という感じでした。

ロジクール、ロジテックに関しては、何かしらSDK的なものはあるみたいですが、ざっと見た限りはホイールの操作とか、キー操作とか、LEDとか、みたいな限定的な感じですね。

ちょっとロジクールがなにがしかの正式なAPIを用意しているかどうかは一度調べてみようかとは思いますが、直近では変更の規模が大きくなりずぎて遅れに遅れている現行のテスト版リリースを先に優先したいところです。

Gakuto Matsumura - Developer 返信 2023/11/26
ちょっとまったくわからんですが、HID(ヒューマンインターフェースデバイス)というものからずばりG502にアクセスするらしきサンプルがあったので、とりあえずビルドしてみたものでいけるか試してもらおうとしましたが、念のため確認としてvirustotalに投げてみたらマルウェア判定されるので、ちょっとそのあたり確認してからにします…

あんころ - 2202@wPwZ/XtmPXGwPPtZG10um/w//Jf02P2 返信 2023/11/26
早速ご検討頂きありがとうございます。
勿論今のスケジュールをご優先ください。
お手隙の時に検討進めて頂ければ十分です。
よろしくお願いします。

Gakuto Matsumura - Developer 返信 2023/11/27
とりあえず、マルウェア判定について色々調べてみましたが、中身はどれもオープンソースで公開されている内容のみで、そのままビルドして特に問題はなく、特に怪しい内容は含まれていないと思います。

virustotalの誤判定で猛威をふるっている、AIで誤検出が極めて低いと宣伝しているやつは大体食らうし、opensslとかをそのままビルドしたやつでも普通に似たようなマルウェア判定になるので、正直ビルドしてから時間が経っておらず、使用人数が少ない。という時点でどうにもならなさそうです。

多分無害である。とは思うけど、保証はできない。でよければ以下を試してみてください。
repo.thilmera.com/pac/thilmera7/managed/test/logicool-G502test20231126-2358.zip



正直この二つは大体文句いう…
www.virustotal.com/gui/file/e1a442fa72c52dd14f56c3943851ece91a5372deaa2f16c47c35866e81d61e66?nocache=1

あんころ - 2203@wPwZ/XtmPXGwPPtZfP0tJllZtZ11lmmt 返信 2023/11/28
早速ありがとうございます。
試してみたんですが下記の通りでした。
imgur.com/HGqziaD
知識不足で恐縮ですが
本来ならDevice pathに何かしら表示されるんでしょうか??

Gakuto Matsumura - Developer 返信 2023/11/28
テストありがとうございます。
とりあえずそのまま動くようなものではない。という前提と、ころがってる優先のロジクールのマウスに対して、デバッグしながらとりあえずなんか0%であるのはとれたぽい。みたいな状態にしました。
repo.thilmera.com/pac/thilmera7/managed/test/logicool-G502test20231128-0146.zip

多分今度出力される内容は端末の情報が載ってるので、.txt形式のファイルにしてここに添付して下さい。
ここでの.txtの添付ファイルは管理者のみ閲覧可能となります。

あんころ - 2204@wPwZ/XtmPXGwPPtZgfPl/f20PJww00Ju 返信 2023/11/28
出力内容添付いたします。
ご確認お願い致します。

[appended] txt

Gakuto Matsumura - Developer 返信 2023/11/29
ログの中身で、
電圧が 3855 ミリボルト。
電池残量 59 %。
バッテリは現在放電中のフラグ。
と文字上ではでていますが、これは対象のマウスの求めている電池残量の数値に近いでしょうか?

あんころ - 2206@wPwZ/XtmPXGwPPtZmf2uP1JugZg012/1 返信 2023/11/29
バッテリー残量は89%なのでちょっと差が大きいですね。
電圧はメーカーアプリに表示が無いのでちょっと分かりません。
Statusの部分は無線モードで使用していたので合ってはいるのですが
USBケーブルを接続してPCからの充電モードにしてもdischargingのままでした。

暫くマウスを使ってみてメーカーアプリの残量が減ると
出力ログが59%から変化するか確認してみます

あんころ - 2208@wPwZ/XtmPXGwPPtZlG1222GXPG0mZmXl 返信 2023/12/03
アプリ表示:89% ⇒ログ出力:59% 3855 mV
アプリ表示:93% ⇒ログ出力:59% 3855 mV
アプリ表示:79% ⇒ログ出力:59% 3855 mV

バッテりー残量が上がっても下がっても
ログ出力は59% 3855 mVから変化しないようです。。。

Gakuto Matsumura - Developer 返信 2023/12/04
報告ありがとうございます。

どうもよく見てみると、このソースは、ボルト数の固定Max値に対しての残量の割合を単に示そうとしているようです。
なので、mVの数値が変化がないならば、パーセンテージも動かないみたいです。

とりあえずあてにならなさそうなので、HID(ヒューマンインターフェース)とは全く別口で、汎用的なバッテリーの列挙をするものを組みました。

ちょっと全てにおいて有線派であるのと、バッテリーが完全にいかれていて、電源ひっこぬくと電源おちるノートしかないのでなんともですが、電源抜けないノートでは、ノート本体のものは一応出てきはしたのを確認しています。

repo.thilmera.com/pac/thilmera7/managed/test/20231203test_common_test_battery02.zip

こちらで何かしらでるでしょうか?
まずは何かが出るか。
出たとして目当てのマウスはありそうか。

の確認をお願いします。

あんころ - 2209@wPwZ/XtmPXGwPPtZ/0wZJwmXtJ1ZPPu 返信 2023/12/04
確認したところ、下記ログが出力されました。
よろしくお願いします。

start
end loop

wait press key...

Gakuto Matsumura - Developer 返信 2023/12/04
とりあえずこっちのリストにlogiのワイヤレスマウスはない。ということですね…

ちょっとさらに調べてみます。

Gakuto Matsumura - Developer 返信 2023/12/13
こちら、ちょっとやそっとでは解決しなさそうで、可能かどうかも不明なので、とりあえず現状は半年かかっている次期バージョンの正式リリースを先にさせてください。

次期リリース後に落ち着いたら、改めて下調べから再開します。

あんころ - 2212@wPwZ/XtmPXGwPPtZlwwt/mmf2gtJJm21 返信 2023/12/16
ご連絡ありがとうございます。
お手隙の時にでも検討進めて頂ければ十分です。
よろしくお願いします。
update
返信

質問 マウスオーバー時の操作
#974
犬飼 - 2207@PPwZP1PwZPZGPP1X1022f2Xg1Jgg2u12 返信 2023/12/03 08:59
マウスオーバー時に非表示にしていますが、こうするとシルメラの操作ができなくなります。タスクバーのアイコンを右クリックしても項目が出ず操作不能です。どうすればいいでしょうか。

Gakuto Matsumura - Developer 返信 2023/12/03
報告ありがとうございます。
タスクバーのアイコンが反応しないのはあきらかにおかしいですね…

まずは使用しているバージョンと、使用している環境のOS。
問題が発生している環境のthilmera7.iniを添付して下さい。

犬飼 - 2207@PPwZP1PwZPZGPP1X1022f2Xg1Jgg2u12 返信 2023/12/03
返信ありがとうございます。使用しているバージョンは 0b178 Rev.8 です。Windows 11で使っています。

[appended] ini

Gakuto Matsumura - Developer 返信 2023/12/03
ch1=RELの0b178 Rev.8のwin11にてタスクバーのアイコンが反応しなくなるという問題は再現できませんでした。

まずは以下を試してみてほしいです。
thilmera.com/page-help-31

犬飼 - 2207@PPwZP1PwZPZGPP1X1022f2Xg1Jgg2u12 返信 2023/12/03
マウスオーバー時に非表示を元に戻すには、inf ファイルを直接書き換えればよいのでしょうか。そうであれば、該当する項目を教えてください。

Gakuto Matsumura - Developer 返信 2023/12/03
上記試された後でも、やはりタスクトレイアイコンはどのクリックも反応しない感じですか?

試された上でも動かない場合は、以下の追加の確認をお願いしたいです。
① そのタスクトレイアイコンが反応しない状態で、メインウィンドウは更新されているか。
② メインウィンドウは完全に止まった状態のものが表示されているか。
③ もしくはメインウィンドウは非表示になったまま帰ってこなくて表示がない状態になっているのか。
④ タスクトレイアイコンの中身はアニメーションしているか、止まっているか。
⑤ 他のプログラムのタスクトレイアイコンは正しく反応するか。


一応、マウスオーバー非表示の設定だけをオフに戻せばそれで全てが解決するのならば、thilmera7.iniをメモ帳などで開き、"wnd_over_hide = on;" (*後修正済) の行を消すか、onをoffに書き換えて下さい。

Gakuto Matsumura - Developer 返信 2023/12/03
すみません、"wnd_over_hide = on;"の間違いです。

Gakuto Matsumura - Developer 返信 2023/12/03
そういえば忘れていましたが、本体がデッドロック(お互いの終了待ちが発生して無限に待機してしまう)系統のバグが特定の環境で残っている可能性があり、マウスオーバー非表示はそれがでる可能性のある機能なので、こちらでは再現できていませんが、おそらく③であり、④は止まっていて、⑤も該当する形ではないかと思います。

もし可能であれば、犬飼さんの環境にて、ch0=DEVのバージョンをそのまま確認し、改善されていないかを確認してほしいです。
もしこちらでも同様の問題がでる、となれば、犬飼さんの環境用に、どこが問題であるかのアタリをつけるためのテスト版を作成してログをとらせてほしいです。

ch0=DEVのバージョンを利用する方法は、本体の動作が怪しそうなので、フォルダ内にthilmera7.upd.exeがある場合は、それを適当な別フォルダにコピーして実行し、「0ch : 公開テスト版」を選択してダウンロードしてください。
上記がない場合は以下からダウンロードできます。
repo.thilmera.com/pac/thilmera7/updater
repo.thilmera.com/pac/thilmera7/zip-updater
update
返信

報告 Disk I/Oについて
#967
熊倉 - 2196@PPwZl1PwwtllPPuGu1Jw1gf1J//ffg1 返信 2023/10/17 12:39
実際は書き込み読み出ししていないドライブレターが表示されているように見えます。
できるだけ無駄ディスクアクセスが無くなるようにwindowsを調整してシルメラでモニターしていたのですが、Windowsのモニターと比較してもどうもそのように見えます。
ファイルのスクリーンショットはEドライブをアクセスしているように見えますが読み書きは0バイトです。
パソコンの状態を監視するのにすごく役立っており助かっております。ありがとうございます。

Gakuto Matsumura - Developer 返信 2023/10/17
なるほど。
質問ありがとうございます。


こちら、シルメラが何かしら事実にないドライブアクセスを示している。ということではないです。

0%については小数点切り捨てなので0%とでていますが、ここにE:というのがでているということは、論理ドライブE以下にアクティビティ(稼働率)が、少なくとも0ではない1%未満の少量がで出ている。ということになります。

ここの表示ではDisk I/Oのグラフが見えていないので、直近のEドライブのデータの読込/書込が完全に0だったかはわかりませんが、このE:表示は読み書きのバイト数から表示されるのではなく、ドライブの全てのアクティビティのパーセンテージで最大値の理論ドライブが表示される。という仕様です。

ドライブのアクティビティには、Read, Write以外にもTransferなどが存在していて、ドライブのアクティビティには、データの中身の読書以外にもいくつか動作があります。

読み書きに関しても、OS付属のタスクマネージャーでは表示されないものも普通にあります。(これはタスクマネージャーには表示出されないだけで、OS内部には当然情報としてあるものです)

論理ドライブとしてのトラフィックにはでないけど、物理ディスク全体としてのトラフィックはある。というケースもよくあります。


Read,Writeのみに限定したとしても、例えばユーザー本人がそのドライブにはそもそも何一つファイル設置してないんだけど!という場合でも、空き容量が最も多いとか、よくわからない理由でOS含めて勝手に一時ファイルなどを書き込んだりする挙動をする場合も多々あります。

ブートドライブがCと同一ではない場合、ブートドライブに色々と置かれていてそれにしょっちゅうアクセスするケースもよくあります。

このあたりは理由はいくらでも考えれるので、少なくともWindowsはそういうもの。という認識でいいかなと思います。

もしどうしても気になるようでしたら、シルメラが認識しているディスク関連の情報を更に可能な限り纏めるようなものを作成することも可能ではありますが、ずばり理由がわかったところで、止められるようなものである可能性は低いかもしれません。

少なくとも、マルウェアなどが入っていなかったとしても、私の知識内では、標準的なWindowsでは普通にありえる挙動。という感じです。


もし疑問が解消しなかったり、わからない所があれば遠慮なく言ってください。

Gakuto Matsumura - Developer 返信 2023/10/17
書き忘れてましたが、シルメラで採用しているCrystalDiskInfo由来のSMAR取得機構の内部では、デバイスドライバを通したアクセスを各ドライブにしているので、それの内容もアクティビティの中に出ている場合も考えられます。

あとは細かい補足になりますが、以前にシルメラのユーザーの要件として必要になったのでCrystalDiskInfo側にもつけくわえさせてもらったNo Wakeupをオフにした場合は、SMART情報が読めないドライブに対して、直接的に512バイトのIOを発生させて眠ってるディスクを起こす構造になっています(これがは全ての物理ドライブで発生するものではないです)

こちらの懸念に関しては、シルメラのSMART関連をオフにする設定が複数個所あるので、もしオフにして試したいのならば、具体的にどういう設定が必要かを案内します。
update
返信

テスト CrystalDiskInfo風のGUIのテスター募集
#963
Gakuto Matsumura - Developer 返信 2023/08/03 02:14
 現在のテストDEV13は、コア部分を含む多くの書き直しや多くの修正がされています。

・CrystalDiskInfo風のGUIのテスト版。現状CDIに存在しない機能の開発テスト:テスター募集
 GUIにて、以下のテスト項目の確認をしてくれるユーザーを募集中です。
 ・現在仮テスト作成中なので、とりあえず動く程度の精度です
 ・日本語以外の言語は自動の機械翻訳のため、現状文字数がオーバーして見づらいケースがあります
 ・現在確認を募集している部分
  ・サブフォルダへのフォルダマウントを行っているドライブが、正しいドライブで正しいパスが表示されるかどうか
  ・NVMeで、本来複数の温度がとれるデバイスで、左の温度欄が2つ以上表示されるか
  ・NVMeで、下部のtestから始まる内容で、0以外が表示されるケースがあるか


[テストの基本手順]
既に旧バージョンがある場合は、その他からリリースチャネルで0を選択してアップデート。
ない場合はアップデーターをダウンロードし、0chを選択してダウンロード。

次に、設定のドライブのSMARTなどをオンにし、同グループのOpen: DiskInfo GUIをクリックするか、タスクトレイアイコンの右クリックメニューなどからDiskInfo GUIを選択。

上部の四角いエリアをクリックすると各ドライブが表示される。
update
返信

報告 報告とはちょっと違うかもなんですが
#956
龍牙 襄 - 2186@uPwZP1ZPZXmPPP0G0PftP/mfJuwt1GJ 返信 2023/07/05 09:24
ここしばらく(すいません、具体的にどういうタイミングからかはわかりません)、CPU使用率が100%で張り付いてしまいます。
PCの起動時から100%でほぼ落ちることはありません。
ただ少々妙なのはタスクマネージャーでは90%くらいなんですよね。
おまけに使用感ではそんなに重く感じることはなく、普通にゲームなどはプレイできます。多少カクつくことはありますが。
またIObitのAdvanced Systemcareのウィジェットでは30%前後で、体感としてはこちらが実態に近い感じなんです。
使っている感じとしてはタスクマネージャーやthilmeraの値がおかしい気がするのですが、どうすればいいでしょうか。

CPU-Zのレポートを添付しておきます。
ほかに必要なデータがあればお教えください。


[appended] txt

Gakuto Matsumura - Developer 返信 2023/07/05
丁度最新のOS更新からおかしくなった。とかならありえますが、IObitさんのものがどういう仕様なのかは知らないです。

どんな環境なのかがよくわからないのでなんとも言えませんが、「CPUの負荷の高さ=体感の動作が遅い」ではありません。

たとえばthilmeraにはCPU負荷テストが備わっていますが、それを有効にして意図的にCPUを100%にした状態でも、PCは全く問題なくさくさく動きます。
これは、CPUの使用率と、優先度は別の問題であるからです。

例えば、OSの更新後の後処理であったり、メモリコンプレッサがメモリを整理していたり、ファイル転送などでシステムががんばっていたり、これらは一例ですが、CPUの負荷になりますが、基本的に優先度は低い(余った計算力で行う)場合が多いので、操作上のストレスは感じませんが、実際には裏で処理しているようなことが、OS単体でもおこったりします。

まず確認してほしいのは、「トッププロセス」→「トッププロセスCPU」をオンにして、何のプロセスがCPUを稼働させているのかを確認して下さい。

OS関連のものならよいですが、よくないものが走ってる可能性もあります。

龍牙 襄 - 2186@uPwZP1ZPZXmPPP0lPXuPtltwZGGfmtG 返信 2023/07/05
トッププロセスをオンにしたところ、p:(CscService)が一番上で張り付いていました。
画像を添付しておきます。

Gakuto Matsumura - Developer 返信 2023/07/05
んん、なんかおかしいですね。
たしかにCscServiceというのは、正規の正しいOSのサービスであるならば、オフラインファイルに関するものらしいです。
不思議なのはCscServiceが消費しているCPUは1/16コアの最大100%とおもわれる数値なので、全コアが100いってるのにトッププロセス一覧に出てきてない、というのは確かに変ですね。

まず原因の切り分けのため、以下で100%張り付きが改善されるのか確認してみてほしいです。
管理者権限のコマンドプロンプトで
sc stop CscService
またはコンピューターの管理>サービスとアプリケーション>サービス>Offile Filesを開いて「停止」を押す


これは消したりするわけではないてので、再起動すれば元に戻ります(サービスの種類によっては自動的に再開される場合もあります)

龍牙 襄 - 2186@uPwZP1ZPZXmPPP0lPXuPtltwZGGfmtG 返信 2023/07/05
試してみました。
やはりCPU使用率に変化はありませんが、トッププロセスにはdwmが来ました。

Gakuto Matsumura - Developer 返信 2023/07/05
うーん、なんだろうなぁ。
表示されている温度からすると、負荷自体はたしかにかかってそうです。
普通負荷もなしに100度とかにはならないので。

ただ、プロセスのリストにない、ということは何かしら計算できてない謎のプロセスがいるか、もしくは全体の稼働率の取得が何かしらの原因でおかしい数値になっているか。

こちらでwin11実機を現状の最新の状態にして確認してみましたが、とくに問題は再現されませんでした。

タスクマネージャーで上部のCPUのところをクリックして、上位はどうなっている感じですか?

龍牙 襄 - 2186@uPwZP1ZPZXmPPP0gwGlPJX2lltl2lft 返信 2023/07/06
すいません。あの後PCを落として離れていました。

タスクマネージャーのCPU使用率の一覧の上位を取ってみました。

Gakuto Matsumura - Developer 返信 2023/07/06
あまり不確かなことは言いづらいのですが、見たところIOBit Malware FighterとAvast Serviceという、セキュリティ対策ソフトが2つ以上動いている状態なのではないかと思います。(これらの製品の内情には詳しくないので、これらがどういう動作をしている状態にあるかはわかりませんが)

セキュリティ系ソフトが2つ以上動いていると、お互いがお互いを監視しあったり、お互いがチェックする動作をチェックしたりと、色々と干渉して滅茶苦茶なことになるので、どちらかを削除して、セキュリティ対策ソフトは一つに。

あるいはファイアウォールなど、絶対この機能がいる、みたいなのがなければ両方削除してMicrosoft Defenderにしたほうがセキュリティ上望ましいです。

昔の常識ではMicrosoft Defenderは使い物になりませんでしたが、今のwin10,11では、Microsoft Defenderよりも堅固なセキュリティ対策ソフトは探すのに苦労するほどです。

話がそれましたが、プロセス一覧のCPU使用率と全体のCPU使用率が違う理由の予想として挙げられるのが、

[1] セキュリティ対策ソフトなどの、システムから見えなくされている部分(セキュリティ対策ソフトの内部はシステムから隠されていることがあります)で何かが起こっている。(最も可能性が高い)
[2] 変なプログラムが居ついて悪さしている。
[3] OSのパッチや環境による不具合。
[4] CPUなどの物理的なデバイスやドライバのバージョンによる固有のトラブル。
[5] thilmeraとタスクマネージャー両方が不具合(これはもしあるとしても3,4由来になります)

CPU使用率がIOBitなにがしで30%前後というのは、多分取得できるプロセス(セキュリティ対策ソフトの一部はここにない可能性がある)の合計値を出しているのではないかと思います。
が、thilmeraのスクリーンショットでは明らかに100度前後の熱を出しており、CPU使用率を別にても、相当負荷はかかっている状態なのが見て取れます。
update
返信

雑談 0b178にアップデートされた際の気づき・質問など
#928
SleepyF - 2167@P2Xef7Ni 返信 2023/04/30 18:37
1. 第一階層グループの左から呼べるなど、デザイン変更は概ねよい感じです。
 左ペインに第0階層(?)表示がないのは最初少し戸惑いました。慣れの問題かも。
 スクロールバーは以前の色・幅の方が好みでした。

2. 設定の[表示]―[ウィンドウ/Software/…]項目の「タイトル&属性表示」が
 ONの場合に、[表示]―[スタイル]項目の「グループセパレート」のON→OFF
 /OFF→ON操作でリセットされてしまうのが、少々分かり難いです。
 尤も「調整される」旨のポップアップ説明が出るので、不整合を回避するため
 などの都合があるのでしょう。

3. アイコンの設定[白色アイコン]の用途が分かりませんでした。プログラム
 アイコン、タスクバーアイコンを見たつもりですが…。以前からある設定ですが
 初めて弄りました(タスクバーのミニグラフ表示機能は分かります)。

4. 設定窓の高さがあと少し低いと嬉しいです(#719で暫定対応された件)。
 でも1366x768画面で仮想マシンを起動させた場合だけの特殊状況であり、
 広い外部モニター上で作業すれば済む話なので切実な問題ではありません。
 それに設定窓が最初から広い方がよい人も多いでしょうし。

Gakuto Matsumura - Developer 返信 2023/04/30
>1
全てのページを統合したため、以前の設定1以下が最下層になりました。
たしかに設定1以下というのがかなり長い期間そのままだったので違和感はあるかもしれません。
現状、元設定1以下に全てが含まれたため、そもそも区分けする必要がなくなった。という感じです。

>2
これ以外にも、とくにレイヤードと半透明などの、互いに干渉する設定は、オンオフ時に調整されるルールのものがちらほらあります。
どうするのがよいと思いますか?

>3
これはすみません、UIのグルーピングのカバーミスで、正確にはタスクバーアイコン以下の設定なので、タスクバーアイコンが白か黒かの設定になります。


>4
現行の最小=デフォルトの高さが660px(今回のバージョンより拡大可)になりますが、768あっても収まらないようになっていますか?

SleepyF - 2167@P2Xef7Ni 返信 2023/04/30
ご回答ありがとうございます。

#1 説明が足りませんでしたが[表示][項目][詳細]というカテゴリ?のことを
書きました。 なくて困る訳ではないです。

#2 「タイトル&属性表示」がONで「グループセパレート」のON/OFF切替でも
「タイトル&属性表示」ONが維持されているのが好ましい気がしますが、干渉を
避けられないなら仕方ないかな、というところです。

#3 タスクトレイのアイコンでなくタスクバーのアイコンを確認しましたが、
変化していないように思えます。図を添付します。

#4 VirtualBoxで仮想マシンのタイトル/ステータスバーで消費されて、私の環境では
画面高さ655が最大。更にWindowsのタスクバーでWin7:33またはWin10:40消費されて、
有効な高さの最大は622または615です。

SleepyF - 2167@P2Xef7Ni 返信 2023/04/30
#3 投稿後に気付きましたがWin7では(初めて見ましたが)アイコンタイプ選択で形が
変化し、確かに白・黒変化していますね。
Win10では添付した画像の通り変化なし。WinXPではタスクバーアイコンがそもそも出ません。

Gakuto Matsumura - Developer 返信 2023/04/30
>3
こちらのメイン環境はまだWin10で続けていますが、タスクバーのアイコンは今回のリリース前に確認済みで再確認しても問題は再現できませんでした。
念のためiniファイルを頂けると助かります。

XPでタスクバーアイコンが出ないのはOSの仕様上無理っぽいので、タスクバーアイコンの項目をVista(これも確認してませんが)以降でのみ有効に変更しておきます。

>4
内部テストにて、以下の修正を作りました。
 ○ 設定ウィンドウの最小の高さを615pxに変更。ウィンドウの高さが、現在のモニターのワークエリアより高い場合にサイズ補正。

>2
これはどちらかといえば、相容れないデザインになっている属性表示を、フローティングなどに合わせてデザインしなおして存続させる。みたいな方向性の要望ということですね。

>1
なるほど。たしかにその区分けは消えています。
ちょっと、スマートな表示の仕方がないか一度考えてみます。

SleepyF - 2167@P2Xef7Ni 返信 2023/04/30
#3 thilmera7.iniファイルを添付します。XPで表示されないのがOS仕様である点、およびその対応の件了解です。

#4 一般環境と狭い環境、それぞれに考慮して戴きありがとうございます。

#2 難しいですね。ちょっといい案が私には思いつきませんが、[スタイル]内の変更が[ウィンドウ/Software/…]内の設定に影響したのが、意外と感じた理由です。尤も広く言えば共にスタイル問題なので、影響してもおかしくないか…とも思ったり。
余計なことを書くならば、グループセパレートの、余白の高さが私の使い方だと(複数環境で)どこも変わらなくて首を傾げたり…。

[appended] ini

Gakuto Matsumura - Developer 返信 2023/04/30
>3
問題は際限されませんでした…
うーん、OS起因のなにかの設定かな…原因が検討つかないですね。

>2
グループセパレートに関して、頂いたiniで確認しましたが、機能しないのは想定通りで、マウスオーバーの説明の通り、非レイヤード(ソフトウェア描画で非レイヤード。ハードウェア描画の場合は制限なし)の場合は表示には適用されません。

うーん、このあたりもたしかに初見からしたらややこしくてよくわかないですよね。

SleepyF - 2167@P2Xef7Ni 返信 2023/05/01
#3のアイコンの件なぜでしょうね 情報のバー表示はされているようですが。
OS関連の情報を書いてなかったので一応補足しておきます。

Windows の仕様
 エディション:Windows 10 Pro
 バージョン:22H2
 OSビルド:19045.2846
 エクスペリエンス:Windows Feature Experience Pack 120.2212.4190.0

SleepyF - 2167@P2Xef7Ni 返信 2023/05/01
追加:マウスホバーさせるとアイコン形状&白/黒が変化していることに気付きました。

SleepyF - 2167@P2Xef7Ni 返信 2023/05/01
別件で気づいたのですが、右クリックメニュー[thilmeraについて]―[更新確認/アップデート]にて、
「現在の最新バージョンです」や「SERVER NOT FOUND」などのメッセージが出なくなっていますね。

Gakuto Matsumura - Developer 返信 2023/05/01
すみません、なんかサーバー上でキャパオーバー的ななにかかが発生していたのかもしれません。
2023/04/30日未明から発生していたようです。

とりあえずリダイレクトのルールの記述変更のみで現在問題なく通るようになったので、しばらくこちらでも様子を見てみます。


何か気づかれたら連絡いただけると助かります。
よろしくお願いいたします。

Gakuto Matsumura - Developer 返信 2023/05/01
ちょっと、目玉のUI刷新なのに、肝心の新UIが多くの環境で途中で途切れて表示される状態であることを確認したため、急遽Rev.1として更新しました。
以下の内容を適用してあります。タスクバーアイコンに関しては原因を探るのに時間がかかりそうなので改めて取り掛かります。


 ○ 設定ウィンドウの最小の高さを615pxに変更。ウィンドウのサイズが、現在のモニターのワークエリアより大きい場合にサイズ補正。
 ○ タスクバーアイコンを、Vista未満でのバージョンで明示的に無効。
 ○ グループセパレートの更新
  ・グループセパレートをソフトウェア描画時に有効にした場合に、条件付きレイヤードをオンにするように変更。
  ・グループセパレートのサブ設定に、「半透明計算なしのレイヤードを使用」のオプションを追加。デフォルトでオン。
   グループセパレートを使用している場合、この更新により

SleepyF - 2167@P2Xef7Ni 返信 2023/05/02
> ○ 設定ウィンドウの最小の高さを615pxに変更。ウィンドウのサイズが、現在のモニターのワークエリアより大きい場合にサイズ補正。
→ (高さを伸ばして閉じた後も)小画面時には615pxとなり正常に閉じたり保存したりできることを確認しました。ありがとうございます。

○ タスクバーアイコンを、Vista未満でのバージョンで明示的に無効。
→ XPにて、無効になっているのを確認しました。

ハードウェアアクセラレーションが無効での挙動で気づいた点を書いておきます。

◆1:グループセパレートに関して:

「グループセパレート」で「透明なエリアが作成される」の記述で、何が起こるのかようやく機能がイメージできました。

[グループセパレート]のON/OFFを最低2度繰り返してOFFにすると[*]、ウィンドウが透明化する件: [*]1度だと透明化する場合としない場合とがある
 ・ソフトウェア描画で調整が発生する件は(ポップアップで説明が出るので)諸事情あるのだろうと納得しています。
 ・[タイトル&属性表示]が無効化する点は、戻せば済むので面倒でも納得はできます。
 ・透明化を戻したい場合、以下のような操作が必要だと気づくのは辛いかも…と感じました。

(0) ポップアップ説明通り[ウィンドウ/Software/…]の[レイヤード]が(当初OFFでも)ONになっている; 説明の「条件付きレイヤード」とはこの[レイヤード]のことなの?という疑問は湧きますが… 挙動から見るとそうなんですよね?
(1) 説明で「条件付きレイヤード」と記してあっても[レイヤード]のON/OFFでは意図せぬ透明化を解除できず、
(2) OFFを示している[半透明ウィンドウ]を一旦ONにして(スイッチの見かけは同期しないものの、(1)の実施有無に関わらず[レイヤード]がOFFになり、透明度付ながら透明化が解除;変な説明ですが…)、再度OFFに戻すことで意図せぬ透明化を解除できる、
(3) 加えて、上記[グループセパレート]操作*直後*には、(実はレイヤードON&非半透明だけど)ONで透明化が解除されたように見え(且つ透明度設定と無関係に、透明度100%設定と同じ状態に見え)、OFFで見かけが変わらないまま真の非半透明(&非透明)になる点が、通常のONで半透明/OFFで非半透明という動作と、食い違う点も混乱する気がします。

ハードウェアアクセラレーション有効の場合、[半透明ウィンドウ]や[レイヤード]がスイッチの見かけ通りの挙動のため、上記の混乱を感じませんでした。

もしかしたら上記(2)と(3)は以下の結果に由来するのかな?
> グループセパレートのサブ設定に、「半透明計算なしのレイヤードを使用」のオプションを追加。デフォルトでオン。

◆2:[半透明ウィンドウ]のON挙動がちょっと変?
 ON/OFFした際、ONで文字が表示されない黒っぽい半透明になります。[ウィンドウの透明度」をいじると、意図通りの半透明表示に治ります。

SleepyF - 2167@P2Xef7Ni 返信 2023/05/02
先のコメントの◆2ですが、発生するのは仮想環境のXPだけで、実機Win7, Win10では発生しません。

SleepyF - 2167@P2Xef7Ni 返信 2023/05/02
散発コメント済みませんが、◆2の件、仮想環境のWin7も発生しません。

Gakuto Matsumura - Developer 返信 2023/05/02
>◆1
>(0)
正確には、「レイヤード」+「グループセパレート+半透明なしのレイヤードを使用」がそれにあたります。

「半透明なしのレイヤードを使用」をオフにすると半透明になります。

ソフトウェア描画においては、ウィンドウの描画の仕様がそもそも違うため、グループセパレートを再現するにはレイヤードをオンにしなければならず、かつ条件つきレイヤードは本来のレイヤードで計算される半透明度を計算しない。という、元々無理があるソフトウェア描画における非レイヤードに近いものをグループセパレートとして再現する。
といった感じになります。

レイヤードとのフラグの関係を内部的に整理するとなるとかなり根本から多くを変えないといけないため、暫定として「指定しても変わらない」という問題報告への対処をしました。

>(1)
「グループセパレート+半透明なしのレイヤードを使用」の状態で、必須である「レイヤード」をオフにしたら画面更新がされないのを確認しました。

また、「半透明ウィンドウ」は「レイヤード」をオフにする排他的設定なので、レイヤードが切れます。

なんとか整理してみますが、少なくとも1ch以下では次回以降のバージョンでの対応となります。

>(2)
そもそも意図せぬ透明化というのが何を指しているのかわかりませんが、グループセパレートは、「グループ間に透明なエリアを作る」のが機能の仕様であり目的です。

>(3)
よくわかりませんが、ソフトウェア描画では強制的に「レイヤード」がオンになるため、グループセパレートがオンのときのみ有効になるサブ機能である「半透明なしのレイヤードを使用」は、グループセパレートがオフになると無視されるので、単体の「レイヤード」となり、ウィンドウは半透明になります。

>◆2

ソフトウェア描画にて、レイヤードから半透明ウィンドウにスイッチした際に、透明度が初期から適用されない場合があるのを確認しましたが、どうやらグループセパレート系を弄らなければ再現されない問題のようです。

SleepyF - 2167@P2Xef7Ni 返信 2023/05/03
個々に状況を説明していただいて、挙動の意味など何となくわかりました。
多数の機能・要望を様々な環境下で実現させるべく、ソフトウェア描画では困難なことも力技(?)で実現させているということに、ホント、敬服しますね。

>>(2) >そもそも意図せぬ透明化

これは、(予備説明なくテレビ機器を渡された人のように)仕組とか意識しせずスイッチをON/OFFしてみて、OFFにしたのにON前と同じにならないという点での「意図せぬ(主表示部分の)透明化」という意味合いで書きました。(以下のような感じ)
(0)「グループセパレート」有効で「透明なエリアが作成される」のはポップアップの説明で承知した
(1) 有効にした → 確かに透明エリアができた。でも自分には不要な機能だった
(2) 戻そう → 無効に戻したら「透明なエリアが」なくなるだけと思ったのに、主表示エリア(透明なエリア以外)も透明になってしまった

Gakuto Matsumura - Developer 返信 2023/05/03
>>(2) >そもそも意図せぬ透明化
なるほど。
指摘される遷移になるのはバグではなく仕様と認識通りのものなのですが、オーバーフローの中身をよく読まずに適当に触ったら元に戻すのがどこにあるのかわからなくなる。というのはたしかにわかりにくいです。

最近は0chにて長い時間(今回は5か月間)をかけて公開テストをする。という方法で、リリース直後にデスマーチが始まったり、ユーザー全体でのテスト爆走にならないように気を付けてはいるのですが、なかなか不具合やわからない点があっても、伝えてくれる(私に伝わる場所である公式フォーラムやメール、Discordでしっかり発言してくれる)方はとても稀なので、なかなか苦労しています。


今回はすみません。ソフトウェア描画は確認不十分でした。
ハードウェア描画をテストの基本にしていたため、ソフトウェア描画における不具合を認識できておらず、以下クリティカルなバグが見つかったため、Rev.2として更新しました。

半透明ウィンドウに関しては、どうも古いOSだと、昔は無かった何かしらのバグ(開発環境の変化(更新)による影響か、もしくは現行のコードの互換性)が発生しているようで、原因が判明するまで正常動作が確認されたWin8.1未満では一時的にソフトウェア描画における半透明ウィンドウは無効。としました。UIなどが固まってiniを編集して半透明ウィンドウを解除しないと復活しないレベルでやばいです。



[version 0b178 Rev.2 / 2023/05/03]
 ● 【重要】ソフトウェア描画で、レイヤード設定のオンオフや、レイヤード中のサイズ変更で描画が停止する不具合の修正。
 ● 【重要】古いOSのソフトウェア描画で、半透明ウィンドウを使用すると動作不良を起こす問題があるため、解決できるまでWindows8.1未満のOSで設定をオフに。
 ● ソフトウェア描画におけるレイヤード関連の調整
  ・グループセパレートを、レイヤード設定に影響を受けない専用処理として再作成し、不要になった「半透明計算なし」を削除。
   ハードウェア描画と同じく、ユーザーが仕様上の制約を気にする必要がなくなりました。
  ・レイヤードと半透明ウィンドウの切り替えで、透明度が適用されないなどの、いくつかの不具合の修正。
 ○「背景色を透明化」のオプションを、レイヤード設定のオンオフに影響されないように変更。
 ○ 設定UIの左ペインに、前バージョンにあった区分ラベルを追加。

SleepyF - 2167@P2Xef7Ni 返信 2023/05/03
設定窓の左ペインや、ソフトウェア描画に関する対応など了解しました。
クリティカルバグの発見につながったのは良かった(?)かもしれませんが、軽い素人レベルの感想を書いたら、あれこれ掘り返す形になっているのが少々心苦しくもあります。

電気回路設計や小規模なアプリ作成を経験した身として、**を実現させるには(現状)**せざるを得なくて副作用的に**が発生する、なので「調整される」旨の説明を書いておく、といった状況も分かります。
一方で、予備知識なく素人が扱っても戸惑わないUIが好ましいという思いもあり、その観点で気づいたことを時々コメントしたりします。
なので、何か言っている奴がいるという風に、負担にならない程度に目を通して戴けると良いかなと思います。

Gakuto Matsumura - Developer 返信 2023/05/03
いえいえとんでもない。
今回も「こうなります」「うん確かにそう作った…」だったので、こういう所がユーザーに無駄なハードルを課してる部分なんだろうなと…

率直な意見とてもありがたいです。
「予備知識なく素人が扱っても戸惑わないUI」は正に到達しなければならない目標です。

内部的な仕様としてこうなるけど、ユーザーがそれを意識した上で、説明文を読んで、対象を探しにいかないと元に戻せない。というのはものすごくまずいと思いますorz

属性表示が関連設定時に消える件などもToDoに書いてあるので、また改めて調整します。

あと、各OSでテストした結果、仮想のwin7でのタスクバーアイコンはSleepyFさんと同様に、プログラムのアイコンが出るだけで変わらない。というのが再現されました。
ここら辺で参考にできるか試してみますね。


今回は正式チャンネルにリリース後だったので、ちょっと余裕ない感じでバタバタした対応になってしまって申し訳なかったですが、普段の0ch上での更新フットワークは軽く、期間も長め(参加人数が限られていてテストチャンネルという性質なため)なので、本リリースでクリティカルな問題が出ない限りは0chにて自由に引き続きやっていきます。
update
返信

要望 Bluetoothデバイスのバッテリー残量の監視は可能でしょうか?
#921
ますお - 2159@Iyx2m+9A 返信 2023/03/26 17:53
初めまして。いつもThilmera7には助けられています。
負荷ごとに踊るように変動するCPU使用率のグラフは眺めているだけで癒されます。

さて表題の件ですが、Bluetoothデバイスのバッテリー残量の表示を追加することは可能でしょうか?
Windows10では設定のBluetoothとその他のデバイスを開かねばならないのが煩雑で、また設定ウィンドウで画面を覆うのが邪魔で仕方なく
いつも視界に入っているThilmera7に表示されたらとても便利なのでは?と思い切って要望の声を上げさせていただきました。
HSPとBSPのプロトコルでバッテリー残量が取得できればほとんどのデバイスに対応できるのではないかと思います。

お手すきの時にでもご検討いただければ幸いです。
よろしくお願いいたします。

Gakuto Matsumura - Developer 返信 2023/03/27
滅茶苦茶苦戦してます。

・Bluetoothには、クラシックとLow Energyの二種類がある。
・手持ちの環境ではクラシックで列挙だけできたが、Low Energyでは列挙すらされなかった。
・Linuxは標準で見れるものがあるらしいけどWindowsにはない。
・Microsoftが公式で出しているBluetooth端末の取得取得は、Win11では動かない(何らかの依存なのかデフォルトのポリシーなのか>回答として、レジストリを弄れとあるが、弄っても動かなかった)
・Windowsの設定画面にあるバッテリー情報も、すべてには対応しておらず、専用のアプリを使え。とある。
・ライセンス、言語問わず、10以上のソースを200回以上テストしてみたが、どれ一つとして手持ちのデバイスのバッテリー残量はとれなかった。
・唯一とれそうな雰囲気のある有料アプリは、インストールの時点でBluetoothのサービスなどを完全に弄くるものらしく、ちょっと参考にすらならない。

どうしましょうかねこれは…

ますお - 2159@Iyx2m+9A 返信 2023/03/29
早速試していただけるとは、確認遅くなって申し訳ありません。
これは…難しすぎますね…
他にバッテリー残量表示するものがあるかな?と検索したところBluetooth Battery Gadgetというフリーソフトが見つかったのですが、そちらでもとても苦戦しているのが見受けられました。
こちらはLow Enagyだけ取得できてClassicの方はまた別の作者のアプリをインストールされている場合に連携する、というものでした。
nazenaninadesico.hatenablog.jp/entry/2021/07/17/085847

しかしWin11で動かないとなると、近い将来Win11以降が主流になったときに再度検証・修正の手間が入ると考えると、いったん棚上げにした方がいい機能かもしれません。
OSのシェアが変動した時にでも再度ご提案させていただきたいと思います。
検証・試行していただき本当にありがとうございました!

Gakuto Matsumura - Developer 返信 2023/03/29
そうですね。
Bluetoothのサービスやドライバを完全に弄らない限り、実用に耐えるものはなかなか難しいかもしれません。

手持ちのデバイスが、Classicでは列挙できるが中身はとれないヘッドフォンと、Low Energyではひっかかるけど、残量はWindows設定でも確認できないAndroidスマホの2つしかなく、PC側もWin10でBluetoothが載ってる機器がないので、Win10で確認できるのかは試せていないのですが、Microsoftが正式に公開しているBluetoothの情報取得サンプルが、Win11では起動すらしないというのが大分厳しいですね。

Low Energyに関しては情報の項目にバッテリーがあるので、とれるものは取れるのだと思いますが。

なんかBluetoothの仕様の闇を見た感じですね(汗
update
返信

テスト CPUスレッド数128環境でのテスト
#879
Gakuto Matsumura - Developer 返信 2022/08/24 00:31
CPUスレッド数が65以上のCPU(AMD threadripperの128スレッド)のテスト
該当のCPUをお持ちの方、テストをお願いします。

テスト項目:
・設定のその他>ストレスCPUをオンにして、CPU全体が使用率100%に到達するか
・CPUマルチが全て表示されるか
・CPUクロックが全て表示されるか
・RyzenMasterモードのEffectiveClockが全て表示されるか


○ CPUスレッド数
 ・CPUマルチ、CPUクロック、EffectiveClock、Intelコア温度、ストレスCPUの枠数を可変長に変更。
 ・CPUスレッド数が65以上の環境への対応テスト。テスター求む。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20220824-002631.zip
update
返信

報告 ディスクI/Oの%表示が変?
#876
ANACOSTIA - 2107@PPwZZ1Pw2g1wPPgtGfGJuZtGg0Jgmw2/ 返信 2022/07/18 23:58
 (自動アップデートにより、)いつからか、PC自体がアイドルに使い状態の時でも、[ドライブ]→[ディスクI/O]の%表示の数値(ディスク(ドライブ)のアクティビティ率。転送速度ではなくビジー状態の割合。 by 弦生ささと - admin 2021/07/29 (木) 18:36 (775,5442))が殆ど100%で固定されるようになってしまいました。

 この時、Windowsの[パフォーマンスモニター]で[LogicalDisk]→[対象ドライブ]→[% Disk Time]及び[% Idle Time]を確認すると、[% Disk Time]は0位で殆ど一定、[% Idle Time]は100位で殆ど一定になっています。
 [PhysicalDisk]の方も同様の結果です。

 これまでは、thilmeraの[ディスクI/O]の%表示が100%に張り付き続けるということはありませんでした(何か多量のファイルのやり取りその他の操作をしない限りは)。
 この状態が正常な動作・表示なのかどうか、確認をお願いしたいです。

Gakuto Matsumura - Developer 返信 2022/07/19
thilmeraのディスクI/Oが100%になる理由は大抵はOSのパフォーマンスカウンターが破損などにより0を返している場合が殆どです。
この場合はヘルプの「表示がおかしい」の一つ目にある、管理者権限のコマンドプロンプトdから「lodctr /r」を実行し、OS再起動で大抵直りますが、これはもう試されましたでしょうか?

ANACOSTIA - 2108@PPwZZ1Pw2g1wPPgtPXGwtZm/ffuXluJt 返信 2022/07/19
 早速のご返答ありがとうございます。
 未試行でしたので、先程実施してみました。
 しかし、残念ながら症状は変わらずです。

 現在2台のIntel-CPU-PCを使っていますが、2台とも同じ症状が出ています。
 朧げな記憶ですが、version 0b174(但しRev.不明)に自動アップデートされた辺りからこの症状が出たような気もします(2台のPCの運用の違いから、自動アップデートの時期がズレており、発生時期が明確ではありません)。

 尚、この症状が出た際に取り敢えず

・イベントビューアーから、関連しそうな異常がないかの確認
・SSDのSMARTに異常がないかの確認(thilmeraと他ソフトとの両方で)
・[コントロールパネル]→[メンテナンス]→[信頼性履歴の表示]で関連しそうな異常がないかの確認

を行い、取り敢えず差し迫った問題は無いと判断し、その内thilmeraのRev.アップでこの症状が無くなるのだろうと軽い考えでいました。
 しかし、100%に張り付き続けるのがずっと続くのにもどうかと思うようになったので、投稿した次第です。

Gakuto Matsumura - Developer 返信 2022/07/19
報告ありがとうございます。

確認してほしい事と、設定ファイルを添付していただけると助かります。

確認してほしいのは、
① DiskI/O全体だけでなく、各ドライブ「ディスクIO一覧」も全て100%になるかどうか。
② 100%固定の状態が常に続くのか、もしくはほぼ100%になるが、それ以下になることもある(変動が見られる)か。

2台ともということなので、なんらかの条件によりなる内部的な可能性が考えられますが、まずは設定ファイルによりこちらで再現できないか試してみたいです。

ANACOSTIA - 2109@PPwZZ1Pw2g1wPPgtPXGwtZm/ffuXluJt 返信 2022/07/19
 thilmera7.iniを添付しました。

①について
 [ディスクIO一覧]を有効にすると、Cドライブ分が追加されますが、元々の[Disk:]と同時に100%になります。
 元々、PCにはSSDが1つしか装着されておらず、更にGPT特有のパーティションを除けば、OSから通常見えるドライブが1つ(Cドライブ)のみなので、こうなるのは当たり前なのでしょうけど。
 この件に関しては、2台のPCの内、片方のPCしか確認できていません。

②について
 時々100%未満となります。
 PC2台ともそうなります。

③[FullR]について
 これまで[ドライブ]→[ディスクIO]の[FullR]が有効でしたが、これを無効にすると表示が正常になるように見えます(これに関しても、PC2台ともそうなります。)。
 しかし、[FullR]は以前から(100%貼り付き問題が発生する前から)有効だったと思います。
 [ANACOSTIA - 2021@BSadaW6T 返信 01/13 (木) 20:36 (817,5627)]でもthilmera7.iniを添付しましたが、このファイルは[FullR]が有効になっているのではないでしょうか?(少なくともこの時は、100%貼り付き問題は起こっていなかった)
 残念ながらこの時のファイルが手元に無いので、申し訳ありませんが、こちらでの検証はできません。

④IOテキスト更新頻度
 フレーム速度をFPS:60(wait:0.016s)とし、[更新フレーム頻度-I/O]を15としています。
 なので、ディスクI/Oのバーは60Hz、テキスト(ReadとWriteそれぞれの速度(MB/s))は4Hzで更新されるようになります。
 しかし[ディスクI/O]の%表示は60Hzで更新されているようです(以前はどうだったのか記憶にありません……)。
 この[ディスクI/O]の%表示も、ReadとWriteそれぞれの速度と同じく、[更新フレーム頻度-I/O]の値が反映されて欲しいです。

[appended] ini

Gakuto Matsumura - Developer 返信 2022/07/19
なるほど。フレーム速度60FPSという時点でなんとなく原因はわかりました。

仕様として明記していないのが悪いのですが、FullR時のディスク稼働率は、最高値を採用します。
そしてディスク稼働率は、統計期間が短くなればなるほどピーキーに100%をだしやすい(0or100みたいなのが繰り返される)ので、根本的にFullR時の仕様を作り直す必要がありそうです。

ANACOSTIA - 2109@PPwZZ1Pw2g1wPPgtXfwX0wJlmmJGJ/0l 返信 2022/07/20
 ディスクI/Oの[FullR]に関しては、CPUの[フルデータバー色反転]、GPUの[フルバー色反転]、トッププロセスの[フルバー色反転]と同じイメージで捉えていました。
 現に、以前は100%貼り付きが起こっていなかったと記憶しているからです。
 バージョンヒストリを見ると、100%貼り付きが起こるようになったのは、version 0b172 Rev.8でフレーム速度関係を変更してからなのかもしれませんが、小生の頼りない記憶からは、ここから発生するようになったという認識はありません。

 取り敢えずは[FullR]を無効にすることで解決できると考えております。
 データバーやテキストの更新頻度に応じたサンプリング範囲の最大値ではなく平均値を採ることで、最終的な解決が得られれば有り難いです。

Gakuto Matsumura - Developer 返信 2022/07/20
FullR時の最高値採用の理由は、100%近辺になった場合に激しく明滅してしまうため、非常に見づらいからでした。

パーセント表示の取得と更新間隔を、更新フレームIO準拠に変更してみました。
repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20220720-223139.zip

Gakuto Matsumura - Developer 返信 2022/07/20
FullR時も、サンプルからの最高値採用ではなく更新フレームIOの間隔での値をそのまま使用します。

ただ、当然ながら更新フレームIOの時間が短くなればなるほど値はピーキーになっていきます。

ANACOSTIA - 2109@PPwZZ1Pw2g1wPPgtg211wg02flXtmfmG 返信 2022/07/22
 ありがとうございました。
 repo.thilmera.com/pac/thilmera7/test/thilmera7test_build_s64_20220720-223139.zip(0b174 Rev. 8.5) で問題は起こっていません。

 時間・精神・その他に余裕があれば、CPU & GPU 丸め(平均)、フレーム速度の基本ウェイト時間、フレームあたりのテキスト更新頻度を整理して、データバー、グラフ、テキストの更新頻度と丸め方(平均値の算出法)の見直しをすることも考慮すべきかもしれません。
 現在の自分の設定でいえば、
・データバー(及び100%で反転)は1/60秒間にサンプルした(全データ又は間引いた)データの平均値を60Hzで表示
・テキストは1/4秒間にサンプルした(全データ又は間引いた)データの平均値を4Hzで表示
という実装にするなどです。

Gakuto Matsumura - Developer 返信 2022/07/22
見直しということですが、具体的に今とどう変わるのでしょうか?

現在は、ベースとなる更新フレーム速度1に対し、グラフとバーは1更新。
IOなどのフレーム数指定により、20とすると、テキストは1/20更新となります。

ANACOSTIA - 2109@PPwZZ1Pw2g1wPPgt2g2/01flwt2m10u/ 返信 2022/07/23
 他人に理解させることができない表現で申し訳ありません。


 まずは確認(認識の共通化)です。

> ベースとなる更新フレーム速度1に対し、グラフとバーは1更新。

 この更新に使うデータの取得法はどうなっているのでしょか?
 バーとグラフの更新頻度は1回/(60秒~1/60秒)(=1/60Hz~60Hz)ですが、例えばここで1回/秒(=1Hz)とします。
 この時、[CPU & GPU 丸め(平均)]の設定で、

・スルー    の時は、1秒間で 1サンプルし、そのデータを1秒間のバー&グラフ表示に使用
・前回との平均 の時は、1秒間で 2サンプルし、その平均値を1秒間のバー&グラフ表示に使用
・10回平均   の時は、1秒間で 10サンプルし、その平均値を1秒間のバー&グラフ表示に使用
・20回平均   の時は、1秒間で 20サンプルし、その平均値を1秒間のバー&グラフ表示に使用
・50回平均   の時は、1秒間で 50サンプルし、その平均値を1秒間のバー&グラフ表示に使用
・100回平均   の時は、1秒間で100サンプルし、その平均値を1秒間のバー&グラフ表示に使用

ということなのでしょうか?

 また、1回/(1/60)秒(=60Hz)の時は、

・スルー    の時は、1/60秒間で 1サンプルし、そのデータを1/60秒間のバー&グラフ表示に使用
・前回との平均 の時は、1/60秒間で 2サンプルし、その平均値を1/60秒間のバー&グラフ表示に使用
・10回平均   の時は、1/60秒間で 10サンプルし、その平均値を1/60秒間のバー&グラフ表示に使用
・20回平均   の時は、1/60秒間で 20サンプルし、その平均値を1/60秒間のバー&グラフ表示に使用
・50回平均   の時は、1/60秒間で 50サンプルし、その平均値を1/60秒間のバー&グラフ表示に使用
・100回平均   の時は、1/60秒間で100サンプルし、その平均値を1/60秒間のバー&グラフ表示に使用

ということなのでしょうか?

 テキスト更新頻度も同様です。
 バーとグラフの更新頻度を1回/(1/60)秒(=60Hz)とし、テキスト更新頻度を15(イコール4Hz)の時は、

・スルー    の時は、1/15秒間で 1サンプルし、そのデータを1/4秒間のテキスト表示に使用
・前回との平均 の時は、1/15秒間で 2サンプルし、その平均値を1/4秒間のテキスト表示に使用
・10回平均   の時は、1/15秒間で 10サンプルし、その平均値を1/4秒間のテキスト表示に使用
・20回平均   の時は、1/15秒間で 20サンプルし、その平均値を1/4秒間のテキスト表示に使用
・50回平均   の時は、1/15秒間で 50サンプルし、その平均値を1/4秒間のテキスト表示に使用
・100回平均   の時は、1/15秒間で100サンプルし、その平均値を1/4秒間のテキスト表示に使用

ということなのでしょうか?


 そして、上記認識が正しいとした場合の当方の希望改善案ですが、

(1) [CPU & GPU 丸め(平均)]の設定にある、

・加減制限25%(前回の値と今回の値の差が25%以上の場合は差異25%とする)
・66%変動( (今回の値×2+前回の値)/3 )
・33%変動( (今回の値+前回の値×2)/3 )

を廃止。

(2) [CPU & GPU 丸め(平均)]の設定にある、[スルー、前回との平均、10回平均、20回平均、50回平均、100回平均]の対象を、CPUとGPUだけではなく、[メモリ]、[ドライブ]、[マザーボード, 電源, Hyper-V]、[ネットワークI/O]、[プロセス]にも反映。

 現状、これが無いので不便・不満を感じるということは少ないので、「そういえばこんな要求もあったなぁ」と記憶の片隅に留めて置いて貰えれば十分です。

Gakuto Matsumura - Developer 返信 2022/07/23
[CPU & GPU 丸め(平均)]というのは、元々は開発当初の2001年から残っている遺物です。
基本的に指定のフレーム速度が最速の1サンプル(1クロックと考えてもらえればよいです)となります。

1フレームが1秒である場合、
10回平均は1秒間で10サンプルではなく、10秒間の平均値をとります。

テキストは、この1クロックに「更新フレーム頻度」の数値をかけた回数で更新され、前回更新してからの平均値が出されます。
つまり、60hzのWaitで、更新フレーム頻度が20の場合、テキストの更新は3hzで、20回分の平均値となります。

ただ、ここで誤解がないように補足しておくと、ほとんどのサンプルデータは、期間が長くなればなるほど平均化されます。

例えば、60hzで取得した60サンプルの平均と、1hzで取得した1サンプルの数値はほぼ誤差の範囲になります。(温度系などは瞬間値なのでこの例には当てはまらない)

(1)
廃止に関しては、廃止すると利用している人がいた場合に元に戻してくれという話になるので(これは流石に使わないだろうという機能の撤廃で過去何度も発生した事案)、これに関しては残しておくことにさしてデメリットが思い当たらないので、ちょっと難しいです。

(2)
メモリ、マザーボードは完全に更新フレーム頻度に依存し、リアルタイムな値を出しているので、平均という概念がそもそもありません。

Hyper-VはCPU,GPUと同じ設定が適用されます。

ドライブとネットワークIOは、デフォルトの10回平均ではあまりにもガタガタしすぎるので、まとめるのは難しいです。
ちなみに現在は約2.5秒程度の平均化となっていますが、これを変えたいならば設定を作るのは構いませんが、少なくともデータの現れ方がCPUなどとは全く異なるため、一律な設定にしたら極めて見づらくなってしまいます。

トッププロセス関連は更新フレーム頻度に依存します。これも「60hzで取得した60サンプルの平均と、1hzで取得した1サンプルの数値はほぼ誤差の範囲になる」が適用されます。

ANACOSTIA - 2112@PPwZZ1Pw2g1wPPgt2g2/01flwt2m10u/ 返信 2022/07/24
 ご丁寧な回答ありがとうございました。

 ところで、フォーラム上にある今回のような内容の記述(ヘルプに記載があってもおかしくないような内容の記述)を、ヘルプに逐次追加していくようなことはできないのでしょうか?
 正直なところ、ヘルプにある記載と設定画面におけるポップアップの説明だけだと、設定内容の意味や設定値選択の判断に苦しむことがあり、フォーラムを検索したり、それでも欲しい情報が無ければフォーラムへ質問を投稿しているのが現状です。

 本フォーラム(BBS)の記述が古いものから削除されるのかは存じておりません(閲覧可能な一番古い投稿が2009/10/14のものですが、これより以前に本フォーラムへの書き込みは無かった??)が、もし古いものから削除されていくのであれば(例えそうでなくとも)、弦生ささとさまの独断と偏見で、「これはヘルプに追加した方が良いかな」と思われる記述の内容をヘルプに順次ぶち込んで戴ければありがたいと考えております。

 勿論それに伴う作業負荷を最小限にする為に、(タイトルだけは熟考する必要がありますが)フォーラムのやり取りをそのまま(直接関係ない部分の削除も最低限行った方が良いでしょうが)、[ヘルプ]→[トラブルシューティング]→[Q&A]のような形で追記していくものです。
 如何でしょうか?

Gakuto Matsumura - Developer 返信 2022/07/24
書いてみました。
thilmera.com/?page=help&lang=ja&i_ID=49
すみません、テキストの中身が前回からの平均というのは間違いでした。


ヘルプに記載がない質問を受けた仕様についてはもちろん今までと同様にヘルプに追加していきます。

ヘルプにも、疑問が記載されていない場合は質問してほしいと記載しているのは、開発者の立場からすると、何が分かって何が分からないか(何が気になって何が気にならないか)はユーザーでないとなかなかわからないので、疑問点は聞いて頂ければこたえられる範囲でまとめますし、今まで同様ヘルプにも追記していきます。

Gakuto Matsumura - Developer 返信 2022/07/25
書き忘れてました。
2009年10月時点のものが最古になります。
それ以前はややこしいのですが、多分シルメラの旧BBSが全く別形式で、それより前はフルJavaで書かれていたsPherTiaというサイトのBBSとごっちゃになってたのではないかな…

過去のバックアップを掘り起こしたらワンチャン見つかるかもしれませんが、観覧できるようにするのはちょっと手間かもしれません。
手間のわりに古すぎて内容に意味があるかも疑問です。

ANACOSTIA - 2113@PPwZZ1Pw2g1wPPgtuG00t2mlJ0/JlZ0X 返信 2022/07/26
 データの取得頻度、表示に際した代表値化方法、表示の頻度に関し少しだけ理解できました。

 ヘルプの記載と設定画面のポップアップの説明に無い情報を順次(勿論、精神的・時間的余裕のある時に限る)加えて欲しいと思ったのは、以前の小生の質問に対する回答(弦生ささと - admin 返信 01/15 (土) 17:03 [817,5632])も載っていないしなぁと感じていたからでした。

 旧BBSの件ですが、そこにしかない貴重な情報(ヘルプやポップアップに無い情報)が少なくない量で埋もれており、そして殆ど手間をかけずに可能というのであれば、是非公開ログデータ化して欲しいです。
 質問と回答の関係が明確になっていれば、単なるプレーンテキストで構わないというのが小生の考えです(この為だけに新たにスクリプトを組む必要も無い)。

Gakuto Matsumura - Developer 返信 2022/07/27
とりあえず2002-2005年くらいのデータはでてきましたが、やっぱり中身が殆ど私の作曲した曲の話とかですね。
しかも整形スクリプト書かないととてもではないがどこからどこまでが本文かわからん…

2005-2009の間は見つかりませんね…

この掲示板の最古データまでのはいくらでも見つかるんですが、多分2005-2009は落ちまくる自宅サーバー時代で、もしかしたら中身にあるかもしれないmysqlのバージョン不明のバイナリデータくらいしか見つかりませんでした。
test, test1 test2 というテーブルにない場合はこのバイナリデータを解析しても中には無いです。

貴重な情報とのことですが、どんなことが書かれてましたか…?

Gakuto Matsumura - Developer 返信 2022/07/27
認知される切っ掛けになったvectorの初登録が2009/07/20なので、2009/07/20から2009/10/14の3か月弱の間は多分vector上の掲示板が本体ですね。
vectorのコメント上でサポートしてたのを今更思い出しました。
comment.vector.co.jp/comment.php/477492/4
そりゃ手元にデータないわけだ。

この掲示板では
2009/10/14 (水) 21:18 の #2 CPU温度誤差報告スレッド【0b26以降】
が最も古いです。
#1はテスト書き込みして消しただけなので、実質消えたものは何もないです。
update
返信

*オープンクローズ
 + 
#
thilmera project - forum
フォーラム一覧
t7b - v12.30.0.0
Original - Board v3.4 Revision(http://revision.s22.xrea.com/)
© 2001-2024 Gakuto Matsumura:弦生ささと (thilmera7gmail.com) Privacy Policy