デスクトップでLinuxが普及する訳ないと思った時 14

**login:Penguin** · 2019/10/30(水) 14:22:37.51

グロ貼り戌厨の隔離スレ

前スレ
デスクトップでLinuxが普及する訳ないと思った時 13
http://mao.2ch.net/test/read.cgi/linux/1560640166/

ネタはこちらに
デスクトップでもLinuxが普及してる事にするスレ [無断転載禁止]@2ch.net
http://mao.2ch.net/test/read.cgi/linux/1499169719/

**login:Penguin** · 2019/11/07(木) 19:56:55.28

>>115
Linuxでも、マウスがデスクトップを「触れる」ような本当に穴を開ける
方法も存在していることは存在している。そしてそれはWindowの真ん中
でも穴は開くし、いくつでも穴は開くので解く形の制限は無い。
しかし、そうするためのシステムコールは、横一行ごとに
ランレングスタイプで指定する。穴が空いている場所と空いて無い場所の
変化点までの長さを次々に最後まで指定するようなイメージ。
それを縦のどドット数分だけ繰り返す。

この方法でも速度面以外では、Windowsと余り変わらないことが出来る。

一方、厄介なことに、Windowsでは、ARGB値を使っての「完全なる透明化法」が、
子ウィンドウに対しては使えるが、デスクトップに浮いているような
TopLevelWindow では使えないので、LWA_COLORKEY が必要となる。
そして、LWA_COLORKEY 法を使うと本当に穴が空いてしまう。

それをLinuxで模倣するためには、上記に書いたように、ランレングス的な
方法で情報を与えなくてはならない。

Windowsで、「完全透明」の TopLevelWindow をアニメーションしたいと思ったら、
上記の方法で高速に行える。本当にアニメ長の絵を秒間60枚でも描こうと思えば描ける。
これは当然、LWA_COLORKEYを使うことになる。

一方、Linuxでは、ARGB法を使えば同様に、TopLevelWindowで、全く同様のことを
高速に行える。

ところが、Wineの場合は、上記のWindowsアプリをエミュレート実行するためには、
LWA_COLORKEYを模倣しなくてはならない。そして、それは、実際に穴を開けてしまうので、
Linuxのせっかく高速なARGB法が使えない。そこで、上記のランレングス法を使わざるをえない。

**login:Penguin** · 2019/11/07(木) 19:57:42.47

>>117
ところが、このランレングス法は、アプリを最初に起動した直後に一度だけ行うことを想定している
らしいことと、ランレングス法を使っていることで、透明色のON/OFFが非常に激しく変動すると
ランレングスデータが大きくなってしまうことも有って、ものすごく時間が掛かる。
ものすごくといっても、1/60秒に比べて遅い程度。しかし、やっかいなことに、これが
X-Windowのコマンド・バッファ(?)に「蓄積されてしまう」。

で、Windowsの場合、このように描画が遅い場合は、Invalidate() 系の関数が自動的に処理の
頻度を遅らせてくれたりするようになっているので問題にならないが、Wineは、それが上手く
模倣できていない。調べてみると、もう忘れてしまったが、X-Windowのコマンドバッファが
たまっているか、空いているかを調査する関数が正しい値を返さなかったり、また、
処理のフラッシュが沢山の種類があるが、どれも、本当の意味でフラッシュしてくれなかったり
することで、結果的にエミュレートが出来ないことになっていることが分かった。
思い出してきたが、「Xのコマンドをフラッシュして処理が終わるまで帰ってくるな」
という意味の関数を呼び出しても、実際には、Xの描画が終わって無いのにすぐに帰ってきたりする。

実は、このことと絡んで、WM_TIMERもちゃんとエミュレートできていない。WM_TIMERも、
Windowsでは優先順位の最も低いメッセージの一つで、画面処理が遅いような場合は、
システムが適当に間引いてくれることで、異常な処理の遅さを回避できているのだが、
Wineではそれが模倣できていない。この理由も今述べたようなことが複合的に重なって、
での仕組みを使っても模倣できない事態になっていた。

**login:Penguin** · 2019/11/07(木) 20:08:16.60

>>118
「Xのコマンドが実行完了するまで戻ってくるな」
の意味のシステムコールはあるにはある。これをFとしよう。
Linuxで先から述べている「ランレングス法を使った外形変更」のXコマンド、
をRとしよう。
Fは、Rについては処理が終わって無くても、すぐに帰ってきてしまう。
だから、せっかくFを実行してもRはまだ終わって無い状態になっている。

もし、Fが、Rの処理が終わるまで待ってくれていたなら、問題は余り無い。
単に描画が本家Windowsより遅い程度で済む。

ところが、現実には、処理が終わって無いのに、アプリ本体が次から次へと
アニメーションのために、画面の書き換えAPIを呼び出す。
本家では、先に述べた Invalideteや、WM_TIMERの仕組みが、自動的に
それを抑制してくれているのでもんだ無い。

ところが、Linuxの場合だと、Xコマンドがまだまだ大量に残っている状態で、
アプリ側が次から次へとXコマンドを発行するようなことが繰り返される。

この結果、Linuxのデスクトップシステム全体が全く人間のマウス操作に反応できない
ような状態が何分も続くようなことがおきてしまう。

ハングアップしたのかと思って、念のためアプリをなんとか停止させた後に、
数分待っていると、正常な状態に戻る。

事情を知らない人にはハングアップに見えるので、ある意味では「脆弱性」とも言えるかもしれない。