Mona/移植
MonaGUIの非矩形ウインドウのテストを兼ねてマスコットアプリを移植。(apps/gui/kukuri)
スクリーンショット
オリジナル
- Cygwinでコンパイル可能
- Windowsバイナリ（Cygwin非依存）同梱
- FLTKは静的ライブラリとヘッダのみ同梱
コメント
コメントはありません。 コメント/Mona/移植/マスコットアプリ?
- 同時起動の際に、最初のプロセスにメッセージを送ってインスタンスを増やしてリソースを共有するように変更しました。そのためリソース枯渇が緩和されました。あまりに多く起動させると非常に重くなるので同時起動数を5人に制限しました。 -- Tino 2004-06-13 (日) 20:53:26
- 下の件ですが、ウインドウバッファやビットマップリソースはGUI.SVRが共有メモリに確保するので、共有メモリが枯渇した時点でGUI.SVRの動作がおかしくなり、すべてのMonaGUIアプリに影響を及ぼす結果となります。そのためWindows 9xのリソース不足と同種の現象であると書きました。従って下に書かれた懸念点は少し違いますので、特にコメントしません。 -- Tino 2004-06-12 (土) 22:36:42
- newでNULLというのは書き方が悪かったですね。Bitmapのインスタンスをnewしたとき、_objectがNULLになるというのが正確です。省略しすぎてすみません。 -- Tino 2004-06-12 (土) 22:42:51
- GUI.SVRで描画するようになった関係上、リソースもGUI.SVRで管理されています。そのためBitmapはguiserver_bitmapのラッパーになっているのが現状です。_objectというのはguiserver_bitmap*です。 -- Tino 2004-06-12 (土) 22:44:14
- 下の件、気になるところを書かせていただきます。>Tinoさん。 -- ひげぽん
- 巻き込んで死んでしまう件
- 他のアプリまで巻き込むのはMonaとしては意図しない動作です。アプリのメモリ空間を完全に分離しているので、もし巻き込まれるとすればそれはカーネルのバグということになってしまいます。
- メモリ不足の件
- kukuriを順に2つ起動したとします。(以下それをk1, k2と呼びます。)。理論上はk1, k2が使用する物理メモリ量は大して違わないはずです。k2の方が後から起動しているので必要なメモリを確保できない可能性はあります。ただしユーザーアプリの使用しているnew/mallocは実際の物理メモリの空きは関知せず、メモリを割り当てます。ではどこでメモリ不足が発覚するかというと、k2が割り当てたメモリにアクセスしてページフォルトが発生したときに発覚します。メモリが足りている場合はページフォルト⇒物理ページ割り当て⇒復帰となりますが、不足時はページフォルト⇒物理ページ割り当て不能⇒警告メッセージ表示となります。
つまりk2でnewがNULLを返すならば、k1でもNULLを返す可能性が高いにもかからずそのような現象が見られないので別の原因があるのではないかと思っている次第です。
- この現象は急ぎで対応するのではなくて、頭の片隅に意識しながらいつか解決する類のものかなと思っています。
- 5−6人起動するとランチャーやkukuriが落ちることがあるようです。現象はVPC(ゲストメモリ48MB)で確認しました。 -- ひげぽん 2004-06-11 (金) 00:24:26
- これはメモリ不足のためnewでNULLが返って来るためのようです。kukuriに限らず他のアプリでも発生するようです。MonaGUIは手を抜いてほとんどASSERTしていないので、ぬるぽに弱いですね……。ASSERTしていても結局落ちることには変わりないので、対処のしようがないというのが正直なところです。 -- Tino 2004-06-12 (土) 01:31:48
- 他のアプリまで巻き込むというのは、Windows 9xでリソース不足になるのと同種の現象と言えそうです。 -- Tino 2004-06-12 (土) 02:01:48
- よくやった。感動した。 -- 2004-06-10 (木) 23:35:17
- Tinoさんお疲れ様でした。グルグル!!! -- ひげぽん 2004-06-10 (木) 23:32:57
- グルグルだ！ -- あっきぃ 2004-06-10 (木) 22:38:07
- 適当に移植しやすそうなものを持ってきただけで、元ネタのことは良く分かりません。 -- Tino
- どうも私の対応が悪くてご迷惑をお掛けする結果になってしまったようで申し訳ありません。とりあえず私の方で移植してcommitしておきました。 -- Tino 2004-06-10 (木) 22:06:03
- なるべく元のソースを生かすようにしたため、ソースの整理はほとんどしていません。パラメータが多くてお世辞にも読みやすいコードではないのですが、テクニック的には色々と面白いことをしているので、その点が参考になれば幸いです。 -- Tino 2004-06-10 (木) 22:07:12
- いろいろとありがとうございます。いろいろついでと言ってはなんですが、ぐっとこらえずにそのまま突っ走っていただく事は可能ですか？悪い意味ではなくて、ほぼTinoさんのコードになったので突っ走っていただいた方がよりよいものができると思います。 >Tinoさん-- ひげぽん
- 移植の案件は今後も出てくると思うのですが、必要なのは良いものを作るということよりも、まずは最小限の手間で動くようにすることだということを伝えたかったわけです。ほぼ私のコードになったと言うことですが、もともと作るところは作って、使えるところはそのまま使うという考えだったので、多かれ少なかれ今回のような形式にするのが一番簡単だったはずです。基本的に美しさとかは度外視して、可能な限りオリジナルから外れないようにしただけです。 -- Tino 2004-06-09 (水) 19:17:12
- 今回のものはコード的には小規模なので作り直してリファクタリングという考えになったのかもしれませんが、それは移植ではないです。移植の際に作るところは作るというのは溝を埋めるための作業で、リファクタリングが目的ではないです。中規模以上の移植では、いちいち内部構造までいじっていると動く前にエンバグして移植になりません。 -- Tino 2004-06-09 (水) 19:19:01
- どうもTinoさんの「ひげぽんを成長させよう」という親心？を全て理解せず空回りしてしまったようです。もうしわけありません。 -- ひげぽん 2004-06-09 (水) 21:46:33
- 同じようなアプリを作ろうと設計中だったこともあり作り直しリファクタリングへと傾いて迷走してしまいました。すいません。。。 -- ひげぽん
- 今回の件も元々私がやればそんなに難しくないことだったのですが、ひげぽんさんの勉強になればと思ってお願いしていたことなのです。そんな暇はないから嫌だというのなら私がやりますけど。>ひげぽんさん -- Tino 2004-06-09 (水) 18:56:19
- 今回の件は完全に私の迷走によるものなのでTinoさんは全然悪くないのですがちょっと移植のモチベーションが下がってしまったのでやって頂けるとうれしいです。わがままを言って申し訳ありません。m(__)m -- ひげぽん
- >ひげぽんさん とりあえずベースになるように修正しておきました。というか、私じゃないと分からないような文書化していない部分を書いておいた感じです。後は機械的に移植できると思います。対象となるのはメインクラスだけで、コンテキストメニューはとりあえず見送れば、本当に機械的な作業で済むと思います。（思わず全部やりそうになったのをぐっとこらえました^^;） -- Tino 2004-06-09 (水) 03:34:56
- またも独り言。動きだけ軽くべたっとかいてみた。頭の中はオブジェクト指向設計をなんとなくしていることが多いけど、まずはべたっと書くことで必要な道具をそろえることが出来る＆実装が可能なことが分かる。 -- ひげぽん 2004-06-07 (月) 00:45:51
- 思えばacos必要なかった予感・・・明日直そう・・ -- ひげぽん
- かなり独り言。まったりとxpmの形式がなんとなく分かった。fl_draw相当を自分で実装するのが早いか。全部bmpでMonaGUIに任せるか(読み込み多発で遅いだろうな) -- ひげぽん 2004-06-06 (日) 01:30:51
- ファイル読み込み多発の問題は、複数のイメージを1枚のBMPにまとめて、描画の際にずらすという方法で回避できます。BMPをbzip2圧縮してBM2にすればサイズも小さくなります。ただBM2にするとエミュでは展開に時間がかかるんですよね。それでも実機だとFD読み込みより展開の方が速いというのと、FDの節約になるので、BM2の方がお勧めではありますが。あとXPMのパーサーがFFCPixmapです。 -- Tino 2004-06-06 (日) 01:39:34
- 実は部分描画に対応していないので、1枚のBMPをずらして描画するというのは現段階のMonaGUIの実装では効率が悪いのですが（出来ないわけではないです）、その辺はWABAで言及したflushの件と合わせて近いうちに改善します。 -- Tino 2004-06-06 (日) 01:50:40
- ありがとうございます。パーサーの件は理解しています。結局最後にFFCPixmapがfl_drawに渡されて描画される感じなのでfl_draw相当を実装すべきと理解したいます。
実はxpmにこだわらずMonaGUIと親和性の高い形式を選べばよいことに気づきました。重要なのは描画の部分ではないので。 -- ひげぽん
- はい、私もそういうイメージです。 -- Tino 2004-06-06 (日) 02:03:36
fltk-kukuri.zip
kukuri.png