32bit版のCool VL Viewerにて、private memory poolのサイズ定義に関する潜在バグ

バグ状況を先に述べると、32bit版のCool VL Viewer ver1.26.xx.xx (1.26系全てだと思われます)に於いて、デバッグ情報設定にて変更可能なPrivate Memory Poolのサイズ定義があるのですが、その項目の数値が正しく解釈されてなく、初期状態であっても表記のサイズ(256MB)とならずに、常に128MBとして動作してしまうというバグが潜在していました。エラーで停止するようなクリティカルな問題ではないことから誰も気が付かなかったのでしょうね。。。lol

もっとも今時TPVでもないはぐれなビュワーのCool VL Viewerなんて使っている人は希で、しかも32bit版などを起動している人は居ないのではないかと思いますが、もしも使っている人が居たらと思うとブログ記事に残しておこうかなと思った次第です。内容的には本家に報告するべき事案レベルですが、もはや本家では32bit版の取扱はなく、さらには32bit版特有のPrivate Memory Poolの機能は64bit版に特化したときに全面的に削除となっているので、報告をする対象が存在しない状態ですから本家の方では話題に出さないようにお願いします。

ことの発端は、最近よくLinden Realmsとかで遊ぶのですが、遠景描画が少し不鮮明かと思いグラフィックドライバーの設定を変えて(異方性フィルタの倍率をドライバー側で固定にした)みたのですが、なんか動きがもっさりと引っかかる感じに思えるところがあって、変だなぁと思って何気なくビュワーの動作ログに目を通してみたところ

起動時に確保されるPrivate Memory Poolのサイズが128MBってなっているじゃありませんか！
たしか初期状態でも256MBだったよね・・・・？？

確認のために256、512、640　と、値を変えて起動してみても全て128MBとログに示されます。

謎を解くためにコードを追いかけてみました

この部分(llappviewer.cpp)がsettings.xmlから値を取りだしている箇所で単純に PrivateMemoryPoolSizeの値を取り込んでいるだけです。

そしてCallされる側のClassの中身が

こちらがClassの中身で(llprivatememorypool.cpp)にあります
最後の行で呼んでいるllMaxという関数は、どちらか大きい側を返却するだけの関数です。
比較対象の MIN_POOL_SIZEの定義から数値の単位はバイトであることが伺えます。
しかし呼び出し元が渡しているのはsettings.xmlの数値そのままです。
256 と 128*1024*1024を比較したら256じゃなくて640とかセットしても
128*1024*1024の方が明らかに大きいですからねぇ・・・
何をセットしても128MBとなる訳です。

つまり、XML上で右のようなMByte単位での数値ではなく
左のように元からバイト単位で設定すれば問題なく動くってことです。

説明書きにはMByteとなっていますが、強引にバイト数で値をセットします。
(この画像の場合は、256 MB = 256 x 1024 x 1024 = 268435456 Byte)

そうすると・・・

ちゃんと256MBを確保してくれたようです。

そんな訳でPrivateMemoryPoolSizeを指定しても(指定しなくても)256とかMB単位での指定では正しく動作せず、全て128MBの設定となってしまうってことでした。修正必須な内容ですが、過去バージョンのビュワーとの同居や同時使用という場面を想定した場合に同じ項目がそれぞれで別の解釈となってしまうのは良くないので互換性を保つために現状では、あえてそのままにしたいと思います。というか、いままで初期値だったから256MBのPrivateMemoryPoolSizeで動作していたと思い込んでいたのに実際は、ずっと128MBというリミッターが効いた状態だったという衝撃的な事実です。それを本来あるべき仕様に変更したら、どのように変化が起こるのか数字だけでは全く想定できないので、とりあえず、まずは２倍容量の256MBとして使ってみようかなという次第。ちょっこっと256MB仕様で起動してみたけれど、128MBの封印を解いて凄く変わった！？とかの感触もなく、なんとなくスムーズになったような・・・ってぐらいかなぁ。正直、よく分かりませんが、使用する環境によっては福音となるかも知れませんね。

ちなみに３系のビュワーであるXP用最終の公式ビュワー3.7.28では