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

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



やすしです。
ちょっと遅れました。


From: Naitoh Ryuichi <night@bfree.rim.or.jp>
Subject: [b-free: 2069] Re: Xlib interfaceの存在価値 (was: BTK)
Date: Wed, 09 Sep 1998 23:53:12 +0900

> 
> 隆一です。

...snip...
 
> > > うーん、とすると今の B-Free OS には dynamic link library の実装のこ
> > > とは考えていないんですが、その機構が必要ということでしょうか?
> 
> です。

ぜんぶ staticなんですか??
C 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 を直接触ると平気とは書いていないつもり
> ですが。

間違えました。
う〜ん、wrapperが賢くても、不具合出ますかね?この辺はやってみないとわからない?

> > 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 サーバの方に近いものだと思います。

ハンドブックの 第2編 第2章は、BTRONが実際に描画するための関数ではなくて
それよりも、プログラマーから見た視点で、「この関数を使うとこうなる」的な
事が書いてあるように思えますけど、どうですか?
つまり、「Xlibの説明はあるが、X serverの実装(?)については触れられてない。」
様に、思いますけど?

display primitiveとは、基本的な描画に関する関数群と思っていますがどうですか?
つまり、Xlibに含まれているのでは?もちろん、Xlib APIを通して、サーバーに渡されて、
実際に仕事をするのは、サーバーの方だと思いますが。

> > それで、前に、「bdp(Btron display primitive)と、Xlibとの共存は可能ですか?」
> > と聞いたのでは?で、僕は、共存と言うより、bdpはconverterとして、
> > データをXlibに渡すだけにすれば良いかなと思ったのですが?
> > で、そのconverterが独自に管理する情報があったらどうなるのか?となって
> > 僕の訳のわからないX11.soのメールに行くわけですが‥。
> > converterなのですから、独自の情報なんてありません。
> > もしも、bdpの情報を変換できない場合は、Extensionを書きましょう。
> 
> うーん、ディスプレイプリミティブの API には描画環境を作成する関数があ
> ります(これは、メモリ/画面の両方とも使えます)。

gopn_dev, gopn_memのことでしょうか?
これらの関数によってgidが帰るわけですが、gidがXで言うところのDrawableのIDですよね?

gopn_devの場合、devの部分がwindowであったりbitmapであったり。
gopn_memで、dev=NULLならbitmapに書き込むようですから、そのbitmapに線を書くなら、
Xで言うXCreateBitmapFromData()などで、Pixmap pixを作り(これが、BTRONで言うgidに
当たるはず)、XDrawLine(dpy, pix, gc, x1, y1, x2, y2)と線を引けますよね。BTRONには、
dpyの概念がないようなので今の所置いておいて、pixがgid、gcはpat+mode、x1+x2+y1+y2は、
p1+p2から情報を取れます。

一番ややこしいのは、gcでしょう‥。

Xでは、描画環境を製作する関数というのはないですが、描画環境(Xでは、drawable(日本語では何と呼ばれてるかは知りません))を返す関数があり、そこに書き込むことができます。

> ります(これは、メモリ/画面の両方とも使えます)。

と、ありますが、これで答になってます?
メモリと言っても、bitmapですよね?

> アプリケーションが描画環境を作成し、図形を描画したとします。図形の描画
> をするとき、クリッピングもディスプレイプリミティブが行うことになってい
> ます。

う〜ん、display primitiveがやるとはちょっと思えないですね。
diplay primitiveは、基本的な図形や文字を表示するための関数群じゃないですか?
クリッピングなどはもっと下のlevelのような気がしますが?
例えば、handbookの2-12ページの頭から「描画環境には、以下に示す各種データが
保持されている。これらのデータは全て display primitiveの関数を通してアクセス
され、‥‥‥その構造はインプリメントに依存する」とありますね。で、その下に
ならんでいる物の中に、クリッピング領域とあります。
 
> > > > これは、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 は単に描画を行うだけでなく、自分自身で描
> 画環境をもち、クリッピングなども行うものだと思います。直接アプリケーショ

上記の通り、bdp API(まあ、Interfaceと名が付く物では、情報は保存しないような
気がします。)は、もっと下のレベルに情報を渡すだけの役目であって、それ自身は
何もも情報は持たないのではないでしょうか?

> ンが X を操作してしまうと、ディスプレイプリミティブでのクリッピングな
> どはまともにできないでしょう(ディスプレイプリミティブは、メモリ上にも
> 描画環境を作ることができるわけなので、X サーバの単なるラッパというわけ
> にはいかないです)。

と言うことで、単にwrapperと言うわけにいきませんか?

> 考えてみると、X での Toolkit でも似たようなことはありますよね。
> Toolkit 内でボタンなどの情報を管理しているとき、直接アプリケーションが 
> (Toolkit を介さずに) X を直接操作してしまうと、Toolkit で描画している
> ものが、おかしくなってしまうでしょう。

う〜ん、これわからないので、例出してもらえます?
で、以下は、繰り返しなので省略。

...snip...

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

managerじゃなきゃ、だめですかね?
dllが、無いならそれしか方法ない?
全部staticなら、しゃれにならないですよね‥‥‥。

---
  -o)   Yasushi Shoji   | PGP Public Key
  /\\   yashi@yashi.com | http://yashi.com/public_key.txt
 _\_v2.1.119   Powered by Linux and Open Source Software