[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 2069] Re: Xlib interfaceの存在価値 (was: BTK)




隆一です。


From: Yasushi Shoji <yashi@yashi.com>
Subject: [b-free: 2068] Re: Xlib interfaceの存在価値 (was: BTK)
Date: Wed, 09 Sep 1998 06:49:49 -0400
Message-ID: <19980909064949R.yashi@yashi.com>

> やすしです。
> 
> From: Ryuichi Naitoh <naitoh_r@soft.hitachi.co.jp>
> Subject: [b-free: 2067] Re: Xlib interfaceの存在価値 (was: BTK)
> Date: Wed, 09 Sep 1998 13:43:45 +0900 (JST)
> 
> > 
> > 隆一です。
> > 
> > 
> > From: Yasushi Shoji <yashi@yashi.com>
> > Subject: [b-free: 2065] Re: Xlib interfaceの存在価値 (was: BTK)
> > Date: Tue, 08 Sep 1998 23:26:13 -0400
>  
> > > > なになに.so っていうのは、dynamic link library のことでしょうか?
> > > 
> > > そうです。shared objectの略です。
> > > # 略すのはやめた方が良いみたい‥。
> > 
> > うーん、とすると今の B-Free OS にはディスプレイプリミティブの実装のこ
> > とは考えていないんですが、その機構が必要ということでしょうか?
> 
> 何でそうなるのかな?
> so が、shared objectですねって言う話ですよね、ここ?
> display primitiveが、何をさしているのかはいまだにはっきりしない‥。

あ、間違えました。

> > うーん、とすると今の B-Free OS にはディスプレイプリミティブの実装のこ

ではなく、

> > うーん、とすると今の B-Free OS には dynamic link library の実装のこ

です。

# shared object とは、dynamic link library と考えていいですよね?



> > > > > > たとえば、ディスプレイプリミティブが独自の管理情報をもっている場合、問
> > > > > > 題があると思います。これは、アプリケーションから X を使えるようにした
> > > > > > 場合でも問題になりますが。
> > > > > 
> > > > > 自分が思っていた方法なら、display primitiveの情報はもちろん API を通して
> > > > > 受け取ります。たとえ Xlibを直接使ったからと行って display primitive API 
> > > > > に、accessできないわけではないですから。
> > > > 
> > > > いや、だからアプリケーションが Xlib に直接アクセスすると、ディスプレイ
> > > > プリミティブの内部情報と X サーバ側とで不一致が生じるんじゃないですか?
> > > > これは、アプリケーションがディスプレイプリミティブを呼び出せるとしても
> > > > 解決できません。
> > > 
> > > これを吸収するために wrapperが存在するわけですが、
> > > もしこれがむりなら、X + Xlibを使う自体無理ですよね。
> > > X + Xlib for B-Free libなら、どうでしょう?
> > 
> > ラッパというか、アプリケーションが X11 に直接アクセスしないとするなら
> > ば、大丈夫だと思います。アプリケーションが X11 に直接アクセスしてしま
> > うと、いくら利口なラッパでも実際の表示との不一致が生じることは避けられ
> > ないでしょう。
> 
> どうして、applicationが Xlibに直接触るとprimitive と X serverの内部情報に
> 不一致が生じるのですか? で、どうしてX11(たぶんX serverのことですよね?)に
> 直接触ると、平気なのですか?

うん? (アプリケーションが) X11 を直接触ると平気とは書いていないつもり
ですが。



> share するものは、X server resouceとして、serverが持てば良いのですよね?
> それともICEや、ICCCMのようなもののこと?

? ということは、X サーバがディスプレイプリミティブ固有の情報を持つと
いうことですか?  後ろにも書いているとおり、それはできないのではないで
しょうか?(X サーバのもつ情報とディスプレイプリミティブのもつ情報とは
一対一ではないので、ディスプレイプリミティブが固有に情報をもつ必要があ
る)


> > > > > display primitiveがlibraryでも情報を持つことになりますか?
> > > > 
> > > > えーと、ディスプレイプリミティブはライブラリで実装できるんでしょうか?
> > > 
> > > display primitiveとは、何なのでしょう?
> > > 画面上に、点、線、文字などを書くための routineですよね?
> > 
> > ディスプレイプリミティブは、単純に図形描画のルーチンではないと
> > 思いますよ。むしろ X サーバのようなものでしょう。
> 
> そうでしょうか? BTRON Display Primitive APIは、X が持つ display primitive
> に、情報を渡すための窓口に過ぎないのでは?つまり、Xlibと同じですよね?

えーと、BTRON1 プログラミングハンドブックのディスプレイプリミティブの
章の基本概念の項目を読んでいただきたいのですが……。
ディスプレイプリミティブはむしろ、クリッピングの機能をもち、単なる 
Xlib のようなライブラリというより、X サーバの方に近いものだと思います。


> それで、前に、「bdp(Btron display primitive)と、Xlibとの共存は可能ですか?」
> と聞いたのでは?で、僕は、共存と言うより、bdpはconverterとして、
> データをXlibに渡すだけにすれば良いかなと思ったのですが?
> で、そのconverterが独自に管理する情報があったらどうなるのか?となって
> 僕の訳のわからないX11.soのメールに行くわけですが‥。
> converterなのですから、独自の情報なんてありません。
> もしも、bdpの情報を変換できない場合は、Extensionを書きましょう。

うーん、ディスプレイプリミティブの API には描画環境を作成する関数があ
ります(これは、メモリ/画面の両方とも使えます)。
アプリケーションが描画環境を作成し、図形を描画したとします。図形の描画
をするとき、クリッピングもディスプレイプリミティブが行うことになってい
ます。



> > > これは、Xでは XlibでClient側に提供されているものでしょうか?
> > > それとも X server自体が持つ物の方でしょうか?
> > > # ちなみに、X serverには Graphics Contextも必要ですね。
> > > # これは X serverが持つ物です。
> > 
> > えっと、この段落で何を言いたいのかいまいちわかりません。
> > 説明していただけないでしょうか?
> 
> Xでのdisplay primitiveは、X serverが持つ機能だと思っています。
> しかし、描画する場合 その display primitiveを abstruct したた部分と、
> X serverが持つroutine(primitive そのもの)と、X serverが必要とする
> resouceが必要だと思います。GCなどは、そのresouceにあたる部分であり、
> Xlibは Clientが X serverの持つ routineを簡単に使えるように abstruct
> した物なのではないでしょうか?(間違っていたら指摘してくださいm(__)m)
> generalize とも、言えるかな?
> この段落では単に、GCの例を出して、GC は X server の resouce だが、
> primitive は、何のだろうか?と言う疑問を書きたかっただけです。
>
> bdp APIは、converterという事を上に書きました。
> 本来、bdpは描画を行うことまでを含むのかも知れません。が、Xを使うのなら
> X の display primitiveを使ってしまえば良いのではないでしょうか?

上記のとおり、むしろ、bdp API は単に描画を行うだけでなく、自分自身で描
画環境をもち、クリッピングなども行うものだと思います。直接アプリケーショ
ンが X を操作してしまうと、ディスプレイプリミティブでのクリッピングな
どはまともにできないでしょう(ディスプレイプリミティブは、メモリ上にも
描画環境を作ることができるわけなので、X サーバの単なるラッパというわけ
にはいかないです)。

考えてみると、X での Toolkit でも似たようなことはありますよね。
Toolkit 内でボタンなどの情報を管理しているとき、直接アプリケーションが 
(Toolkit を介さずに) X を直接操作してしまうと、Toolkit で描画している
ものが、おかしくなってしまうでしょう。
X の Toolkit の場合だと、単なるアプリケーションの問題なのでまだいいで
す(他のアプリケーションには影響が少ない)。ディスプレイプリミティブだと、
BTRON のウィンドウマネージャの土台となるものですから、下手をすると画面
全体がしっちゃかめっちゃかになってしまいます。


> 「display primitiveを作る」じゃなくて、「display primitive APIを、
> Xlibに変換するwrapperを作る」ですね。画面情報は、X server だけですから
> 統合も何もないと思いますが? bdp APIを介しても、会さなくても元のデータは同じ
> X serverから来るものですから。

ディプレイプリミティブは、自分の内部に描画環境をもつわけですから、
Xlib の単なるラッパではできないでしょう。やるとしたら、アプリケーショ
ンは X に直接アクセスできないようにして、ディスプレイプリミティブだけ
を使うだけにする必要があります。

また、描画環境は、他のアプリケーションがアクセスしているディスプレイプ
リミティブと整合性が取れている必要があります。アプリケーション毎に別々
のメモリ領域をもっているライブラリだと整合性をとるのは難しいでしょう。



> でも、2番もかなり気になります。Xlib BTRON API版を作るってことですよね?
> これだと、BTRON仕様のdisplay primitive APIだけになるから、
> 前に議論にでた、「Xlib APIを残すか?」での、残さないになりますよね。
> と言うか、このスレッドはその続きか‥‥。
> 
> > 2) X サーバはそのままで、X プロトコルをしゃべるディスプレイプリミティ
> >    ブマネージャを作る(ディスプレイプリミティブは Xlib をリンクする)。
> 
> でも、Xlibを linkするってところがわからないけど‥。
> (つまり、X server、Xlibともにdisplay primitiveじゃないと?)

ディスプレイプリミティブの API を提供するマネージャを作り、画面の書き
換えをするために Xlib をリンクするということです(これでも、ディスプレ
イプリミティブを介さずに X サーバにアクセスすると画面が乱れてしまいま
すが)。


> 1番は、個人的には好きじゃないですね。
> Driverの所だけを使って、全く新しいものを作る様なものですよね?

ドライバというか、X サーバのソースからディスプレイプリミティブを作ると
いうことですよね。クリッピングとかの処理を流用することになります。 


---
B-Free プロジェクト実行中! 詳細はこの Web ページへ
(http://www.sccs.chukyo-u.ac.jp/B-Free) 


内藤隆一 (rnaitoh@st.rim.or.jp)