[過去ﾛｸﾞ] 今夜も Wine で乾杯! - 21本目 [無断転載禁止]©2ch.net (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
328: 2018/01/26(金)11:30 ID:2+tR6Py2(1) AAS
IEって再配布許可されてたっけ？
329(1): 2018/01/27(土)20:54 ID:giAfVQmq(1) AAS
なんかwine-stable入れなおしたらフォントがちゃんとWindowsみたいにアンチエイリアスなしでビットマップフォント描画するようになってて違和感
以前
画像ﾘﾝｸ[png]:i.imgur.com
現在
画像ﾘﾝｸ[png]:i.imgur.com
330: 2018/01/29(月)01:59 ID:7OnATKIe(1) AAS
>>329
へ〜Jane Styleだとこうなるのか
ちょっと試してみるわ
331(3): 2018/02/03(土)15:04 ID:ELGdE4BJ(1/8) AAS
wine3.0にしたらadobe airがインストールできなくなった
air28だけでなく27も26もだめ
しばらく様子をみるしかないか
332: 2018/02/03(土)15:28 ID:Oo2vNWbE(1) AAS
qtもインストール出来なくなったね(´･ω･`)
未実装の関数がどうとか出てくる(´･ω･`)
333: 2018/02/03(土)15:34 ID:ELGdE4BJ(2/8) AAS
qtもなんだ
office2007とかすごく快適に使えてるからとりあえずはいいんだけど
郵便局のハガキデザインキットで暑中見舞い作りたいからそれまでにはなんとかしてほしいわ
334: 2018/02/03(土)18:46 ID:Kel5QXve(1) AAS
3.1出とるで
335: 2018/02/03(土)18:54 ID:ELGdE4BJ(3/8) AAS
Developmentだからなあ
基本Stableを第一に考えてるので3.0が優先かな
まずは他に方法がないかいろいろ探してみようと思う
336: 2018/02/03(土)19:23 ID:ELGdE4BJ(4/8) AAS
>>331
自己解決
adobe airをwinetricksから試しにインストールしてみようと思ったら、ついこの前までadobe air2.0xと表記されてたものが今はadobe airとだけの表記に変わってた
これをインストールすると郵便局のハガキデザインキット2018もちゃんとインストールできた
wine uninstallerで見てみるとadobe airはちゃんと最新版28.0.0.127になってる
何のことはない、adobeのサイトからではなくwinetricksからだったらインストールできたというオチでした
画像ﾘﾝｸ[png]:i.imgur.com
337: 2018/02/03(土)19:23 ID:ELGdE4BJ(5/8) AAS
>>331
自己解決
adobe airをwinetricksから試しにインストールしてみようと思ったら、ついこの前までadobe air2.0xと表記されてたものが今はadobe airとだけの表記に変わってた
これをインストールすると郵便局のハガキデザインキット2018もちゃんとインストールできた
wine uninstallerで見てみるとadobe airはちゃんと最新版28.0.0.127になってる
何のことはない、adobeのサイトからではなくwinetricksからだったらインストールできたというオチでした
画像ﾘﾝｸ[png]:i.imgur.com
338: 2018/02/03(土)19:23 ID:2NmXANz5(1) AAS
>>331
自己解決
adobe airをwinetricksから試しにインストールしてみようと思ったら、ついこの前までadobe air2.0xと表記されてたものが今はadobe airとだけの表記に変わってた
これをインストールすると郵便局のハガキデザインキット2018もちゃんとインストールできた
wine uninstallerで見てみるとadobe airはちゃんと最新版28.0.0.127になってる
何のことはない、adobeのサイトからではなくwinetricksからだったらインストールできたというオチでした
画像ﾘﾝｸ[png]:i.imgur.com
339: 2018/02/03(土)19:24 ID:ELGdE4BJ(6/8) AAS
あかん、３回も書き込まれてしまった
ごめん！
340: 2018/02/03(土)19:35 ID:GZq3v5kX(1) AAS
三回とは珍しい
341: 2018/02/03(土)19:44 ID:ELGdE4BJ(7/8) AAS
お恥ずかしい
書き込みエラーが出たので試しにプロキシの設定の書き込みの方にもチェックを入れてみたところ、いきなり３回書き込みになってしまいました
342: 2018/02/03(土)19:45 ID:ELGdE4BJ(8/8) AAS
あ、ちなみにJDです
343: 2018/02/04(日)04:35 ID:otRrUZsg(1) AAS
女子大生なら仕方ない
344: 2018/02/04(日)05:23 ID:z31m/4Dh(1) AAS
JCなら許したがJDじゃ許さない
345: 2018/02/04(日)05:50 ID:A0TCwoRK(1) AAS
JKがいいな
346: 2018/02/04(日)08:45 ID:b+VNmt3j(1) AAS
俺もJKがいいわ
347(1): 2018/02/04(日)13:01 ID:rnnaq26n(1) AAS
ここまでDKやDC、DSすらなし
348: 2018/02/04(日)13:18 ID:0SOx+W3z(1) AAS
女装男子だろJK
349: 2018/02/04(日)15:28 ID:GzGg78Tp(1) AAS
>>347
男子コリア人や男子中国人、男子シベリア人ですか
350(1): 2018/02/04(日)16:30 ID:uHhYoqNi(1/2) AAS
若いころは、JSがまさかここまで人気になるとは思わなかったな。
Javaに似せただけがとりえのスクリプトだと思ってたのに。
351: 2018/02/04(日)16:36 ID:fzkuBClS(1) AAS
いや全然Javaに似てなくないか
JSってかなり変わった言語だと思うけど
352: 2018/02/04(日)16:42 ID:uHhYoqNi(2/2) AAS
ごめん、名前の話ね。
JSリリース当初は、まさに全然違うのになぜLiveScriptからJavaScriptに変えたんだろう、と思ったんで。
353(1): 2018/02/04(日)16:51 ID:i7LhZGzA(1) AAS
あえて言おう、女子小学生と！
354: 2018/02/04(日)17:03 ID:Oj6myZBS(1) AAS
AA省
355: 2018/02/04(日)17:50 ID:z6WochWF(1) AAS
逮捕！
356: 2018/02/04(日)17:54 ID:/nA3Cux+(1) AAS
>>350
大半が同じ感想のはず。
ajaxの手法が公開されてから一気に沸騰した。
357: 2018/02/04(日)19:07 ID:m27l3Bxn(1) AAS
JK=ジャパニーズ・コリアン ニダ！
358: 2018/02/04(日)20:49 ID:bJ63O2JQ(1) AAS
The Wine development release 3.1 is now available.
What's new in this release (see below for details):
- Kerberos authentication support.
- Window class redirection for Common Controls 6.
- Support for X11 ARGB visuals.
- DOSBox required for running DOS executables.
- Various bug fixes.
359: 2018/02/05(月)02:08 ID:O1Pwqk/s(1) AAS
とりあえず3.0stableで様子見決め込んでる
360: 2018/02/05(月)19:21 ID:Nv69ARvL(1) AAS
wine-staging2.21からwine-stable3.0にしたら
負荷とメモリ消費が素晴らしく改善されたから
開発版に手を出しかねてる
3.0で改善されたのか、stagingのものが足を引っ張ってたのか判別つかなくて
361: 2018/02/05(月)20:00 ID:EoTMajD6(1) AAS
chrootで試せばいい。
362: 2018/02/07(水)03:18 ID:EaQ8LavF(1) AAS
janeで書き込みてすと
363: 2018/02/07(水)11:19 ID:wf+3Oqyn(1) AAS
3.4のときは起動すらしなかったのにな
4.0になったら快調すぎる
364: 2018/02/07(水)12:09 ID:obK+oDJv(1) AAS
だったらいいんjane
365: 2018/02/07(水)13:18 ID:zs43/D2L(1) AAS
じゃあコンパイルすっかな
366: 2018/02/08(木)05:29 ID:awGx+2l1(1) AAS
結局のところwinehq-stableとwine-stableの差は何なのさ
367: 2018/02/09(金)02:10 ID:7CcbsDfN(1) AAS
winehq stableが公式サイトで公開されてるやつでwine stableは各ディストリから配布されてるやつだと思ってたけど違うのかな
368(1): 2018/02/09(金)09:15 ID:VkWK7O5C(1/2) AAS
wine-3.1-arm.apk
ExaGearより動くかなと期待して入れたんだけど、プログラムが一つも動かない…
まだ見てくれだけの未完成品ってこと？
369: [ｓａｇｅ] 2018/02/09(金)09:31 ID:VkWK7O5C(2/2) AAS
あー Windows RT ARMのソフトしか動かないのかこれ
370(1): 2018/02/09(金)10:40 ID:PPTatEc4(1) AAS
違うだろ
2chｽﾚ:market
371(1): 2018/02/09(金)10:58 ID:FuNSphmo(1) AAS
>>370
マルチポストにつきNG推奨
372: 2018/02/09(金)11:54 ID:uGFZgCuz(1) AAS
>>371
こいつMac関連のスレ狙ってる？別にそんな事ないのかな
373(1): 2018/02/10(土)14:13 ID:JX1fd7td(1/2) AAS
crossoverのベースになっているwineのバージョンってどこから調べたらいいの？
もう3.0ベースになってるのかな
374(1): 2018/02/10(土)21:57 ID:yxHJfpP2(1/2) AAS
>>373
/opt/cxoffice/changelog.txt
もしくは
外部ﾘﾝｸ:www.codeweavers.com
3.0はまだやね
375(1): 2018/02/10(土)22:08 ID:yxHJfpP2(2/2) AAS
ちがったかな
$ /opt/cxoffice/bin/wineserver --version
wine-2.8-8251-g8a457d1
376: 2018/02/10(土)23:24 ID:JX1fd7td(2/2) AAS
>>374-375
ありがとう
そっかまだかあ
377: 2018/02/15(木)16:28 ID:Adu/G50n(1) AAS
ubuntu studio 16.04LTS にwineを入れて、
JaneStyle を使える様にはなった。
書き込みテスト。
378: 2018/02/15(木)22:20 ID:feRq4tDS(1) AAS
>>368
まじかよ、Elonaさえ動けばいいのに。
379: 2018/02/15(木)23:40 ID:XEMKL93X(1) AAS
ARM機とかスマホしか持ってないわ
これから増えるんかね
380: 2018/02/16(金)01:05 ID:+Lqzmf2v(1) AAS
3DSとかもARMじゃないっけ
381: 2018/02/16(金)08:01 ID:TwuYLqrN(1) AAS
PS VitaもARMだしSwitchもARMだな
382: 2018/02/16(金)08:03 ID:8cWV/uet(1) AAS
最近のモバイル端末はだいたいARMだな
383: 2018/02/16(金)08:03 ID:8uACRqcY(1) AAS
ChromebookもARM機ある
384: 2018/02/16(金)11:10 ID:80vLUCQ5(1/2) AAS
WindowsもARM機が再登場する
385(1): 2018/02/16(金)12:08 ID:Q5rpQjEk(1) AAS
RTでコケて痛い目にあったからそれはないと思う。
ARMじゃない別のアーキテクチャで出す可能性はあるかも・・・
そしてまたコケるw
386: 2018/02/16(金)12:24 ID:Pj9ij8xw(1) AAS
>>385
いや出るから
HPとASUSがsnapdragon搭載Windows端末を発表済で春に発売予定
387: 2018/02/16(金)13:41 ID:QNuqSD5T(1) AAS
売れるとは限らないんだがなぁ
x86exeが何となくでも動くだけでいいのにな
388: 2018/02/16(金)15:27 ID:80vLUCQ5(2/2) AAS
x86が動くWin10のARMが出る
389: 2018/02/16(金)16:20 ID:1h3N4gI+(1) AAS
ちょっと調べてから否定しようよ
まあいいんだけどさ
390: 2018/02/16(金)19:29 ID:XuFK7/QF(1/4) AAS
古いけど、Ubuntu12.01 への Wine3.0のインストールに成功した。
git のソースから、./configure
途中、Font関連のファイルが見つからないエラーが出たので、
そのFontの「dev版」をapt-getでインストール。
その他、いくつかエラーが出るので、インストールしたりする。
その後、make, make install。
でインストールには成功するが、今まで動いていたWinアプリを起動してみると
日本語で文字化けしてる。wintricks font や regedit などをいじってみたが、
ダメだった。しかし、apt-get remove wineとしたあと、再度、
apt-get install wineとすると、なぜか、すぐに成功した。
wine --versionとすると、なぜか、3.1のままだった。
不思議な事に、文字化けはすっきり解決した状態で、Ver 3.1のWineが動いているらしい。
実際、Windowsとの互換性は明らかに向上した。
391: 2018/02/16(金)19:30 ID:XuFK7/QF(2/4) AAS
3.1じゃなく、3.0でした。スマソ
392: 2018/02/16(金)19:37 ID:XuFK7/QF(3/4) AAS
Wzエディタで、検索やGrepのダイアログのStatic Textの表示が途切れてしまう
不具合があったのが、Wine3.0では修正されている。これは使える。
393: 2018/02/16(金)23:10 ID:XuFK7/QF(4/4) AAS
透明色と MDI Window を組み合わせた自作WindowsアプリをWineで動くように修正中。
MDI Child Widnow のタイトルバーをドラッグすると遅くなるので原因を調査していた。
PreTranslateMessage() にくるメッセージを、自前でWindowに表示していたところ、
システム全体が実質的にハングアップした。マウスは動くが、タスクバーも反応しない。
ちなみに、透明色とMDI Windowの組み合わせが必ず遅くなるわけではない事は、
単純なテストプログラムを作って分かっている。ではなぜ、このプログラムに限っては
遅くなるのかが分からないので調査中だった。
394: 2018/02/17(土)14:20 ID:SLFwTllY(1) AAS
The Wine development release 3.2 is now available.
What's new in this release (see below for details):
- Separate implementation of USER controls for ComCtl32 v6.
- Multisample texture support in Direct3D.
- Support for HID gamepads.
- More event support in MSHTML.
- Obsolete DOS code removed.
- Various bug fixes.
395: 2018/02/17(土)16:25 ID:XDWn7PKv(1) AAS
廃れたDOSコードを削除、か
396(60): 2018/02/17(土)16:26 ID:KjUUJ1nJ(1/9) AAS
Wineは、Desktopの直接の子であるような、Win32における「OVERLAPED WINDOW」
的な物しか、XWindow の Window を作らないのだろうか？？
Wineのソースをダウンロードして、FIXME(WARNでもいいはずだけど)で実行を調べてみた。
でも、良く分からない。ビルドとmake installに時間がかかるため、大変。
本当はもっと実験したいんだけど、時間的に難しくなる。
ソースを見ると、HWNDの親が Desktopの場合にだけ、XCreateWindowしているように
見える。これが、透明ウィンドウが遅くなる理由かもしれない。LinuxのNativeなWindowの
場合、実験した限り透明にしても速度が余り変わらない。でも、Wineがもし、自前で透明処理
をやっているとなれば遅くなるのも頷けるが。
1つのソースしか修正してないのに、ビルドが始まるまでに数十秒かかる。make installに
また数十秒。それに、wineserver -k などにも時間がかかるし。なんか、30年前のビルド環境
みたいだ。
397(1): 2018/02/17(土)16:41 ID:eqmjcJnH(1/2) AAS
>>396
>ソースを見ると
どこだかわからんから外部ﾘﾝｸ:source.winehq.orgのリンク貼ってくれ
398: 2018/02/17(土)17:12 ID:KjUUJ1nJ(2/9) AAS
>>397
今回に関しては、以下を読んで、git でやってます :
外部ﾘﾝｸ:wiki.winehq.org
home directory (~) にて、
$ git clone git://source.winehq.org/git/wine.git [ret]
とすると、wine ディレクトリが作成されるので、
$ cd wine
とします。そこで、
$ git config remote.origin.url [ret]
と入れて
git://source.winehq.org/git/wine.gi
と出れば、大体 DL 成功です。
~/wine/ にソースが DL されており、dlls に Win32 の DLL 群の実装があります。
例えば、user32 などのフォルダがあります。~/wine/server に wine の中枢の
プログラムが入っています。CreateWindow などは、dlls の方にありますが、
それを XWindowCreate に橋渡しするのは、server の方です。
オンラインで見たいなら、
外部ﾘﾝｸ:source.winehq.org
の win.c に CreateWindow 系のソースが入っており、
外部ﾘﾝｸ[c]:source.winehq.org
で見られます。win.c の右の「raw」のボタンを押すと、ローカルの Wz エディタ
などでも見られます。
399: 2018/02/17(土)17:16 ID:KjUUJ1nJ(3/9) AAS
5ch からのアクセスは禁止されているらしいので、アドレスバーに上記の URL を
コピーしてアクセスしてください。
なお、make が遅い件は、make -j 4 などとして、マルチコア動作するとだいぶ良くなりました。
ただし、その場合、make にバグがあるので精密な神経の持ち主には、ストレスがたまります。
400: 2018/02/17(土)17:19 ID:KjUUJ1nJ(4/9) AAS
動きをトレースしたい場合、TRACE はデフォルトではメッセージが出ず、使い方を調べて
ないので、
FIXME( "Yamada Taro, CreateWindowEx, hWND=%08X", hWND );
みたいにやってます。
401: 2018/02/17(土)17:23 ID:KjUUJ1nJ(5/9) AAS
makeしたい人は、~/wine にて、
$ ./confiugre
$ make -j 4 2>build.log
$ make -j 4 install 2>inst.log
$ wineserver -k
で行けます。ここで、wz エディタを起動してみます。文字化けするようでしたら、
$ apt-get remove wine
$ apt-get install wine
で直ると思います。これは、一度やれば Ok のようです。
402(1): 2018/02/17(土)17:40 ID:KjUUJ1nJ(6/9) AAS
AA省
403: 2018/02/17(土)17:41 ID:KjUUJ1nJ(7/9) AAS
AA省
404: 2018/02/17(土)17:42 ID:KjUUJ1nJ(8/9) AAS
AA省
405: 2018/02/17(土)18:08 ID:KjUUJ1nJ(9/9) AAS
ちなみに、
1. ~/.wine
2. ~/wine
は別物です。1は、binary をインストールした際に出来るデフォルトのフォルダ
ですよね。2. は、git からソースを持ってきた時にできるディレクトリです。
まずは、バイナリをインストールして動作してから、ソースを持ってきてください。
406(4): 2018/02/17(土)18:27 ID:1JDlaACg(1) AAS
半透明化はWin32API側でどうやっているの? Linuxネイティブなアプリでは?
SetLayeredWindowAttributesであれば、user32.dllからUSER_Driverを介してwinex11.drvが呼ばれて、
window.c内のsync_window_opacityで_NET_WM_WINDOW_OPACITYにα値を設定している様子が見て取れる
外部ﾘﾝｸ[c]:github.com
TRACEで表示しているメッセージを確認するには環境変数WINEDEBUGを使って、
WINEDEBUG=win,x11 みたいにカンマ区切りで指定する。細かくは
外部ﾘﾝｸ:wiki.winehq.org に書いてある。
あとは、dlls配下の各ディレクトリでもmake && sudo make instlallできるので
特定のDLLファイルしか変更しないのであれば、この方法でビルド時間を短縮できるぞ。
407: 2018/02/17(土)18:42 ID:cvAP0C15(1/2) AAS
デバッグ大変だな。めんどくさそう。
仕事じゃないと俺はやらないだろうな。
408: 2018/02/17(土)19:41 ID:J9G7l4mf(1) AAS
自分はimm32関連(日本語入力)APIを修正しようとeclipceでコンパイル環境作ったはいいけど
ネイティブのウィンドウマネージャ関連の知識不足でソースの意味がわからず寝かせてある・・・
409(1): 2018/02/17(土)19:54 ID:Tf7u8zkg(1/4) AAS
>>406
Linux Nativeアプリの場合、32BIT COLOR にすると、A,R,G,B の 4つの値を
ドットの「色」として指定できます。Aがα値です。このようなことは、Windows
では出来ないと思います。Windowsの場合、CreateWindowExのdwExStyle に
WS_EX_LAYEREDを指定すると透明、半透明が扱えるようになります。
1.完全に「透明になる色」を24BIT値で1色指定できます。この色で描いたドットは、
デスクトップまで透けて見えるようになります。見た目だけではなく、Windowメッ
セージも下のWindowに伝達されてしまうことになりますが。
2.ドットごとではなく、Window全体のα値を1つ(1BYTE)だけ指定できます。
ドットごとでは無いので、全体的に透明度が決まってしまいます。
1と2は完全に別の概念です。
LinuxのARGB値は、ドット毎に指定できるので、Windowsの機能を包含していると
言えます。逆に Windowsでは、同じ事は出来ないはずです。
410(1): 2018/02/17(土)19:57 ID:Tf7u8zkg(2/4) AAS
/wine/dlls/winex11.drv/x11drv.h
に次のような構造体があり、この whole_window というのが大事らしい：
/* x11drv private window data */
struct x11drv_win_data {
Display *display; /* display connection for the thread owning the window */
XVisualInfo vis; /* X visual used by this window */
Colormap colormap; /* colormap if non-default visual */
HWND hwnd; /* hwnd that this private data belongs to */
Window whole_window; /* X window for the complete window */
Window client_window; /* X window for the client area */
RECT window_rect; /* USER window rectangle relative to parent */
RECT whole_rect; /* X window rectangle for the whole window relative to parent */
RECT client_rect; /* client area relative to parent */
XIC xic; /* X input context */
BOOL managed : 1; /* is window managed? */
BOOL mapped : 1; /* is window mapped? (in either normal or iconic state) */
BOOL iconic : 1; /* is window in iconic state? */
BOOL embedded : 1; /* is window an XEMBED client? */
BOOL shaped : 1; /* is window using a custom region shape? */
BOOL layered : 1; /* is window layered and with valid attributes? */
BOOL use_alpha : 1; /* does window use an alpha channel? */
int wm_state; /* current value of the WM_STATE property */
DWORD net_wm_state; /* bit mask of active x11drv_net_wm_state values */
Window embedder; /* window id of embedder */
unsigned long configure_serial; /* serial number of last configure request */
struct window_surface *surface;
Pixmap icon_pixmap;
Pixmap icon_mask;
unsigned long *icon_bits;
unsigned int icon_size;
};
411: 2018/02/17(土)20:00 ID:Tf7u8zkg(3/4) AAS
>>406
後半の二つ。自分に取っては、かなり貴重な情報です。助かります。
412: 2018/02/17(土)20:11 ID:Tf7u8zkg(4/4) AAS
>>406
XWindow で透明化。これはやってみて実際に出来ました：
外部ﾘﾝｸ:stackoverflow.com
how-to-create-semi-transparent-white-window-in-xlib
子ウィンドウを入れてみても、ちゃんと出来ました。
ただし、子ウィンドウには、Win32のような、タイトルバーは付ききませんでした。
XWindow に詳しい人によれば、XWindow の Window Manager は、
Win32 の MDI のような事は、サポートしていないらしいです。絶対か
どうかは分かりませんが。
実験してみると、子ウィンドウも、親ウィンドウも、ABI で、XMoveWindow
でスムーズに動かせました。
ただし、Wineの場合、子ウィンドウに直線や文字が書かれていて、かつ、背景が透明な場合、
スムーズには動かせません。
413: 2018/02/17(土)21:31 ID:cvAP0C15(2/2) AAS
Win32APIだけじゃなく、X Windowについても知っておかないといけないのか
面倒臭っ・・・
普段使ってるだけでずいぶん楽してたんだな。
414: 2018/02/17(土)22:08 ID:eqmjcJnH(2/2) AAS
面白そうだけど時間ねえな……
>>410を見る限りだとuse_alphaは持ってるけどAlpha値自体はもうX11の構造体にいれてるのかな？
まあ遅くなる理由とか検討つかんけど……
415(3): 396 2018/02/18(日)01:13 ID:DznsC7ZZ(1) AAS
WINEにおいて、
1. MDIのCMDIChildWndのCViewのCLIENT領域全体(子ウィンドウの
中全体と言ってもよい) に >>409の1.の色を塗って、完全透明
にしている時は、CMDIChildWndのタイトルバー(子ウィンドウの
タイトルバー）をドラッグしても高速に動かせる。
2. 1のCViewの中に、pDC->LineTo()で直線を一本描いた状態にしてから
同じ事をしようとすると、とても遅くなる。
3. 2.は、直線の代わりに pDC->TextOut() で文字を描いても同様に遅く
なる。
4. 推定では、Wineは、Win32のCreateWindow系で、Parent Window が
Desktop 以外の場合、XWindow の Window を使わず、自前で
Parent Window の中に画像を合成して子Windowを模倣している。
5. 4.の様にしている理由は、推定だと Window Manager の種類による
挙動の違いに患わされずに安定して Emulation するためかも知れ
ない。
6. その結果、XWindow の ARGB 値による高速な透明処理を利用できな
くなり、低速になる。
7. しかし、なるべく低速にならないようにするため、少なくとも、
子ウィンドウの中全体が完全透明な場合については、対策が取ら
れており、高速にドラッグできるようになっている。
8. その結果、2, 3 のような条件の時のみ遅くなると推定される。
416(1): 2018/02/18(日)01:24 ID:smHwezpH(1) AAS
推定じゃなくて直接聞いたら？
417: 2018/02/18(日)01:56 ID:HH6qVqdM(1/9) AAS
>>416
どうやって？
418(3): 406 2018/02/18(日)02:29 ID:dARugMLm(1/2) AAS
>>415
すまん、ウィンドウの半透明化処理(LWA_ALPHA)と勘違いしてた。
ウィンドウ領域内の特定色で書いた箇所を透過させる場合(LWA_COLORKEY)ね。
ソースを調べたら、WineではX11のShape Extensionを使ってウィンドウの形状を変更することで、
「見た目だけではなく、Windowメッセージも下のWindowに伝達すること」を実現しているようだ。
具体的にはupdate_surface_region()で1ピクセルごとにピクセル値を比較して、
XShapeCombineRectanglesに指定する矩形領域を作っている。
外部ﾘﾝｸ[c]:github.com
415の2.,3.の条件だと遅くなるとすると、ピクセル値を比較する処理は1.と同じなので、
矩形が大量になったときに、X側で描画性能が低下するのではないかと思うぞ。
StackOverflowの記事はShape Extensionを使っていないので筋違いだ。
419: 2018/02/18(日)04:20 ID:HH6qVqdM(2/9) AAS
>>418
なるほど。
1つ質問です。
はっきりとは書いてなかったのですが、>>415の遅くなる条件であるところの 2,3 の場合
においても、CMainFrame、つまり、アプリケーション全体の Main の Window のタイトルバーを
ドラッグした場合は、遅くなりません。いたって高速にドラッグできます。
>>418 が正しいなら、どうして、X は、この場合だけは速く、CMDIChildWnd の場合だけは
遅く動作するのでしょうか？？？
420(1): 2018/02/18(日)04:57 ID:HH6qVqdM(3/9) AAS
AA省
421: 2018/02/18(日)05:32 ID:HH6qVqdM(4/9) AAS
/wine/dlls/user32/painting.c の中の、
// Set the visible region and X11 drawable for the DC associated to a given window.
static void update_visible_region( struct dce *dce )
の中に、
USER_Driver->pGetDC( dce->hdc, dce->hwnd, top_win, &win_rect, &top_rect, flags );
とあって、
void CDECL X11DRV_GetDC( HDC hdc, HWND hwnd, HWND top, const RECT *win_rect,
const RECT *top_rect, DWORD flags )
が呼び出される。引数に hwnd と top、win_rect と top_rect が対になっているらしいことに注意。
この関数の中で、x11drv_escape_set_drawable escape; の
escape.dc_rect に、win_rect の top_rect の (left, top) からの相対座標が入れられる。
そして、ExtEscape( hdc, X11DRV_ESCAPE, sizeof(escape), (LPSTR)&escape, 0, NULL );
と ExtEscape() が呼び出される。
escape = X11DRV_ESCAPE;
escape.code = X11DRV_SET_DRAWABLE;
in_data = &escape;
の状態で、
X11DRV_PDEVICE *physDev = get_x11drv_dev( dev );
const struct x11drv_escape_set_drawable *data = in_data;
physDev->dc_rect = data->dc_rect;
となる。physDev->dc_rect が、>>420 の dc_rect に他ならない。
つまり、HWND hwndのwin_rectの、HWND topの左上座標からの相対座標が、
physDev->dc_rect に入ることになると思われる。hwndの「最上位の親」が
topだとすると、topだけが XCreateWindow()された本物のWindowであって、
hwnd は 擬似Windowであるとして辻褄が合う。hwndへの描画は、
実は座標だけを修正して top の(本物の X )Window に書き込まれているだけ
かも知れない。
422(1): 2018/02/18(日)12:58 ID:HH6qVqdM(5/9) AAS
結論的には、Wine では、完全透明色が設定されている全ての LAYERED_WINDOW に
対して、Idle状態の時か、または、50(ms) 毎に、Windowアプリのメッセージループ
の中から自動的に、>>418 の update_surface_region() が呼び出されるようになっ
ているらしいです。この条件のWindowがあって、かつ、update_surface_region() の
処理が重い場合に、動作が遅くなる可能性が高いです。Dirty Bitのようなものは、
今のところ見つかっていませんので、何もしなくても常に重くなるのでしょうか。
【詳細】
flush_window_surfaces() なる関数が、定期的に呼び出される。
典型的なタイミングは、PeekMessage() の中からであり、GetMessage()では、
check_for_driver_events() を介して呼び出される。
flush_window_surfaces() の中に次のようなマクロ呼び出しがある :
LIST_FOR_EACH_ENTRY( surface, &window_surfaces, struct window_surface, entry )
surface->funcs->flush( surface );
ここで、
/* iterate through the list using a list entry */
#define LIST_FOR_EACH_ENTRY(elem, list, type, field) \
for ((elem) = LIST_ENTRY((list)->next, type, field); \
&(elem)->field != (list); \
(elem) = LIST_ENTRY((elem)->field.next, type, field))
であり、上記は、window_surfaces リストに登録されている全ての
window_surface *surface について、window_surface_funcs *funcs の
関数ポインタ flush の関数を呼び出すことになり、結局、
関数 x11drv_surface_flush() が呼び出されることになる。
関数 x11drv_surface_flush() の中に
if (surface->is_argb || surface->color_key != CLR_INVALID) update_surface_region( surface );
とある。update_surface_region() は、>>418 に書かれている関数。
423: 396=422 2018/02/18(日)13:53 ID:HH6qVqdM(6/9) AAS
該当の条件の時、新たには何の描画もしていない静止状態でも、Linuxのシステム・モニターで
CPUパワーが膨大に消費されていることを確認しました。このことは、>>422 を裏付ける物です。
だとすると、Dirty Bit を導入して、update_surface_region()の頻度を下げれば、この低速化
は修正できる可能性が出てきました。LineTo, TextOut, MoveWindow, SetWindowPos,
ShowWindow などを使ったときだけ、DirtyBit を 1にして、1の時だけ update_surface_region()
を呼び出し、呼び出した後には 0 にすれば良いのではないかということです。
条件は：
1. WINEを使用して Windowsアプリを走らせていること。
2. アプリ内で CreateWindowEx() のdwExStyle に WS_EX_LAYERED を指定して Windowを作成
済みであること。
3. さらに、SetLayeredWindowAttribute() に LWA_COLORKEY を指定して「完全透明色」を
指定していること。
4. その Window の背景を「完全透明色」で消去していること。
5. その Window 内部に通常色で、LineTo() や TextOut() によって図形や文字を
描いた後であること。
です。
MDIを使っている事や、CMDIChildWnd 動かすかどうかは関係ない様です。
CMainFrame をドラッグした時には遅く感じないのは、その動作についてはシステムが CPU
の優先順位を上げているからではないかと思います。
424: 396 2018/02/18(日)14:19 ID:HH6qVqdM(7/9) AAS
>>418 さんの指摘は凄く役立ちました。有難うございます。
ただし、こっちの調査不足のせいが大きいのでしょうが、以下の部分は、今回の
結果とは違っていたようです：
>415の2.,3.の条件だと遅くなるとすると、ピクセル値を比較する処理は1.と同じなので、
>矩形が大量になったときに、X側で描画性能が低下するのではないかと思うぞ。
「X側の描画性能の低下」が原因ではなく、「ピクセル値を比較する処理」自体が、
実は「静止状態」でも、常時、大幅に増加していた、ということです。
何の変化がないときにでも、百万ピクセルを比較し、ランレングスを導き出す処理を、
原則的には秒間20回もやっています。
また、図形が複雑だと、システムコールを呼び出す回数がランレングスの変化の回数倍
されます。例えば、直線をN本引いた場合、システムコールの回数が原則 3N (倍)になります。
縦方向が500ドットのWindowで、1本の直線を引いた場合、一回の処理で、最低でも
6,000回のシステムコールが呼び出されます。これが秒間20回も行われますので、
最低で、秒間12万回のシステムコールとなります。1回のシステムコールは、5(μs)
くらいはどうしてもかかるので、これだけで、0.6(秒)もかかってしまいます。
つまり、1秒間に0.6秒も無駄なシステムコールに時間を取られていると見積もれます。
直線を2本にすると、これだけでCPUがフルパワー状態になります。
425(2): 396 2018/02/18(日)14:38 ID:HH6qVqdM(8/9) AAS
【厳密化】
1. 多分、6,000回ではなく、4,500回程度でした。
2. 比較処理自体は、図形の複雑さとは無関係にほぼ一定の重さです。
3. 図形が複雑な場合、システムコールの回数が増えます。
4. 横方向の1つのランレングスで、3つのシステムコールが呼ばれます。
5. 図形が何も描かれていない場合、1つのy座標に対して、1つのランレングスです。
6. N 本の直線の場合、大体で言えば、3N 個のランレングスになります。
7. だから、1つのy座標に対し、9N 個のシステムコールが呼ばれることになります。
8. 縦 500 ドットの場合、500*9N = 4500 N 回のシステムコールとなります。
9. よって、中に描かれている直線の本数が増えると、大体 O(N) で処理時間が
増えます。
10. 文字を描いた場合、大体、文字の複雑さに比例して処理時間が増えます。
426: 396 2018/02/18(日)15:25 ID:HH6qVqdM(9/9) AAS
>>425
【訂正】
「6.」のランレングスの個数は、3N個ではなく、2N+1 個でした。
お騒がせしました。
427(2): 2018/02/18(日)16:08 ID:dARugMLm(2/2) AAS
>>425
update_surface_regionの方が効率悪そうなので、X側の描画性能が原因と推測した部分は撤回する。
Shape Extensionの仕様を見ると、
矩形領域ではなくマスク用のPixmapを指定する方法も採れるから、
BitBltで効率よくマスクを作ればそっちの方が早くなるかもと思ってみたり。
あと、MDIウィンドウがXのWindowではないことは、xwininfoコマンドの結果でも確認できる。
428(1): 396 2018/02/18(日)17:01 ID:hqeoLLBF(1) AAS
>>427
>矩形領域ではなくマスク用のPixmapを指定する方法も採れるから、
>BitBltで効率よくマスクを作ればそっちの方が早くなるかもと思ってみたり。
少なくともその方法だと、図形の複雑さによらずに安定して同じ処理時間で
済みますね。それと当然、BitBlt はハードウェアの補助が得られます。
あと、システムコールも全体で数回しか呼ばなて済みますし。
429: 396 2018/02/19(月)12:40 ID:v4nZjJQ1(1/2) AAS
特定のアプリの場合にだけは、自作の user32.dll.so を読み込ませる事が出来ない。
WINEDLLPATH, WINEPATH を試してみたが、今のところ上手く行かない。
430: 396 2018/02/19(月)15:28 ID:v4nZjJQ1(2/2) AAS
調べてみると、/wine/libs/wine/loader.c の中の build_dll_path()
関数の中で、環境変数 WINEDLLPATH が、読み取られ、: を 0x00に
変えてから、dll_paths[] 配列に : で区切られたそれぞれの文字列
の先頭アドレスを代入している。
しかし、その処理に入る前に、get_dlldir() 関数が NULL 以外を返した場合、
dll_paths[0] にその関数が返した文字列のアドレスを入れてしまう。
そして、実際の get_dlldir() は、"/usr/local/bin/../lib/wine"
という文字列を返してくるので、そっちのパスの方が、WINEDLLPATH
の優先順位よりも上になってしまう。そして、
/* retrieve the default dll dir */
const char *get_dlldir( const char **default_dlldir )
{
*default_dlldir = DLLDIR;
return dlldir;
}
となっているが、DLLDIR が全ての拡張子の全ファイルを全文検索しても
どこにも定義されておらず、参照されているのも唯一この関数だけだった。
これだと、WINEDLLPATH で「Override」できないのも当然だけど、
そもそも、DLLDIR がどこで定義されているのかが分からないので
誰かの教えをいただきたいです。
431: 2018/02/19(月)15:47 ID:qkc2SRTD(1) AAS
見つかりました。wine/libs/wine/Makefileの中で、
config_EXTRADEFS = \
-DBINDIR='"${bindir}"' \
-DDLLDIR='"${dlldir}"' \
-DLIB_TO_BINDIR=\"`$(MAKEDEP) -R ${libdir} ${bindir}`\" \
-DLIB_TO_DLLDIR=\"`$(MAKEDEP) -R ${libdir} ${dlldir}`\" \
-DBIN_TO_DLLDIR=\"`$(MAKEDEP) -R ${bindir} ${dlldir}`\" \
-DBIN_TO_DATADIR=\"`$(MAKEDEP) -R ${bindir} ${datadir}/wine`\"
というのが。単語検索していたのが鬼門でした。
432: 396 2018/02/19(月)19:22 ID:WuPPo4Ry(1) AAS
loader.c の build_dll_path() の修正と、user32.dll.so の修正を、
自分のアプリだけに適用する事に成功しました。
433(1): 396 2018/02/20(火)03:10 ID:nCkYsCc8(1/4) AAS
surface が NULL ではない場合、xxx->pLineTo() は、X11DRV_LineTo()
ではなく、dibdrv_LineTo() が呼び出されるような・・・。
434: 396 2018/02/20(火)05:59 ID:nCkYsCc8(2/4) AAS
DirtyBit を使って、例の update_surface_region() は、
描画してないときには全く呼ばれないようにできたんですが、
まだかなり遅いです。何もしてないときにも CPU パワーがかなり消費されています。
その間、update_surface_region() が呼び出されていないことは、FIXME で
表示して確認が取れています。
なお、>>433は、windrv_LineTo() の方の間違いでした。windrv_LineTo() の場合、
簡単に surface にアクセスできるので、surface に bNeedToUpdate のような
フラグを追加して、それを 1 にして dirty bit にしています。
なぜ遅いままなのかは謎です。
435: 2018/02/20(火)06:05 ID:AmaI1OSV(1) AAS
2ch(5ch?)は人は多いけど基本的にユーザーレベルの人ばかりだから技術的な書き込みしても反応は鈍いね
Qiitaにでも書いてみたらどう？
436(1): 2018/02/20(火)18:28 ID:QMmYbOOf(1) AAS
本家にパッチ投稿もお願いしますw
437: 396 2018/02/20(火)18:49 ID:nCkYsCc8(3/4) AAS
遅い原因の1つは、Onldle の中にあることが分かりました。
1. 必要があって、外部ツールによるファイルの更新チェックをしていたところ、
それがとんでもなく重い事が判明。
2. SetTimer で CMainFrame にタイマーをしかけていると、CMainFrame::OnCmdMsg()
が、WM_TIMER メッセージが来る度に、それを何倍にも掛け算した回数だけ呼び
出される事が判明。例えば、秒間 N 回のタイマーを仕掛けると、OnCmdMsg が、
10*N 回 呼び出されるような感じです。タイマーメッセージがくる度に、
メニューなどを更新するためのメッセージが来ているような気がします。
多分、本家 Windows では、タイマーメッセージが来ても、そのような事には
ならないんじゃないかと思います。 通常、OnCmdMsg は頻度が低いことが
前提になっているので、その中で多少重い処理をしていると、とんでもなく
重たくなる。
なお、透明色を使っている場合、update_surface_region の中の処理の軽重に
よって、描画速度が大幅に変わることも確認しました。
ランレングスを数えてリージョンを add_row している箇所を、単純に何も
数えずに行全体で、1個だけ add_row するように修正してみると、描画が
だいぶ速くなりました（透明にはなりませんが。）。
438(1): 2018/02/20(火)18:56 ID:nCkYsCc8(4/4) AAS
>>436
そうしたいんですが、何かと大変なんです。
1. メールアドレスの登録するのが、Linuxからだと大変。
2. git の仕様が良く分からない。
3. 回線が遅いので、Project を Fork して、git が Tree 全体を
アップロードしようとしてしまったりなんかすると大変な事になる。
4. だから、一部のファイルだけを UL したいが、コミュニケーションの
問題から事情を伝えて、そこまで行くかどうか分からない。
5. だから、独自にオーバーライドしようとしたのが、先日からここでも
書いていたことです。loader を修正して、かつ、環境変数を変えて
やれば、本家と統合しなくても、部分書き変えのような事が出来る。
439(1): 2018/02/20(火)18:59 ID:TT83z4l8(1) AAS
>>438
githubからでもプルリクエスト受け付けてるよ
440: 2018/02/20(火)19:09 ID:LN/W3cN7(1) AAS
先に外部ﾘﾝｸ:bugs.winehq.orgに書いた方がいい
報告してあるとパッチ送る時説明が楽になるから
441: 2018/02/20(火)19:12 ID:hMkWg0ue(1) AAS
描画が早くなるならありがたい
素のWindowsより異様に遅いゲームとかあるし
442: 396 2018/02/20(火)20:06 ID:ErFPSqeX(1) AAS
結論だけ書いておくと、surfaceが非NULLの時の LineTo の実体は、
windrv_LineToで、surface を lock する以外は、dibdrv_LineTo と同じ。
dibdrv_LineToは、bits なるpixel配列に 32BITの色値を書き込む。
実際は汎用性のため、必ずandしてからxorする。SOLIDモードの場合、and値は0。
xor値は、00RRGGBB で、最上位バイトは0。
実際への画面の反映は、定期的に「xxx->flush」なる関数ポインタを介して、
x11drv_surface_flush() を呼び出す事で行う。その中で、議題になっている
update_surface_region() も呼ばれる。最後に bits の内容を実画面に反映させる
ため、XShmPutImage()または、XPutImage(), XFlush()を行う。
surface->image の pixel バッファは、bits[] 配列と共通らしい。
つまり、Linux の描画関数は全く使わずに自前で画像をpixel配列に合成してから、
定期的に、XPutImage() などで実が面に描き込む、というようなことをやっているらしい。
443(1): 396 2018/02/21(水)16:48 ID:SJPTXnf1(1/13) AAS
update_surface_region() が遅いんだと思って、
XShape の作成を、XShapeCombineRectangles() を使う方式から、
XCreateBitmapFromData() と XShapeCombineMask()
を使う方式へと変えた。
すると、1146 x 745 のサイズの Window で、
1. 自前のコードによる 1bit の mask bitmap 作成にかかる時間 :
796 (us)
2. XCreateBitmapFromData() と XShapeCombineMask() にかかる時間 :
38 (us)
3. XShmPutImage() と XFlush() ; x11drv_surface_flush()内 の両方にかかる時間 :
94 (us)
4. MDI Child Wnd をドラッグするときに、x11drv_surface_flush() が
呼び出される時間間隔 :
3〜100 (ms) ---> 秒間 10回〜330回
5. 肉眼で描画が更新されるまでに x11drv_surface_flush() が呼び出される回数 :
数10回 以上あることが多い。
1.〜4. だけみると、高速に処理されている様に見えるけど、5. だけが理解できない。
カウンタを設けて数えてみると、実際に目では更新が起きてないのに、
ちゃんと、1〜3 の全ての関数が数十回も呼び出されている。
ちゃんと「XFlush()」されているのに、なぜだろう？？？？
444: 2018/02/21(水)17:03 ID:SJPTXnf1(2/13) AAS
XSync() を追加しても、XShmPutImage() を XPutImage() に修正しても、
何をやっても見た目だけが更新されない。
445(1): 2018/02/21(水)17:09 ID:iuEniYB2(1/5) AAS
>>443
> update_surface_region() が遅いんだと思って、
> XShape の作成を、XShapeCombineRectangles() を使う方式から、
> XCreateBitmapFromData() と XShapeCombineMask()
> を使う方式へと変えた。
こうするとなんで速くなるの？
446: 396 2018/02/21(水)17:35 ID:SJPTXnf1(3/13) AAS
>>445
それは、
>>427-428
の部分と深く関係しています。
447(1): 2018/02/21(水)17:39 ID:SJPTXnf1(4/13) AAS
X の同期の問題ではなく、MDI Child Wnd の TITLE BAR をドラッグするとき、
なぜか、数秒経ってから、x11drv_surface_flush() がまとめて何十回も呼び出されている
可能性があるかも・・・。
デバッグ表示をリアルタイムで見ていると、見た目が変化する直前までデバッグ表示が
全く出ず、見た目が変化する直前に、どどっと、数十回分の x11drv_surface_flush()
がまとめて出てくる、という現象が起きている。
448(1): 2018/02/21(水)17:56 ID:iuEniYB2(2/5) AAS
>>447
flushしてないだけではなく？
449(2): 396 2018/02/21(水)17:57 ID:SJPTXnf1(5/13) AAS
AA省
450(1): 396 2018/02/21(水)17:58 ID:SJPTXnf1(6/13) AAS
AA省
451: 396 2018/02/21(水)18:24 ID:SJPTXnf1(7/13) AAS
>>448
PeekMessage()を回しているだけの時で、メッセージがキューに残り続けている場合、
メッセージを 200回 (100回？) PeekMessage するまでは、flush_window_surfaces()
されないコードになっている気がしませんか・・・。
452: 2018/02/21(水)18:32 ID:SJPTXnf1(8/13) AAS
GetMessage() の方もほぼ同じような感じかも。。
とにかく、flush_window_surfaces() がとてつもなく長い間、呼ばれないことが
あるコードになっている様に見えて、実際、実験してもそう思える。
453: 2018/02/21(水)18:38 ID:SJPTXnf1(9/13) AAS
そうか、もともとは、dirty bit 方式じゃないから、flush_window_surfaces() を呼ぶと、
再計算する必要が無いのに必ず再計算されてしまうから、呼び出す頻度を下げるしか
高速化する方法が無いために、そんな風なコードになっているのかもしれない。
454: 2018/02/21(水)18:41 ID:SJPTXnf1(10/13) AAS
そして、flush_window_surfaces() のコードでは、最低でも 50 (ms) の時間が経っていない場合には
処理をスキップするコードになっている。とことん、flush() しないコードになってしまっている。
これらが原因か・・・。
void flush_window_surfaces( BOOL idle )
{
static DWORD last_idle;
DWORD now;
struct window_surface *surface;
EnterCriticalSection( &surfaces_section );
now = GetTickCount();
if (idle) last_idle = now;
/* if not idle, we only flush if there's evidence that the app never goes idle */
else if ((int)(now - last_idle) < 50) goto done;
LIST_FOR_EACH_ENTRY( surface, &window_surfaces, struct window_surface, entry )
surface->funcs->flush( surface );
done:
LeaveCriticalSection( &surfaces_section );
}
上下前次1-新書関写板覧索設栞歴
あと 548 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.037s