[過去ﾛｸﾞ] デスクトップでLinuxが普及する訳ないと思った時 14 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
107(1): 2019/11/07(木)03:35 ID:NJgWtqtZ(1) AAS
>>105
Wineの互換性を高めるためには、X-WindowのZ-Orderや矩形以外のWindow、
透明処理などに関して、Windowsに似た動作をするための修正が必要のようだ。
108(5): 2019/11/07(木)09:00 ID:3XWmCdFm(1/6) AAS
>>107
> Wineの互換性を高めるためには、X-WindowのZ-Orderや矩形以外のWindow、透明処理など
xeyes等で使われているX Window SystemのShape extensionって30年以上前からあるんだけど
外部ﾘﾝｸ:en.wikipedia.org
109(2): 2019/11/07(木)10:17 ID:QPicJTJM(1) AAS
>>108
たぶん、"X-Window"は"X window system"とは別物なんでしょ。どうでもいい事だけど。
110: 2019/11/07(木)10:18 ID:pJxnE2XP(1) AAS
>>108
しーっ
111(2): 2019/11/07(木)15:53 ID:AxeF2lCm(1/6) AAS
>>108
あるけど、Windowsの透明や非矩形Windowと相性が悪くて、処理がものすごく遅く
なったり、フラッシュするとシステム描画が全くできなくなって、数分間
ハングアップしたかのように見える現象に悩まされたりすることがある。
なので、どこかで MS Windowsの仕組みに歩み寄りが必要。
112(2): 2019/11/07(木)17:38 ID:AxeF2lCm(2/6) AAS
>>111
非常に複雑なので、手短に説明するのは難しいが、触りだけ理由を書いておく。
Linuxだと、ピクセルごとに自由にARGBの A = アルファ値 を使って
システム中に浮いているWindowに対しても透明色が扱えるのに対し、Windowsだと
システム中に浮いているWindowに対しての透明色は、SetLayeredWindowAttributes()
とLWA_COLORKEYを使わないといけない。Windowsでも一見、アルファ値を指定でき
そうだが、実際にはWindow全体のアルファ値なので、好きな部分だけを完全に透明
にして、他の部分は、元のままのようにすることは出来ず、全体的に薄くするような
ことしかできない。
それで話が複雑なのが、Windowsの場合は、LWA_COLORKEYに指定した色の部分は、
省14
113(1): 2019/11/07(木)17:45 ID:3XWmCdFm(2/6) AAS
>>112
> Linuxだと、ピクセルごとに自由にARGBの A = アルファ値 を使って
いいえ
> 一方、Linuxでは、A=0にしたピクセルは完全に透明になるが、穴が開いている訳ではなく、
> 上記の様なマウスメッセージのデスクトップへの伝達は生じない。
いいえ
技術的にめちゃくちゃ
114: 2019/11/07(木)18:12 ID:AxeF2lCm(3/6) AAS
>>113
徹底的な実験調査に基づくものです。
そういうデタラメな反論はよしてください。
115(1): 2019/11/07(木)18:13 ID:3XWmCdFm(3/6) AAS
今気づいたが
> 一方、Linuxでは、A=0にしたピクセルは完全に透明になるが、穴が開いている訳ではなく、
> 上記の様なマウスメッセージのデスクトップへの伝達は生じない。
>>108でリンクを貼った
外部ﾘﾝｸ:en.wikipedia.org
に
For example, if a window is shaped with a hole in the middle, not only the hole shows what is below
the window, but a click in the hole is considered to be a click in what is below the window.
後ろに伝達するってはっきり書いてあるじゃん
レスするならちゃんと読んでね
116: 2019/11/07(木)18:59 ID:3XWmCdFm(4/6) AAS
あ、>>111-112が何をいっているかわかった気がする
これ、X Rendering Extension(XRender)の話だよね?
外部ﾘﾝｸ:en.wikipedia.org
Keith Packardが20年ぐらい前に作った半透明Windowや透過Windowなど
gtkやQT等の現X環境でメインで使われているのがX Rendering Extension
半透明でなく穴あきのWindowを実現するXの拡張は>>108で言ったように
Keith Packardが30年ぐらい前作ったShape Extensionで、透過ウィンドウや
3Dアクセラレーションがなかった頃からある拡張
117(3): 2019/11/07(木)19:56 ID:AxeF2lCm(4/6) AAS
>>115
Linuxでも、マウスがデスクトップを「触れる」ような本当に穴を開ける
方法も存在していることは存在している。そしてそれはWindowの真ん中
でも穴は開くし、いくつでも穴は開くので解く形の制限は無い。
しかし、そうするためのシステムコールは、横一行ごとに
ランレングスタイプで指定する。穴が空いている場所と空いて無い場所の
変化点までの長さを次々に最後まで指定するようなイメージ。
それを縦のどドット数分だけ繰り返す。
この方法でも速度面以外では、Windowsと余り変わらないことが出来る。
一方、厄介なことに、Windowsでは、ARGB値を使っての「完全なる透明化法」が、
省13
118(2): 2019/11/07(木)19:57 ID:AxeF2lCm(5/6) AAS
>>117
ところが、このランレングス法は、アプリを最初に起動した直後に一度だけ行うことを想定している
らしいことと、ランレングス法を使っていることで、透明色のON/OFFが非常に激しく変動すると
ランレングスデータが大きくなってしまうことも有って、ものすごく時間が掛かる。
ものすごくといっても、1/60秒に比べて遅い程度。しかし、やっかいなことに、これが
X-Windowのコマンド・バッファ(?)に「蓄積されてしまう」。
で、Windowsの場合、このように描画が遅い場合は、Invalidate() 系の関数が自動的に処理の
頻度を遅らせてくれたりするようになっているので問題にならないが、Wineは、それが上手く
模倣できていない。調べてみると、もう忘れてしまったが、X-Windowのコマンドバッファが
たまっているか、空いているかを調査する関数が正しい値を返さなかったり、また、
省9
119(1): 2019/11/07(木)20:08 ID:AxeF2lCm(6/6) AAS
>>118
「Xのコマンドが実行完了するまで戻ってくるな」
の意味のシステムコールはあるにはある。これをFとしよう。
Linuxで先から述べている「ランレングス法を使った外形変更」のXコマンド、
をRとしよう。
Fは、Rについては処理が終わって無くても、すぐに帰ってきてしまう。
だから、せっかくFを実行してもRはまだ終わって無い状態になっている。
もし、Fが、Rの処理が終わるまで待ってくれていたなら、問題は余り無い。
単に描画が本家Windowsより遅い程度で済む。
ところが、現実には、処理が終わって無いのに、アプリ本体が次から次へと
省10
120: 2019/11/07(木)20:24 ID:3XWmCdFm(5/6) AAS
>>117
> しかし、そうするためのシステムコールは、横一行ごとにランレングスタイプで指定する。
Xの拡張APIだからライブラリコール(経由でのプロセス間通信)であってシステムコールではないし、
指定の仕方も横一行ごとにランレングスタイプではない
外部ﾘﾝｸ[html]:www.x.org
それにWineで問題があったとしてもWineのXドライバwinex11.drv.soの実装上の問題であって
XやLinuxの問題ではない
そもそもWineで問題が起きる矩形でないWindowを持つWindowsアプリって何?
121(1): 2019/11/07(木)20:51 ID:3XWmCdFm(6/6) AAS
今wine-4.19のdlls/winex11.drv/以下の#ifdef HAVE_LIBXSHAPEの箇所と
xrender.cを見てみたけど、>>117-119は何の話なんだか全くわからない
一体何を調べて>>117-119を書いたの?
122(1): 2019/11/08(金)08:34 ID:kQY+PCDE(1) AAS
>>121
すまんが、俺は高IQだから、一般プログラマには理解できない可能性がある。
123(1): 2019/11/08(金)16:26 ID:uqna3PBs(1) AAS
>>122
iqとプログラミング能力に関係があるのか？
124: 2019/11/08(金)20:01 ID:eW8AKN/u(1) AAS
>>123
一般的にIQが高い人ほど抽象化能力が高い
プログラミングの世界で抽象化って言えば
オブジェクト指向
抽象化できるとコード量が減って
バグも減る
だから関係が無いこともない
流れ読んでないから適当だけど
125(1): 2019/11/08(金)23:17 ID:9QJJzE7I(1) AAS
> 一般的にIQが高い人ほど抽象化能力が高い
なら、まずそれの証明からだ
その後の話は、それが証明できてからだ
126: 2019/11/09(土)07:53 ID:Mpxnz/Lq(1) AAS
>>125
え
IQテストって
なんか、間違い探しとか
共通項から答えを導きだすとか
そんなのばっかじゃん
上下前次1-新書関写板覧索設栞歴
あと 876 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.023s