site logo
新規投稿
*オープンクローズ
 + 
#
thilmera project - forum
不具合
[Closed] Win7でGPU情報をうまく取得できない
01/25[14]bnmr
報告
[Closed] GPUグラフ、タコメーター
01/23[5]タスマニアの悪魔
報告
[Closed] [半透明ウィンドウ]の[ウィンドウの透明度]がリアルタイムに変更されない
01/23[2]ANACOSTIA
報告
[Closed] スタートメニューへフォルダが自動的に作成される件
01/22[3]七海灯
不具合
[Closed] version 0b180 refresh r20 にアップデート後GPUの温度表示異常
01/21[2]ちゃっぺ
不具合
[Closed] 論理ドライブ表示周りの不具合(と思しきもの)
01/21[6]elphe
報告
[Closed] ディスクIO一覧が表示されない
01/21[15]タスマニアの悪魔
不具合
論理ドライブ表示の不具合・文字枠の太さについて

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

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

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

01/20[7]さた
不具合
[Closed] 論理ドライブが表示されない
01/20[3]りんりん
不具合
[Closed] スリープから復帰するとタスクバーにフィットしない
01/20[14]na
不具合
[Closed] 論理ドライブ表示が不安定?
01/20[3]さた
不具合
[Closed] 論理ドライブ表示が機能しない
01/17[5]elphe
不具合
[Closed] 設定を無視して全画面表示時でもthilmeraが表示されることがある
01/16[1]elphe
要望
[Closed] GPU表示順序とVRAM順序の不一致
01/16[2]西東北南
不具合
[Closed] 特定のNIC (Mellanox Connect X-3)が認識されない
01/16[16]梨々花
報告
[Closed] 指定したフォントの文字枠が消えていました
01/09[11]マークX
不具合
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
報告
[Closed] 仮想WinXPで更新に失敗します
01/03[7]SleepyF
不具合
[Closed] 最小化しても勝手に戻る
01/03[12]kris
質問
[Closed] CPUやGPUのグラフ表示について
2023/12/30[8]sirichan
*オープンクローズ
 + 
#
thilmera project - forum
[Closed] 不具合 Win7でGPU情報をうまく取得できない
#1009
bnmr - 2218@uPwZZ1Z2gwwPP/GuX2/tXgtGPGgmmG/ 返信 2024/01/23 01:24
0b180 r18からr21に更新したところ、VRAMが表示されなくなり、GPUレポートではGPUが2台多く表示されます。

Gakuto Matsumura - Developer 返信 01/23
どこがどうなっているのか予想がつかないので、以下にてログ"debug_log.GPU.txt"を取得してほしいです。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240123-013924.zip

bnmr - 2218@uPwZZ1Z2gwwPP/GuX2/tXgtGPGgmmG/ 返信 01/23
log

[appended] txt

Gakuto Matsumura - Developer 返信 01/23
あれ、スクリーンショットの内容と一致しない…

Gakuto Matsumura - Developer 返信 01/23
スクリーンショットではVramは表示されているようです。
GPUがダミーとなっているのはレガシー用のダミーなので正常ではあります。

Gakuto Matsumura - Developer 返信 01/23
>GPUがダミーとなっているのはレガシー用のダミーなので正常ではあります。
GPUが2つずつとなっているのは、本体とそれぞれのレガシー用のダミーなので正常ではあります。

bnmr - 2218@uPwZZ1Z2gwwPP/G10f2gXJwf/2wZuJu 返信 01/23
バックアップに180r18が残っていたので同じ設定で起動してみました。
r18ではAMD側のVRAMが表示されましたが、r21ではnvidia側しか表示されません。

[appended] zip

Gakuto Matsumura - Developer 返信 01/23
なるほど…
どれが何のスクリーンショットなのかがよくわかりませんが、最初のスクリーンショットで見えているVram-NV2の方ではなく、DXGI由来のVRAMがrefresh以降にレガシー対応判定ルートに入るが、レガシーなハードではないwin7では出ていた…ということですね。

ただ、win7ではハンドルがとれず、マッチングのしようがない、ただ単にどれがどのGPUかかわらないVRAMが列挙されるだけ。というものだったはずなので、マッチングと、マッチングできないならダミーが前提。という状態から、このケースにも対処するにはどうすればいいのか少し考えます。

Gakuto Matsumura - Developer 返信 01/23
とりあえず以下でどう出るかを試してほしいです。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240123-123422.zip

やった内容としては、VRAMが出せるがOSが古いレガシーと、OSはともかくハードウェアが古いレガシーの2ケースを分離し、VRAMのみとれるケースでは、VRAMルート上では、本体の有効無効とは別に、VRAMとるのに必要なデータさえあれば取る。というものにしています。

ダミーは同じなので、恐らく0,1がVRAMとして出てくるスロット(どのGPUであるかは不明)で、2,3が互換性用のダミーとして作成されたGPU本体の管理上のスロットとなります。

Gakuto Matsumura - Developer 返信 01/23
debug_log.GPU.txtのログと、GPUレポートの中身を下さい。

Gakuto Matsumura - Developer 返信 01/23
もしかしたらDXGI由来とVramNVの両方でそうな気がしますが、まずは可能な限りの情報を出すことが先なので、ひとまず結果を見てどうするか考えます。

bnmr - 2218@uPwZZ1Z2gwwPP/Gf12ww/gmGZu0w/tf 返信 01/24
log

[appended] zip

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

すみません、こちらのログは、ちゃんと最初のスクリーンショットが取られた時の設定で取得されていますでしょうか?

ログ取得時に、VRAMの表示設定がオンになってるかを確認してほしいです。
もし、スクリーンショットと同じ設定でもこうなっている。ということならば、さらにログの箇所を増やします。

bnmr - 2218@uPwZZ1Z2gwwPP/Gf12ww/gmGZu0w/tf 返信 01/24
iniを移植して取得し直しました。
問題なく表示されています。

[appended] txt

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

こちら、早々にch0に先行、そののちリリースチャネルと思っていましたが、先に別の問題報告の様子をみてからにします。

確認した内容の方は、だめだろうと思っていた部分が全て動作しているという、予想していた修正群が必要なくそのまま使えそうな、かなりいい内容でした。

別件でのモニターに関する問題がまとまれば更新作業を再開します。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 GPUグラフ、タコメーター
#1008
タスマニアの悪魔 - 2239@gziI3HF9 返信 2024/01/22 06:29
設定のGPU項目GPU情報の稼働率にチェックしないと、グラフ・タコメーターが反応しない。

Microsoft Windows 10 Pro 64 ビット 22H2 (10.0.19045) Dark IE/11 JS/11.0.16384 ja_jp 96 AMD Ryzen 7 3700X 8-Core Processor

レポート: GPU情報

--------

flag: DXGI1, DXGIp1


---- GPU:0 ----

Name: NVIDIA GeForce RTX 2070

[DXGI]
dVRAM: 254.7KiB / 7.83MiB
sVRAM: 20.94KiB / 7.96MiB
Memory Frequency: 7.00GHz / 7.00GHz
Temperature: 49.8'C
Max Memory Frequency(Over Clock): 7.00GHz
Temperature Warning: 81.0'C
Temperature Max: 89.0'C

[NVIDIA]
PCIe x1 MaxSpeed: 3.00Gbps (375.0MBps)
PCIe Bus Speed: no correct / Gen3x16
Memory Bus: 256 bit
TT Shutdown: 94.0'C
TMT Slowdown: 91.0'C
TMT GPU Max: 89.0'C
TT Min Acoustic: 65.0'C
TT Current Acoustic: 72.0'C
TT Max Acoustic: 88.0'C


Gakuto Matsumura - Developer 返信 01/22
こちら、バグではなく、意図してそうなっています。
稼働率は稼働率で、わざわざそのために取得しなければならないケースがあるので、負荷を抑えるために元から収集しない。データを作成しない。というものになるので、少なくとも設計上は正しく、とても正しい挙動です。

この意見としては、メインとなる行内の稼働率だけ非表示となり、タコメーターやグラフが有効の場合は稼働率のオンオフに関わらずに収集する。という仕様にしてほしいという感じでしょうか?

Gakuto Matsumura - Developer 返信 01/22
もし単純に挙動がバグのように感じる。ということならば、設定上の組み方を考えます。

メインとなる行をオフ。または行の稼働率のみオフにして、他は表示したい。ということならばそれはそれで作ります。

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/22
おつかれさまです。
負荷を抑えるための仕様だったんですね。
ウインドウ幅を狭くしている場合に稼働率を表示すると消費電力Wが見切れることがあったので、グラフ・タコメーターで表示しようとしていました。
負荷が増えすぎるのも考え物ですし、現状のままで気にしないことにします。
返信ありがとうございました。

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

①ではなく②であることから改めて確認したところ、確かに稼働率の取得を行いはしますが、本体の行の稼働率表示だけ消したい。というのは普通にありえることだと思うので、以下で対応してみました。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240122-230914.zip

変更内容は、稼働率、グラフ、タコメーターのいずれかがオンの場合、稼働率の収集は行い、稼働率のオフは、メイン行への表示を消す効果。グラフとタコメーターが無い場合は今までと同様。としました。

稼働率はいらないから負荷を極限まで抑えたいというニーズの人が、グラフとタコメーターを使用する可能性はないと思うので、今後はこちらでいこうと思います。

他になにかしらのクリティカルな不具合がない場合、この変更はch0での次期バージョン開発に回し、デフォルトリリースはr21を採用する予定です。

タスマニアの悪魔 - 2239@IvwLh4xP 返信 01/23
おつかれさまです。
確認しました。思い通りの表示にできました。
ありがとうございます。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 [半透明ウィンドウ]の[ウィンドウの透明度]がリアルタイムに変更されない
#1006
ANACOSTIA - 2241@PPwZZ1Pw2g1wPPgt1wffZJJXGfGwm1f 返信 2024/01/21 15:56
Win10 22H2で0b180 refresh r19です。

設定画面から各種設定を弄る際、他の項目はリアルタイムに設定が反映されるのに対し、[半透明ウィンドウ]の[ウィンドウの透明度]を変更する際のみ、設定画面を閉じても反映されず、反映させるには[半透明ウィンドウ]を一度OFFにしてから再度ONにするか、若しくはthilmera自体を再起動するかしかないようです。
当方の環境がWin10だからかもしれませんが。
尚、[ハードウェアアクセラレーションを使用する]がONの時はリアルタイムに反映されます。

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

こちら確認でき、適用される内容はオンオフされた瞬間に、その時の値が適用されて、数値の変更時は適用されない処理となっていました。
前回の値を保持し、数値が変更された場合も適用処理を行うようにしました。
ハードウェア描画では、そもそもレイヤードも半透明も不透明も全く同じ属性の状態で、単に描画する内容の調整のみでるあのに対して、ソフトウェア描画は、不透明、半透明、レイヤードはそれぞれ別個の処理となります。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240121-160640.zip

ANACOSTIA - 2241@PPwZZ1Pw2g1wPPgt0uufPJ0ZZwXmu1 返信 01/23
r21において、[ハードウェアアクセラレーションを使用する]がOFFの時でもリアルタイムに反映されることが確認できました。
ありがとうございました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 スタートメニューへフォルダが自動的に作成される件
#995
七海灯 - 2233@uPwZP2ZfZGPPt1JtGwGfJXtwf21w22 返信 2024/01/15 11:32
最近のアップデートで、スタートメニューへ「thilmera 7 (Portable)」のフォルダが自動的に作成されていました。
こちらは自動アップデートで強制的に作成されるようになったのでしょうか?
また、これを作成しないようにするオプションはないのでしょうか?
(アップデーター上で設定する?)

Gakuto Matsumura - Developer 返信 01/15
こちらは2か月ほど前の0b180系のリリース以前から全員が同一である話で、要望によるものでしたが、逆に作ってほしくないケースというのは確かに考慮していませんでした。

とりあえず、現行までに関してはどうしようもないですが、0b180のrev17から、それ次回以降へのアップデート時に、設定から以下のオプションを指示して、設定を継承した状態でアップデートを行えるように、本体とアップデーター双方を更新しました。

設定欄は、「設定」「アップデート設定」「オプション」以下となります。


本体: 0b180 Rev.17
アップデーター: 0.6.2023NS Rev.8

完全に新しい仕様であるため、下位互換はありません。

今のところは、本筋の動作に問題がないかの確認だけお願いします。

Gakuto Matsumura - Developer 返信 01/15

 ○ 更新時のアップデーターへのオプション指定機能を追加
  プログラム本体からのアップデート時に以下のフラグを付けて呼び出す仕様を作成。
  ・ショートカットを作成しないオプション
  ・全てのアーキテクチャを展開するオプション
  リソース破損による緊急アップデートでは適用されません。

七海灯 - 2233@uPwZP2ZfZGPPt1u1Pu1G1GZftZ2m/l 返信 01/22
返信遅れました。
ご対応頂き有難うございました。
問題ないことを確認しております。
以上、宜しくお願いします。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 version 0b180 refresh r20 にアップデート後GPUの温度表示異常
#1007
ちゃっぺ - 2242@ybP2sLta 返信 2024/01/21 22:40
いつもお世話になっております。
先ほど0b180 refresh r20へのアップデートをしたところ、GPUの温度表示が桁ズレなのか10倍されるようになってしまいましたのでご報告させていただきます。

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

ライブラリ由来の温度が利用できない場合に採用されるDXGIの値に、元となる数値の異なる単位が混在している問題への補正で、確認してみたところ、確かにRadeonの表示にむける数値の桁だけ一桁多くなっていたようです。

更新したので確認をお願いします。

0b180 refresh C r21

ちゃっぺ - 2242@ybP2sLta 返信 01/21
早速の対応ありがとうございます!
0b180 refresh C r21
にて正常に戻ったのを確認しました。

ありがとうございました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 論理ドライブ表示周りの不具合(と思しきもの)
#1005
elphe - 2235@1PwZwX1/PPZ/PPG2PP1/GJ20glZwGu0 返信 2024/01/21 12:15
#998の者です。その節はありがとうございました。
こちらの環境でもversion 0b180 refresh r19では#998の不具合は解消されていることを確認できました。

ただ、version 0b180 refresh r19の論理ドライブ表示周りにて2点ほど気になる点がありました。
・「論理ドライブ」の下の設定で、マウントされたドライブの表示/非表示の設定が機能していないようです。例えば「ドライブリスト」から「D: 表示」のチェックボックスを外してもthilmera上では表示されたままです。
・スクリーンショットで、Cドライブは警告表示になっていますが、このとき棒グラフが(おそらく)表示されていないようです。警告表示になっていないDドライブやGドライブは文字の下に棒グラフが表示されていますが……

elphe - 2235@1PwZwX1/PPZ/PPG2PP1/GJ20glZwGu0 返信 01/21
iniファイルはこちらです。

[appended] ini

elphe - 2235@1PwZwX1/PPZ/PPG2PP1/GJ20glZwGu0 返信 01/21
追加情報です。
設定の「スタイル」から「左右反転」をONにしても、警告表示のCドライブは左右反転しないようです。

Gakuto Matsumura - Developer 返信 01/21
>「論理ドライブ」の下の設定で、マウントされたドライブの表示/非表示の設定が機能していないようです。例えば「ドライブリスト」から「D: 表示」のチェックボックスを外してもthilmera上では表示されたままです。
こちら、確認したところ、非表示に切り替えた時に、中途半端に更新だけ停止して古いデータの表示が残ることが確認されました。
再編成に由来するフラグの伝達ミスのようです。

>・スクリーンショットで、Cドライブは警告表示になっていますが、このとき棒グラフが(おそらく)表示されていないようです。警告表示になっていないDドライブやGドライブは文字の下に棒グラフが表示されていますが……
こちらは、白と赤のうち、赤がバーに相当します。
下にバー表示するスタイルだとバーが無いというのが不思議に感じるかもしれません。
元々のスタイルでは、反転色となり、本来の中身は赤(memory-modifiedカラー)と白(text-color)で表されます。
ただ、確認したところ、母数の単位が100分の1になっていました。

> 設定の「スタイル」から「左右反転」をONにしても、警告表示のCドライブは左右反転しないようです。
こちら確認してなかったのですが、どうも相当昔からこうだったようです。
とくに弄った記憶がない…

以下3点修正しました。
確認をお願いします。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240121-152129.zip

elphe - 2235@1PwZwX1/PPZ/PPG2PP1/GJ20glZwGu0 返信 01/21
リンク先が「404 Not Found」になっていて何もダウンロードされません……

Gakuto Matsumura - Developer 返信 01/21
すみません、アップロードミスでした。
もう一度お願いします。

elphe - 2235@1PwZwX1/PPZ/PPG2PP1/GJ20glZwGu0 返信 01/21
修正を確認できました!
対応ありがとうございます!

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 ディスクIO一覧が表示されない
#1002
タスマニアの悪魔 - 2239@gziI3HF9 返信 2024/01/19 06:54
1.ディスクIO一覧が表示されない
2.ディスクIOの%が常に100%になる
3.ロードキャッシュを含むをチェックしないとディスクIOの値が0
 thilmera.com/page-help-31の内容は実行してみました
4.設定の壁紙で論理ドライブ表示が点滅する タイトルバーをポイントしている間だけ正常に。
5.トッププロセス項目でオプションの降順にチェックしないとトッププロセスディスクIOの表示が空欄になる
6.メモリ項目でビデオメモリオン、DXGIオンにするとVRAMが表示されなくなる
 GPU情報エリアに表示をチェックすると情報エリアに表示されるようになる
Microsoft Windows 10 Pro 64 ビット 22H2 (10.0.19045) Dark IE/11 JS/11.0.16384 ja_jp 96 AMD Ryzen 7 3700X 8-Core Processor

[appended] ini

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

> 1.ディスクIO一覧が表示されない
> 2.ディスクIOの%が常に100%になる
> 3.ロードキャッシュを含むをチェックしないとディスクIOの値が0
 thilmera.com/page-help-31の内容は実行してみました

こちら3つは、ディスクIOに関するものですね。
ディスクIOが常に100%で、ロードキャッシュを含むと0%(おそらく完全0ではないと思いますが)というのは、システムがRAID構成の再同期など、IOに換算されない処理をしている場合はありうるものではあります。

ただ、一覧が表示されないとなると本当に0なので、頂いた設定で確認してみましたが、正常な内容で再現はできませんでした。

常に100%となるという場所で、WriteとReadの値は0でしょうか。0以外でしょうか?


> 4.設定の壁紙で論理ドライブ表示が点滅する タイトルバーをポイントしている間だけ正常に。

こちら、#998, #999, #1001にて修正したものがあるので、下記のもので同時に確認をお願いします。

> 5.トッププロセス項目でオプションの降順にチェックしないとトッププロセスディスクIOの表示が空欄になる

こちら再現できたため、下記にて修正しています。

> 6.メモリ項目でビデオメモリオン、DXGIオンにするとVRAMが表示されなくなる
 GPU情報エリアに表示をチェックすると情報エリアに表示されるようになる

まず、対象のVRAMを搭載するGPUの種類や状態がわからないので、レポートのGPU情報を開き、内容をコピーして下さい。


4.と5.の件へのテスト版
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240119-132531.zip

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/19
おつかれさまです。

1.2.3.
ロードキャッシュを含む にチェックを入れるとWrite、Readともに2.36Mなど正常表示されます。
チェックを外すと完全に0になります、数分眺めていましたが、ピクリともしませんでした。 グラフにも反応はありませんでした。
%の場所は起動時から常に100%です。 スクリーンショットを添付します。
RAIDは組んでいません。

再現できなかったとのことで、こちらの環境の問題でしょう。 お手数おかけしました。


4.5.
テスト版にて修正を確認しました。


6.
レポート: GPU情報

--------

flag: DXGI 1, DXGIp 1


---- GPU:0 ----

Name: NVIDIA GeForce RTX 2070

[DXGI]
Memory Frequency: 7.00GHz / 7.00GHz
Temperature: 39.0'C
Max Memory Frequency(Over Clock): 7.00GHz
Temperature Warning: 81.0'C
Temperature Max: 89.0'C

[NVIDIA]
PCIe x1 MaxSpeed: 3.00Gbps (375.0MBps)
PCIe Bus Speed: no correct / Gen3x16
Memory Bus: 256 bit
TT Shutdown: 94.0'C
TMT Slowdown: 91.0'C
TMT GPU Max: 89.0'C
TT Min Acoustic: 65.0'C
TT Current Acoustic: 81.0'C
TT Max Acoustic: 88.0'C

レポート便利ですね!

Gakuto Matsumura - Developer 返信 01/19
> 1.2.3.
こちら、原因がよくわからないので、そもそも中身の数値としては何がとれているのかをざっくりですがログに出すものを作りました。下記のテストから、20秒程度走らせて出力される"debug.DISK_IO.txt"を添付して下さい。

> 4.5.
ありがとうございます。

> 6.
こちら、再現ができたので、いっそ再編成してみました。

変更はこのような感じになります。

 ● VRAMのルート再編成
  DXGIオン+ドッキングがオフの状態で、VRAMが表示されないケースへの修正として、VRAMのルートを再編成。
  VRAMにおけるDXGIオプションの仕様を変更し、レガシーを強制するスイッチではなく、DXGI由来とライブラリ由来のどちらを優先するかの設定に変更。
  以降は環境により表示可能なデータがあれば、可能な限り表示されるようになります。
  NVIDIAのライブラリからのVRAM取得は、レガシー用に重複して作成されることはなくなり、GPU情報で生成済みのものを参照する形に変更されています。


repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240119-221756.zip

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/20
1.2.3.
添付いたします。

6.
確認しました。
NVOとD-Vramて結構数値が違うんですね。

[appended] txt

Gakuto Matsumura - Developer 返信 01/20
> 1.2.3.
見事に何もないですね。
エラーすらでていない…

一つ追加で確認をお願いしたいのですが、「設定」「日時」「システム稼働時間」をオンにした場、内容は異様なものではなく、正しい時間がカウントされていっていますか?

利用側としては関係のない部分ですが、内部として参照元になるOSのシステムが破損している場合、この「システム稼働時間」の結果も明らかにおかしい、化けた時刻になるので、そこが正しい時間数でカウントされるかを確認してほしいです。


> 6.
DXGI由来とライブラリ由来は、こちらでも数パーセントの違いを確認していますが、グラフィックボード内部で予約されている容量のようなものが、込みとして出るか、省かれて出るかの違いのような気がします。
こちらの環境では、空き容量の値は同じでした。

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/20
高速スタートアップがONになっていて1day 23:00とかになっていました...
それでも数日前にヘルプに書いてあったシフト+シャッドダウンしてたので、おそらく普通の値ですね。
タスクマネージャの稼働時間も同じ値で正常に見えます。

Gakuto Matsumura - Developer 返信 01/20
なるほど。
では、純粋に本来ならば取れてないとおかしい部分や、何がとれるかを全て列挙するテスト専用のものをさらに追加したものを作成しました。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240120-232436.zip

こちらで再度ログの方をお願いします。

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/21
大変お手数をおかけしております。
ログを上げさせていただきます。

[appended] txt

Gakuto Matsumura - Developer 返信 01/21
なんでだろう…
ドライブレターの認識そのものはCDEFGとYがとれているのに、肝心のOSのカウンターのリストが何一つかえってきてない…

Gakuto Matsumura - Developer 返信 01/21
Totalすらない…!?

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/21
ワイのぱそこんは実は幽霊・・?

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/21
すみませんすみませんすみません
lodctr /qの内容でディセーブル見落としありました
[PerfDisk] Performance Counters (Disabled)でした
レジストリエディタから値0にしたら正常動作しました

100%こちらの環境なのだからなんかあるだろうと手あたり次第起動してみていたら
パフォーマンスモニター起動時に

これらのカウンターを追加できません:

\PhysicalDisk(*)\% Idle Time
\PhysicalDisk(*)\Avg. Disk Queue Length

なるポップアップが出てヘルプの内容をもう一度実行しなおしてみていたら見落としを発見いたしました
learn.microsoft.com/ja-jp/troubleshoot/windows-server/performance/manually-rebuild-performance-counters
 このページの レジストリでカウンターが無効になっていないことを確認する セクションを参考にしてレジストリを弄ってみたら直ったようです

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/21
ロードキャッシュを含む のチェックを外しても動作しています。
ログにも生命感が戻りました

大変お手数をおかけしまして、申し訳ございませんでした。

[appended] txt

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

思ったよりもこのあたりはややこしいようで、報告後に調べてみてこれかもしれないとlodctr /qに関する記載をとりあえずわかってる範囲でヘルプに書き足して作業を進めていました。
これに関してはこちらの認識と案内不足でした。

このあたりのlodctr /qの内容をレポートかなにかで実行できないかと思って、文字化け問題と格闘し、まとまったら報告しようと思いましたが、先にずばりのOSの正規なドキュメントを見つけて試してもらえたようで、丁度最適解かつ正式なものなので、ヘルプにもこのURLを追記しておきました。ありがとうございます。

レポートに突貫ではありますが、トラブルシューティング的な感じで、このlodctr /qの結果を呼び出せるようには組めたので、とりあえず現行での以下二つの未解決

・Intel HD Graphicsのレガシー(または全て)の温度がとれない問題
・「ソフトウェア描画+レイヤード+ドットフォント+文字枠+倍率指定」の条件で、文字枠にも倍率が適用されて太くなってしまう問題

の、当面解決しなさそうな2つだけかと思うので、一旦これで出してみようと思います。

後ほどまた問題等を確認されたら報告して頂けると助かります。

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/21
お役に立てたようでよかったです
久しぶりにDiskIO一覧と対面出来てうれしゅうございます
ありがとうございました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

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
返信

[Closed] 不具合 論理ドライブが表示されない
#1003
りんりん - 2240@wPwZZXtmPwu/PP1lGfwuttttmmZ1t/u1 返信 2024/01/20 17:37
お疲れ様です。
突然なのですが論理ドライブの項目が空白のまま表示されなくなってしまいました。
windows・thilmeraの再起動どちらとも効果なしです。ですが同じバージョンのthilmeraをダウンロードし論理ドライブをオンにしてみたところしっかり表示されてしまったのでバージョンの問題ではないと思います、

論理ドライブが表示されない方のiniを添付させていただきましたので対応のほどよろしくお願いします。。

[appended] ini

さた - 2238@2PPZXgfZ22m0Z/XZ0ul2PGmmJ0Gf2g 返信 01/20
横から失礼します。#1001 で同じ不具合を報告した者です。
#1001 のテストビルドを試してみてください。

さた - 2238@2PPZXgfZ22m0Z/XZ0ul2PGmmJ0Gf2g 返信 01/20
>横から失礼します。#1001 で同じ不具合を報告した者です。
>#1001 のテストビルドを試してみてください。

ごめんなさいこれ無視してください

りんりん - 2240@wPwZZXtmPwu/PP1lGfwuttttmmZ1t/u1 返信 01/20
テストビルドを試したところ無事解決しました!
過去ログを確認せず投稿してしまい申し訳ございませんでした。
教えてくださりありがとうございます。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 スリープから復帰するとタスクバーにフィットしない
#1000
na - 2236@2PPZX/Zmu/0/m/1fGfJ2utP0XlgZw 返信 2024/01/17 22:43
いつもthilmeraを愛用させて頂いております。

私の環境だけなのか分からないのですが、PCをスリープから復帰させると「位置フィット -> タスクバー」がONになっていても、タスクバーを超えてモニター端にフィットしてしまいます。
いつもは同時に「左下固定」もONにしているため、スリープ前は左下のタスクバー端に固定されているのが、スリープ復帰後はタスクバーに乗り上げて左下のモニター端に固定されてしまいます。

OSはWindows 11 22H2で、サブモニターにロックして使用しています。

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

こちら、環境による部分もあるなので、今のところディスプレイが変更された場合にモニターのエリアは更新されるはずですが、もしかしたら環境とモニターの種類により、収集がモニターの復帰より早かったりする可能性とかもあるかもしれません。
もしそちらのケースである場合は、スリープ復帰から一定時間後に再収集を行うような挙動がいるかもしれません。

とりあえずひとまずOSがレジューム(スリープなどからの復帰)された際の通知の時点でも、モニターの各サイズ情報を更新するようにしてみました。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240117-232942.zip

こちらで改善されるか、それとも効果がないかを確認お願いします。

na - 2236@2PPZX/Zmu/0/m/1fGfJ2utP0XlgZw 返信 01/18
ありがとうございます。
頂いたファイルを解凍し、thilmera7.iniをコピーしてから起動して同様の手順を試してみました。
が、スリープ解除後に数分待ってみても直る様子は見られませんでした。
タスクバーアイコンを右クリックしてから「プログラム再起動」を選ぶと正常な動作に戻ります。そしてまたスリープすると再発します。

Gakuto Matsumura - Developer 返信 01/18
なるほど。
やはり復帰時に取得自体はされているが、環境依存によりモニターがまだ復帰していないタイミングで取得して、無い物と扱われているような感じかと思います。

こちらのテストでは、サービス稼働開始の時に、モニターがまだ有効ではない場合に、モニターの幅が検出されるまで待機する。というループを、モニター変更や電源復帰時にも適用してみたものになります。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240118-004610.zip

na - 2236@2PPZX/Zmu/0/m/1GJw/1XG0ZGX/mP1/ 返信 01/18
試しましたが、相変わらずでした。

thilmeraのウィンドウを置いているモニターを
・「設定」アプリで識別したときに識別番号1と表示されるモニター
・「設定」アプリでメインディスプレイに設定しているモニター (識別番号3)
の両方で試してみても同じ症状です。
(普段は識別番号2のモニターに置いて使っています)

Gakuto Matsumura - Developer 返信 01/18
なるほど。シングル前提ならこれでいけるはず。というものだったのと、配置はともかく、オフにしても存在はしているHDMI接続とちがって、オフにすると完全に無いものとして消滅するDisplayPort接続だと思うので、OSの復帰ではなく、モニターの復帰のコールバックの方。という事は分かるのですが、ディスプレイ変更時に更新すると、モニターの復帰が間に合ってない、という感じですよね…

どうしたものか。
とりあえずどこでどのタイミングでどうなってるのかわからないので、以下でディスプレイ変更などの感知と、その時の取得できモニターの内容をログ出力するものを作りました。
まずはそもそもそどういう状況なのかを把握したいです。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240118-192611.zip

na - 2236@2PPZX/Z1gZ0G1glGJw/1XG0ZGX/mP1/ 返信 01/19
いただいたビルドを実行し、「起動→スリープ→ウェイクアップ→終了」の一連の流れを行いました。
生成されていたファイルを圧縮した物を送ります。

ちなみに、グラボ側はすべてDP端子で、モニター2,3はDVI変換ケーブルで接続されています。モニター1はモニター側もDPです。

[appended] zip

Gakuto Matsumura - Developer 返信 01/19
確認したところ、モニターの取得は問題なく、モニターの配置がおかしくなったわけではないようです。

原因はまだわかりませんが、気にすべきはポジションの維持をしている右下固定が、再コールされているかどうかのような気がするので、ディスプレイ変更が発生した時に、表示されているウィンドウに、ウィンドウのベーシックな更新を呼び出すフラグをつけるというのを試しに作ってみました。

ウィンドウ位置が結果としてどこになったのかのログも追加しています。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240119-004416.zip

na - 2236@2PPZX/Z1gZ0G1gl/ww0l1w1t1lXfXPX 返信 01/19
今回も期待した動作になってはいませんでした。
ログを送ります。

[appended] zip

Gakuto Matsumura - Developer 返信 01/19
確認と計算をしたところ、どうやらOSのスリープからの電源復帰、かつモニター構成の変更、どちらの時点でも、タスクバーが存在していない。という結果になっているようです。

なので、記録する部分のさらなる詳細化と、タスクバーが変更された。という通知がくるはずの場所にも、同様の処理を追加しました。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240119-020612.zip

こちらで再度ログの取得をお願いします。

na - 2236@2PPZX/Z1gZ0G1glXXfZPZmGfP2uJGf0 返信 01/19
今回のビルドで、スリープ復帰後にタスクバーにフィットしているのが確認できました。
ログを送ります。ご確認おねがいします。

[appended] zip

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

どうも流れとしては、タスクバーの変更に関しても、スリープ復帰後の初回はタスクバーがない状態のものが返ってきているようでした。
なので、起動した後の最初のウィンドウ位置の補正では、タスクバーのない右下につきます。

追加しているタスクバーの変化でも再収集を行うという内容により、2回、3回のタスクバーの変更ではタスクバーエリアが復帰しているので、そこでもう一度移動、という流れになっています。

このあたりはOSの挙動もあるので、ひとまず行けはしたということで、以下は実際の実用に耐えうるであろう形に変更したものです。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240119-041246.zip

こちらの変更点は、通知の度に全て実行ではなく、周期的なループの中で、通知がきたら再収集する。としうものに変更しています。

前回までのは、可能性のあるやつがきたら全て即収集の実行だったので、スリープ起動時に、6回行われていました。

こちらのテストで使用感に問題なければ、これを本採用としたいです。

na - 2236@2PPZX/Z1gZ0G1glXXfZPZmGfP2uJGf0 返信 01/19
何度かスリープに移行させたり、モニターに全画面表示させてみたりと実用的な動作を行ってみましたが、とくに表示のチラつき等はなく、見る限りでは動作に問題はなさそうです。

ありがとうございます。念のため、ログも添付しておきます。

[appended] zip

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

それでは以後のテスト及び、次回のfixではこれを採用しようと思います。

na - 2236@2PPZX/Zmu/0mP0mJtfJwlwZGPlZftm/ 返信 01/20
よろしくお願いします。ご対応いただき、ありがとうございました。
素敵なツールの開発、応援しております。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 論理ドライブ表示が不安定?
#1001
さた - 2238@2PPZXgfZ22m0Z//XPl2Z2lJ2w1w2ll 返信 2024/01/18 02:04
いつもお疲れ様です。
#998と同じバグが発生していたため、同スレッドのテストビルドを使用しています。
通常時に論理ドライブが消えるバグは解消されましたが、「壁紙」タブを開閉するとthilmeraの論理ドライブが消えます。
また、gifに録画していませんが、thilmera 設定ウィンドウのタイトルバの上にカーソルがあるときだけ論理ドライブが表示されます。
よろしくお願いします

さた - 2238@2PPZXgfZ22m0Z//XPl2Z2lJ2w1w2ll 返信 01/18
iniです

[appended] ini

Gakuto Matsumura - Developer 返信 01/18
こちら、調べた結果、根本的な問題のようなので、論理ドライブの表示する内容の更新と、描画の更新を再編成してみました。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240118-192611.zip

ちと別件によるモニター関係のログがでますが、今のところは関係ないので無視してください。

この「thilmera 設定ウィンドウのタイトルバの上にカーソルがあるときだけ論理ドライブが表示される」というのは、再現を確認する前に論理ドライブの方を修正しましたが、恐らく全更新のようなものが走る可能性がありますね。

これはこれで後ほど調べておきます。

さた - 2238@2PPZXgfZ22m0Z/f20m2wtJXw0GmJJ2 返信 01/20
ありがとうございます。修正されておりました。
今後のアップデートもぜひよろしくお願いします。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 論理ドライブ表示が機能しない
#998
elphe - 2235@1PwZwX1/PPZ/PPG2JG1X0wtgPmGJwwuZ 返信 2024/01/16 22:05
設定にて、項目>ドライブから「論理ドライブ表示」をONにして使用していますが、いつの頃からか表示されなくなっていました。(最近気づいたのでいつからかは不明)
どうやら、ドライブそのものが検出できていないわけではなさそうですが……

スクリーンショットの空行部分がその項目です。「論理ドライブ表示」をOFFにすると、空行がすべて消滅するのを確認しました。
また、「ドライブリスト(表示/非表示)」のチェックボックスをいじると、存在するドライブのチェックを外したときに限り空行が1行消滅するのを確認しました。

Gakuto Matsumura - Developer 返信 01/16
おや…
とりあえず設置場所の"thilmera7.ini"ファイルをここに添付して下さい。
現行の最新からは「設定」「thilmeraについて」「詳細」の<path>をクリックすると設置場所がエクスプローラーで開かれます。

Gakuto Matsumura - Developer 返信 01/16
あ、ああぁぁぁ…

古の作った事を鬼のように後悔したデコキューブがちらっと見えますね。
再現できました。
ちょっと直します。

elphe - 2235@1PwZwX1/PPZ/PPG2JG1X0wtgPmGJwwuZ 返信 01/16
とりあえずthilmera7.iniを置いておきます。
あと、デコキューブは結構気に入っています。

[appended] ini

Gakuto Matsumura - Developer 返信 01/16
以下にて修正を試みてみました。
#999と同様になります。

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

elphe - 2235@1PwZwX1/PPZ/PPG2JG1X0wtgPmGJwwuZ 返信 01/17
#998, #999の両方の不具合の解消を確認しました!
早急な対応ありがとうございます!

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 設定を無視して全画面表示時でもthilmeraが表示されることがある
#999
elphe - 2235@1PwZwX1/PPZ/PPG2JG1X0wtgPmGJwwuZ 返信 2024/01/16 22:24
再現手順は以下のとおりです。
1. 「ウィンドウ最前面」をONにしておく(ONにしなくても再現可能)
2. 「マウスオーバー非表示」と「アクティブな全画面(又はムービープレイヤ)時に非表示」をともにONにしておく
3. thilmeraを表示したままYouTubeなどで全画面表示をするとthilmeraが非表示になることを確認する(正しい挙動)
4. 次に、マウスオーバーでthilmeraを非表示にしながらYouTubeなどで全画面表示をする
5. マウスを、thilmeraがあった場所から離す
6. thilmeraが現れる(不具合)

Gakuto Matsumura - Developer 返信 01/16
こちら、その通りにやってみたら本当に再現できました。

以下にて修正を試みてみました。
#998と同様になります。

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

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 要望 GPU表示順序とVRAM順序の不一致
#996
西東北南 - 2234@PPwZl1Pw2g1GPP20uw1Z201lJu2X1/Z 返信 2024/01/16 01:58
当方、内臓GPUのHD Graphics P530及びQuadro M2000Mを搭載したマシンを利用しています。
GPU使用率のグラフは
GPU1N
GPU0I
の順となっておりQuadroが上位に見えるのですが、VRAMは
D-Vram0
S-Vram0
D-Vram1
S-Vram1
となっており、HD Graphicsが上位です。
この順位を一致させて頂けないでしょうか。

Gakuto Matsumura - Developer 返信 01/16
なるほど。確かに環境によっては、物理スロット番号の並びが順不同になる可能性がありますね…

私の環境ではきっちり0,1,2の並びだったので失念していました。

現状、NVIDIAに該当する処理。Radeonに該当する処理。Intel(HD,Arc)に該当する処理。
という順序になっています。

NVIDIA,Radeon,Intelの順番をソートするというのは、後に予定しているGPU系処理の再編成に、要件として追しておきます。

VRAMの順番については、「メモリ」「VRAM」に追加されている、「GPU情報エリアに表示する」を使用すると、以下スクリーンショットのような形で、該当のGPU情報配下に表示位置がドッキングするのですが、これでは要件は満たせなさそうですか?

西東北南 - 2234@PPwZl1Pw2g1GPP20uw1Z201lJu2X1/Z 返信 01/16
「GPU情報エリアに表示」を試した所、対応するGPU使用率直下にメモリ使用率が正しく配置されました。
当面これで運用させて頂きます、ありがとうございます。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 特定のNIC (Mellanox Connect X-3)が認識されない
#994
梨々花 - 2232@pCkEkWlf 返信 2024/01/10 20:24
いつもThilmera7を愛用しています。開発ありがとうございます。

下記環境でConnect X-3の通信のみThilmeraのネットワークI/Oに表示されません。
Thilmera設定画面のデバイスリストもRealtekのみで、Connect X-3が表示されません。
Connect X-3での通信は問題なくできています。ただしインターネットには接続しておらず、IPアドレス手動割当で別PCと直結しています。

Windows 11 Pro
DeskMeet X300
Ryzen 5 5600G
NICはオンボードNIC(一般的なRealtek GbE)とPCI-Expスロットに挿したMellanox Connect X-3(10GbE接続)

なお別PCで同様にWindows 11 ProとConnect X-4を使用していますが、こちらは正しく認識しネットワークI/Oが表示されています。
取り急ぎご報告まで。

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

こちら、恐らくハードウェアインターフェースのフラグがないなどの可能性もあるので、まずは以下テスト版の実行にて出力される、"debug_log.NET_IO.txt"というファイルをここに添付して下さい。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240110-211259.zip

梨々花 - 2232@pCkEkWlf 返信 01/11
添付します。

[appended] txt

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

やはり物理インターフェースのフラグが立っていないようですね。
どうなってるのかわかりませんが、とりあえず試験的に接続中のフラグがたっているものも有効なものとするようにしてみましたが、多分これすると他の環境で意図しない余計なものが出てくる場合がありそうです。

一応以下テストではデフォルトとしておき、それで改善されるならば、仮設置した設定の詳細から変更する場所のデフォルト値を入れ替えます。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240111-004030.zip

梨々花 - 2232@pCkEkWlf 返信 01/11
ご対応ありがとうございます。
作成いただいたビルドを試したところ、問題なく2つのネットワークアダプタが表示されるようになりました。
他にこちらでご協力できることがありましたらご遠慮なくお知らせください。

Gakuto Matsumura - Developer 返信 01/11
ありがとうございます。
できればどういう結果となったのかのログがほしいので、今回の分の"debug_log.NET_IO.txt"がほしいです。

梨々花 - 2232@pCkEkWlf 返信 01/11
どうぞ!

[appended] txt

梨々花 - 2232@pCkEkWlf 返信 01/11
もしご要望と違う内容でしたら教えてください。

Gakuto Matsumura - Developer 返信 01/11
あら、ログ出力の変更は適用されてないものだったようです…

こちらでログ出力をもう一度お願いします。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240111-233511.zip

目的のネットワークアダプタの他の数値がどうなっているのかを見て、なにかしら判断材料がないかを確認したいです。

なお、このテストバージョンでのデフォルトは旧来となっています。
設定のネットワークIO、詳細、test: Adapter Typeを0にすると前回のテストと同様になります。

ログ出力の本題には永久しません。

梨々花 - 2232@pCkEkWlf 返信 01/14
遅くなりましたがお送りします。こちらでよろしいですか?

[appended] txt

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

確認したところ、どうもおおよそ取得できる情報を全部並べても、特に前のテスト版で確認できたフラグ以外で特に差がはっきり分かるものはなさそうでした。

ひとまず、先ほどデフォルトチャンネルのch1にrev14を展開したので、そちらで「ネットワークI/O」「詳細」「test: Adapter Test」を0番に指定してみてください。

この指定により、前回のテスト版と同様の状態になります。

ひとまず0b180系はそろそろ最終安定版にしないといけないので、今回の正式リリースではオプションとし、次回以降にテストしていく段階で、とくにこのオプションによる弊害が顕著に起こらなさそうならば、あらためてこのテストモードを標準とする予定です。

梨々花 - 2232@pCkEkWlf 返信 01/14
ご対応ありがとうございます。
いつも使用しているThilmeraをアップデートし上記の通りtest: Adapter Testを0番にしてThilmeraを再起動しましたが、
・ネットワーク速度、グラフ、NETスピードがどのNICのものも反映されなくなりました
・Thilmera全体が縦に間延びし、アップデート前の2.5倍ぐらいの高さになりました。
取り急ぎご報告です。

Gakuto Matsumura - Developer 返信 01/15
お、ぉぉぅ・・・

とりあえず設定のiniファイルと、元はどんな感じだったかの情報を下さい。
あと、設定のデバイスリスト欄はどうなっていますか?

test: Adapter Testが1の場合は問題ないのでしょうか?

梨々花 - 2232@pCkEkWlf 返信 01/15
ネットワークI/Oが表示されないのは私がデバイスリストからSHOWにしていないだけでした、すみません。。。
NIC2つをSHOWにすると正しく表示されました。ありがとうございます。

表示が間延びする件、スクリーンショット2枚とiniを添付します。
ドット文字表示をONにすると正しい?高さになり、アウトラインフォントを指定すると間延びする気がします。スクショ2枚のうちドット文字のほうがアップデート前のウインドウ高さに近いです。

[appended] 7z

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

こちら確認をお願いします。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240115-004225.zip

使用している設定ファイルをコピーして、戻っている。あるいは行間の調整により戻せる範囲かの確認をお願いします。

Gakuto Matsumura - Developer 返信 01/15
こちら、確認可能な範囲の問題を補正、修正したので、リリースされている最新rev16にて確認をお願いします。

梨々花 - 2232@pCkEkWlf 返信 01/16
rev17にて、アウトラインフォント選択時でもウインドウ高さが正常になりました。
即対応ありがとうございます!

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 指定したフォントの文字枠が消えていました
#993
マークX - 2146@wPwZPXtmP/XfPP1ff0f2/XgG01t//Pmw 返信 2023/12/30 18:54
アプデ以降、見え方がいつもと違っていたので確認したところ文字の枠が付かなくなっていました。

どちらも設定を全部一度初期化して
ウィンドウ設定の背景色を透明化とレイヤードを有効、フォント設定でドット文字表示を無効、選択したフォントは@fixedsysとなります。

添付画像
上が0b178 rev.8
下が0b180 rev12
です

Gakuto Matsumura - Developer 返信 2023/12/30
こちら、たしかに仕様を変更した部分であり、「ソフトウェア描画+レイヤード+文字枠」の設定における文字枠適用に、OSフォントは含まれなくなっています。

ハードウェア描画においては全く変更なし。
ソフトウェア描画におけるドットフォントについては、ハードウェア描画と同等の品質となります。

ソフトウェア描画におけるOSフォントの文字枠は完全に失念していました。

こちらは旧仕様の方は、レイヤードでの描画前の再計算で、メインカラーと完全一致するドットの周囲8マスに枠を追加する。という強引かつ非効率なものだったので、新仕様ではハードウェア描画と同様に、ドットフォントのキャッシュ生成時点で、枠としての描画データも作成しておき、直接枠を含めて文字の記載を追加する。というものに変更しています。

現状、この問題をすぐにカバーすることはとても困難なため、応急措置として以下の対処ではだめでしょうか?

① 「設定」「フォント」を開く
② 「OS Font→'dotfont.custom.bmp'」を押す
③ 「ドット文字表示」をオン
④ 「ドット文字表示」以下の「@なんとか.bmp」とかかれている所をクリックして開くメニューから、最も下にある「dotfont.custom.bmp (edit)」を選択する

この手順にて、英数字に関してはフォントの見た目は損なわずに文字枠がつくようにできるはずです。

ただ、こちらで@fixedsysを選択したところ、指定と実際の高さが異なり、行間が少なく重なってしまっているなど、開発上、意図していない表示崩れが発生しているのと、日本語などの英数字以外ではOSフォント仕様が適用されるため、新仕様では今の所、文字枠はつきません。

マークX - 2146@wPwZPXtmP/XfPP1ff0f2/XgG01t//Pmw 返信 2023/12/30
実環境では美咲フォント製作者様のサイトにあるk8x12というフォントをsize12で使用していました。
これは他所から落とす必要があるので選択画面でたまたま近い位置にでた@fixedsysでの撮影となりました。

bmpフォント化すると若干幅が増えますがこのまま色々カスタマイズしてみます!
返信ありがとうございました!

Gakuto Matsumura - Developer 返信 2023/12/31
たしかに厳密に確認してみると、ドットフォント変換時に幅と高さが+1ドット増えていそうな感じですね。

このあたりも含めて、今後調整していきます。

あと、美咲フォントk8x12で調べてみましたが、これ滅茶苦茶素いいですね!
ちょっとあまりにも良いので直接コンタクトとってみます。

Gakuto Matsumura - Developer 返信 01/02
こちら、ch0=DEVのrev12 DEV2にて、試験的なドットフォントへの変更のテストを入れました。

確認頂けると助かります。

マークX - 2146@wPwZPXtmP/XfPP1fw1wt/21lZlZgm0g2 返信 01/03
確認したところ元のフォントとサイズが一致しました!
gifはOSフォント⇔ドットフォントの状態で、今回はk8x12となっています

一つ下の段にあるtestも試しましたが、若干文字の間隔が詰められるようですね。(よりコンパクトになるのでとても好き)

暫くDEV版のまま使って様子を見てみますー!

マークX - 2146@wPwZPXtmP/XfPP1fw1wt/21lZlZgm0g2 返信 01/03
あ、あと
明けましておめでとうございます!
今年もよろしくお願いします~

Gakuto Matsumura - Developer 返信 01/03
ありがとうございます!
今年もよろしくお願い致します。

先ほど、更なる強化版をDEV4としてch0で更新しました。

教えていただいた美咲フォント製作者様からは、ソフトウェアへ正式に組み込んでよいとのお返事を頂いたので、今回のテスト版より正式にドットフォントとして取り入れています。

こちらのrev12DEV4でとくに問題が発生しなければ、正式にrev13として更新を予定しています。

マークX - 2146@wPwZPXtmP/XfPP1fJ2Xw20mu1mf0wJtt 返信 01/05
日時→日本表記を有効化、フォント→Test→OS font...の有効化で曜日の表示がおかしくなるようですね
初期設定から上記の設定、reb12 DEV4

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

ちょっと機材トラブルやら、なんやかんやで時間かかりました。
上記、新ルートにて、英字以外がきた際に、ポインタが正しくシフトされないバグがあったため、修正しています。
ch0: rev12-DEV7
こちらでテストをお願いします。

ちょっと、曜日のドットフォント化もやろうかと思いましたが、どのみち対応するフォント全てをドットフォントとしてキャッシュ化するものを計画しているので、0b180世代での曜日のドットフォント化は、次バージョン以降に見送ります。

マークX - 2146@wPwZPXtmP/XfPP1fmfPZ/mf10f/1/2mu 返信 01/09
お疲れ様です、DEV7にて曜日の表示が直っていました!

Gakuto Matsumura - Developer 返信 01/09
ありがとうございます!
もうしばらく様子をみて、とくに不具合報告がなさそうならば、0b180系の最終安定版候補として正式リリースに出す予定です。

CLOSED : 追記した内容は通常通り管理人に通知されます。

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
返信

[Closed] 報告 仮想WinXPで更新に失敗します
#986
SleepyF - 2221@e1dZYnLg 返信 2023/12/25 16:39
仮想マシンのWindows XPで、既存の 0b178 rev8 にて0b180 Rev.5へのアップデート
通知に従ったところ、署名が不正というエラーで終了してしまいます。
その際メモできていませんが lang ja imu ? 何とかエラーのダイアログも出ました。

その時点でそのまま thilmera7s.exe を起動させるとアップデータが起動したので
最新版を選んで[ダウンロード]しましたが、やはりエラーとなります。
バックアップでthilmera7のフォルダを戻してやり直しても(変化せず)エラー。
(先のlang云々エラーダイアログは出ませんでした)

Webからダウンロードした新版の thilmera7.upd.exe を実行してもアップデータが
起動して、[ダウンロード]しましたが、エラーとなって実行できません。

Win7, Win10では問題なく更新できています。
スクロールバーが動かす際に広くなるのは使い易いと思います。

SleepyF - 2221@e1dZYnLg 返信 2023/12/25
補足:thilmera7.upd.exe の実行の際インストール先のthilmera7フォルダの中身が空の場合もダメです。

Gakuto Matsumura - Developer 返信 2023/12/25
この件はこちらになります。
thilmera.com/page-help-36
新署名のプログラムは、XP,Vistaに関しては、新たにもう一つルート証明書にインポートする必要があります。
一応展開はされているので、配置されるreadmeフォルダのreadme.htmlに記載しています。

どうやって伝えればいいのかは悩ましいですね。
何せ「重要なお知らせ」を導入するまでは、どこに告知を書いてもユーザー数の1000分の1すら見てもらえなかったのですが、なかなか伝える方法がないのは相変わらずですね…

一応、そのあたりあるかとおもって、アップデーターは期限がそろそろきれる旧署名にしていますが、逆にXPなどは副署名のタイムスタンプが通らないので、そっちはそっちで署名の期間の終わりがきたらそのまま終わりだったりします。

現状、最新リリースの0b180シリーズが新署名。アップデーターは旧署名となっています。
一応今は新旧が共存しているので、アップデーターの中にメッセージを出すように変更することは可能ではありますが…

Gakuto Matsumura - Developer 返信 2023/12/25
あ、途中で止まるからドキュメントも展開されてないのか…

SleepyF - 2221@e1dZYnLg 返信 2023/12/25
ありがとうございます。署名登録で起動できるようになりました。
ところで署名ファイルは(初回エラーとなるのを諦めて)新しい版を入れないとインポートできないのでしょうか?私が気づいていないだけでWebで公開済みでしょうか?

Gakuto Matsumura - Developer 返信 2023/12/25
とりあえず、時間がない状態で証明書を探すだけで時間が溶けていって、場所がわからないから、とりあえず上手く動作する自分が発行されたページにある証明書を同梱している。というのが現状となります。

ここは正直私も気になってはいたのですが、探し方が悪いのか公開されているURLの中に、正しく動作する事が確認できたずばりそのままのセットの証明書が見つからなかった感じです。

とりあえず認証機関にこの件をメールしておきました。

要件は単純に、別個の単体はあるようだけど、そのままインポートして使える連結されたものが無いので、個別単体のもののURLを載せても意味ない…という事で、リリースを優先した形です。

このあたり、XPとVistaは完全自己責任の玄人志向だから、3年前の時も、証明書関係は理解した上での質問しかきてなかったし、まぁ、いっか!

と…

ちょっと年末にかかるので返事くるかわかりませんが、きてなんとかなりそうなら対処します。

ただ、オチとしてXPとVistaはサポート外ですと言われる可能性も結構あります。
少なくともSHA1ハッシュは2年前くらいに完全に閉鎖されたので、そのうちXPやVistaは無署名というヤバイ配布にするしかなくなる時がきそうです。

Gakuto Matsumura - Developer 返信 01/02
こちらまだかかっています。

単にダウンロードが可能な証明書の公開鍵が、パブリックURLのどこにあるか聞いているだけなのに、メッセージが5往復してもまったく話の入口にすら立てません…

Gakuto Matsumura - Developer 返信 01/03
こちら、ようやく望む回答が得られ、オンラインヘルプ、及びch0の最新テストより、readmeに追記しました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 最小化しても勝手に戻る
#982
kris - 2217@Gslg21Ra 返信 2023/12/25 01:34
0b180 Rev.3でデュアルディスプレイ時、右クリックまたはタスクトレイのアイコンから最小化した際、thilmeraがあるディスプレイと別のディスプレイにフォーカスすると最小化が外れて元の表示に戻ります。
thilmera-win64.exeもthilmera7s.exeも同様です。発生が確認できた設定ファイルを添付します。

kris - 2217@Gslg21Ra 返信 2023/12/25
(設定ファイル)

[appended] ini

Gakuto Matsumura - Developer 返信 2023/12/25
こちら、設定ファイルにて再現ができたので、再現の状態からの修正を行いました。
以下のテスト版にて改善されているか確認をお願いします。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20231225-022646.zip

Gakuto Matsumura - Developer 返信 2023/12/25
こちら、現在の最新であるhotfix5により修正されているかの確認をお願いします。

kris - 2217@Gslg21Ra 返信 2023/12/25
返信遅れてすみません。最新版で問題なく最小化できることを確認しました。

Gakuto Matsumura - Developer 返信 2023/12/25
確認ありがとうございます!

kris - 2217@JPwZ/l1G1t2XX1mg/PffXwt/uGJ 返信 2023/12/31
Rev12で再発しているようです。確認おねがいします。

Gakuto Matsumura - Developer 返信 2023/12/31
少なくとも前回頂いたiniでのテストで、問題は確認できず、再発しているとのことですが、再現はできませんでした。

Gakuto Matsumura - Developer 返信 2023/12/31
hotfix5の後に別の問題が発生し、表示非表示系はルールが作り直されています。

まずは再現されているiniファイルと環境の詳細を知らせて下さい。

Gakuto Matsumura - Developer 返信 01/02
こちら、他にrev12にて、表示非表示系のトラブルが再発している方はいますでしょうか?

kris - 2217@Gslg21Ra 返信 01/03
返信遅れてすみません。こちらのiniで発生しています。再発と表現しましたが、タスクトレイのアイコンクリックでの最小化では起こらず、最前面固定時、右クリック最小化した後、その時アクティブだったウィンドウと別のウィンドウを選択すると最小化が解除されるようで、どうも別の問題かもしれません。
環境としては、OSがWindows 11 Home Insider Preview Build 26016、グラフィック周りはRTX2070SにGame Readyドライバ546.33で、4K(150%スケーリング)のメインディスプレイとFHD(100%)のサブディスプレイです。ディスプレイに依存せず発生しています。
よろしくおねがいします。

[appended] ini

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

iniと再現方法の説明により発生条件がわかり、rev7修正後の仕様に統一させました。

以下で意図しない挙動が修正されているか確認をお願いします。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240103-003825.zip

kris - 2217@Gslg21Ra 返信 01/03
修正されていることが確認できました。ありがとうございます。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 質問 CPUやGPUのグラフ表示について
#991
sirichan - 2225@JPwZtmJG1f2wgflmmfJw2mlZm2X 返信 2023/12/26 23:17
お世話になります。
CPU等のグラフで棒グラフとなめらかなグラフの2つが重なっている状態ですが、
瞬間値と平滑値であるのは理解できました。
そこでですが、どちらかだけを表示することはできないでしょうか?
あるいは2つのグラフの流れる速さを同じにできないでしょうか?
(現状棒グラフのほうが早く流れている状態です。)

sirichan - 2225@JPwZtmJG1f2wgflmmfJw2mlZm2X 返信 2023/12/26
追記です。当方環境は以下のとおりです。情報不足しておりましたらご指摘ください。
Win10pro 64bit
0b180 Rev.9
Ryzen7 5800x
gtx2070super
です。よろしくお願いいたします。

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

これは恐らく20年ほど前からある初期も初期の仕様で、そこに言及されたのは今回の質問が初めてとなります。
確認してみると、確かに片方だけ表示する設定は作ったことがないようです。


CPUなどのグラフは、後ろの棒が瞬間値で、前が設定による平均などの処理後の値。
後ろの棒は一回2ドット(1ドット+空白)。前は1ドットで進みます。

IOグラフの後ろの棒は、読み書きそれぞれが発生したかしていないかのフラグを表します。
どちらも、そのまま同じ形状で載せると、どうなっているか認識できないためこうしていますが、それは元々アルファブレンド(半透明の色の計算)ができなかったはるか昔の話なので、需要があるならそのあたりの調整はしてみてもよさそうですね。


これは使用率グラフとIOグラフ、どちらもでしょうか?
単純にCPUなどの瞬間値が観たい場合は、前面の数値の計算オプションを設定すればできはします。

sirichan - 2226@JPwZtmJG1f2lJXGw01tGwug0XfX 返信 2023/12/26
早速ご返信頂きありがとうございます。
フォーラムの過去ログを漁ってもそれっぽいのがなかったので質問して良かったです…w

私としてはCPUとGPUの瞬間値が1番みたい項目です。
スクショ頂いた点いじってみたのですが、ふたつのグラフがおおよそ近い波形になるのは分かったのですが、流れる速さがズレるところにモヤッとしております。
→のでどちらか片方の表示にしたい、と言ったところです。

IOの棒グラフは要は0と1しかないということですよね?
認識が正しければこちらはそんなに気にしていないです。オプションとして棒グラフと波グラフのオンオフができたらそれはそれで嬉しいですが…

タイトルと別件で申し訳ないのですが、IOの波グラフが流れたあと(流れている時)にもうねうね動いている気がしますが、これはどういう仕様なのでしょうか?

いろいろ気になってしまい長文になってしまいました、申し訳ありません。
よろしくお願いいたします。

Gakuto Matsumura - Developer 返信 2023/12/26
> 流れる速さがズレるところにモヤッとしております。
うちのやつでは最初期あたりから当たり前の仕様すぎて、みんなそういうもんと慣れてしまってるか、思っても言わないかのどっちかだったかと思います。

うちはユーザー数がそれほど多くないのに、サイトを見る人が1000分の1以下。何かしらのフィードバックをしてくれる人がそのうちの…



IOグラフのうねうねというのは、多分アンチエイリアスの影響の話かなと思います。

IOグラフは標準で16フレーム分をまとめるので、横方向に16ドット分の平均値を表します。
なので、ハードウェア描画であろうと、ソフトウェア描画であろうと、ドットバイドットではないため、微妙にうねうねするかと思います。

これはここの設定を1にすればドットバイドットとなります。

このうねうねに関しても、流れる速度はともかく、16なら16枠とがっちりきめて最終の1ドットとして固定の内容を移動させる。というのもできはします。

sirichan - 2226@JPwZtmJG1f2lJXGw01tGwug0XfX 返信 2023/12/27
返信ありがとうございます。
> うちのやつでは最初期あたりから当たり前の仕様すぎて、
なるほど…
実は(?)当方ImpressWatchの記事を見て本日乗り換えてきたところでして、既にカスタマイズ性だとかデザイン性だとかで感動しまくりなところでさらに開発者のかたから直接丁寧なサポートを受けれてもう大感激しております。
IOのほうもご説明頂きありがとうございます。後で試してみます。

質問の件は解決いたしましたので、クローズとさせていただければと思いますが、棒グラフと波グラフの表示/非表示は機能のリクエストということで、いつか実装して頂けたら嬉しいです。

今後も使用させていただきます!

Gakuto Matsumura - Developer 返信 2023/12/27
おお、丁寧にありがとうございます!
そして、新規の方から根幹部分を含めたフレッシュな意見がもらえる程度のレベルには到達できたようでとてもうれしく思います。
(以前までは内容が理解しにくく、使おうとしてもだいたいの人が諦めるような感じでした。今もそれほどシンプルではないですが…)

なんだかやたら優しいテンションでこちらも感激です。

とりあえずこの件は工数としてはほぼ分岐を作るのみくらいなので、落ち着いた後でのch0での更新。最終的には次バージョンで全体適用という感じのスケジュールになります。
この件にとりかかった後に緊急なバグが発覚しない限りは、基本的にしばらくはch0のみとなると思います。

よろしくお願いします!

Gakuto Matsumura - Developer 返信 2023/12/28
こちら、暫定のテスト第一弾をch0=DEVにて更新しました。
0b180 Rev.9 DEV1

○ スタイル設定に、グラフの稼働率とIOそれぞれの、前面背面の表示を調整するタイプ指定オプションを追加

基本的にやったことは、usage, ioそれぞれで、前面背面の、両方、前のみ、後ろのみ。の3択オプションを追加した形の単純なものになります。

「設定」「スタイル」に追加しています。

sirichan - 2225@JPwZtmJG1f2g1ftg2JZ2fXmf1GX 返信 2023/12/30
遅くなりました。
先程確認してみましたが大満足です。
年末お忙しいところ実装いただきありがとうございました!
良いお年をお迎えください!

CLOSED : 追記した内容は通常通り管理人に通知されます。

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