Orz日記 by Akio Morita

_ [SAD]Random/Framework, Date/TAIバックポート

CVS MAIN trunkに random_* API周りと DateTAI extension moduleをバックポート完了

Random[]の入れ換えと iseed追い出しのバックポートは、 もう少しコードの改修とテストをしてから... 特に、大量に疑似乱数を使うときは arrayで生成させないと 性能が出ないはずですし...

iseed版はインライン展開だったのでそこそこの性能が出るはずですが、 random_* APIは plugin関数を呼び出すので個別に生成すると 関数呼び出しのオーバーヘッドが無視できない... Orz

最速を目指すなら、呼び出し元を Cで書いて random_* APIの生成系APIを マクロ展開にした上で、Random Plugin ABI変更して framework側に 疑似乱数列のバッファーを持たせるべきかも(マルチコア環境では、 さらにダブルバッファー化して feeder threadを置いてバックグラウンドで 疑似乱数列を生成するとか...)

_ [LHC]LINX/Yファイルサポート

実装してみるが、もらったLINX/Yファイルの TFSパースに失敗するので 入力ファイルに手を入れて動作を確認する。

どうやら、TFSパーサーがエラーになるのは貰ったLINX/Yファイル上での TFSフォーマットの出現順序が異なるからのようだが...

TFSフォーマットの正式な仕様をもらっていない(求めたけど簡単だから 口頭で説明すると言われて仕様書が出てこない)、フォーマットの 説明には出現順序の自由度に関するものが無かった上に、MADXの 出力をリファレンスにしろと言われたので、読めない件に関しては 仕様と言うことにする。

文句が有るなら、TFSの正式な仕様書を書いてもらうことにしよう(w

_ [雑記]nvidia-driverのDPI自動設定

デフォルトでEDID情報からDpiが自動設定されるが、MetaModes経由で画面を90 or 270度回転させていると画面が正方形で無い場合はおかしくなる模様

Dpiの自動計算において、pixel数は意図通りに回転したものが使われるが、画面の物理寸法はEDID情報のまま回転していないものが使われて、歪んだDPIが設定される模様

結果、Type1フォント等のベクトルフォントのレンダリング時に激しく歪んだレンダリング・レイアウトが行われる

特にマルチヘッド構成時に一部のパネルを回転させているケースでは、どの出力系がDPI設定に参照されるかで結果が変わるので、パネルの接続構成変える時は要注意 (意図せず自動設定されるDpiが変わる)

普通のマルチヘッド構成なら、UseEdidDpiオプションでDpi自動設定に参照するモニタへの出力ラインを0 or 180度で設置したメインモニタに固定しておくと良い

手動で設定する場合は、UseEdisDpiオプションをFalseに設定した上で、DPIオプションに<horizontal-dpi> x <vertical-dpi>の形式で所望のDpiを設定する