GUIサーバ高速化/06.AWT調査後の方針


Top / GUIサーバ高速化 / 06.AWT調査後の方針

これは何か

GUIサーバ高速化/05.部分描画実装(libbaygui)/実装/AWTの調査結果を受けてひげぽんが方針を提案します。

提案 by ひげぽん

まずはお礼から。多くの時間を割いて詳細な調査をしていただきありがとうございました。
この調査結果を元に自分なりに考えてみました。

現状問題点

BayGUIが部分描画をサポートしておらず全描画が毎回発生している。
一部のアプリケーションで描画がもたつき実用性がなくなってしまっている。

部分描画サポートがないとは以下2点の事である。

今回の対応へのスタンス

ひげぽんが今回の対応には以下のようなスタンスで臨んでいます。

理想形

調査結果を踏まえて上記問題点を改善する理想形は以下の通りである。

現実的な解

「今回の対応へのスタンス」を考えると、理想形を実現するのではなく現実的な解を見つけなければなりません。
現実解を考える上で以下の事を考慮します。

そして、現実的な解ですが以下のようなものはどうでしょうか?(提案です)

ちなみに上記現実解はGUIサーバ高速化/05.部分描画実装(libbaygui)/変更点でひげぽんが提示したものでほぼ実現できています。
残る課題は Component::update/Frame::update が座標系が異なる点です。
これはひげぽんがBaysideさんと相談しつつ修正すれば良いと思います。

その他の点について

今回のTinoさんの調査でBayGUIと、それがお手本にしているAWTでの挙動の違いを知ることが出来ました。
意図的に挙動が違うものもあれば、そうでないものもあるでしょう。

BayGUIがどこまで AWT と挙動をあわせるか?は、最終的にはリーダーのBaysideさんの判断だと思っています。
なのでTinoさんの調査結果を見て、思う所があれば実装していただければ良いのではないかと思います。

蛇足

BayGUIはJavaでAWT互換を目指した方がいいんじゃないかというコメントがありましたので、個人的な感想を書きます。
誰かに何かをするな/しろといった類のものではないです。念のため。

素人考えですが、AWTが流行っていたのは少なくとも5-6年前で、今は全然普及していないのでないでしょうか。
gcjなどを利用してJava AWTで書いたコードがMona上で動き、C++の面倒臭さから解放されるのは技術的に新しく面白いと思います。
しかし一方で「Mona のGUIはJava AWTなんだぜ」というのは、あまり攻めている印象をうけないです。
個人的にはC#で書ける方が面白そうで攻めていると感じます。(技術的に煩雑になりそうですけど) もっと非現実的なものとして「GUIはHaskellだよ」みたいなのがあって、これはたくさんの人に「おぉ」と思わせる効果があるでしょう。
キワモノを目指しているというのではなくて、Monaは新しい所に常に攻めているんだよという姿勢は今後も維持していきたいよねということです。

コメント

コメントはありません。 コメント/GUIサーバ高速化/06.AWT調査後の方針?

お名前:

MENU

now: 3

リンク


最新の20件
2017-09-29 2017-04-25 2017-01-10 2016-12-11 2016-12-09 2016-10-04 2016-08-14 2016-06-05 2016-05-29 2016-04-15 2015-12-28 2013-02-25 2013-02-21 2013-02-20 2013-02-12 2013-02-11 2013-02-10
最新の20件
2010-02-01 2010-01-31 2010-01-30 2010-01-29 2010-01-16

Counter: 3084, today: 1, yesterday: 0

リロード   新規 編集 凍結 差分 添付 複製 改名   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS

Last-modified: 2008-03-28 (金) 15:47:54 (3676d);  Modified by mona
PukiWiki 1.4.6 Copyright © 2001-2005 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji
Powered by PHP 5.2.17
HTML convert time to 0.064 sec.