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. 0359login:Penguin2018/02/05(月) 02:08:15.28ID:O1Pwqk/s とりあえず3.0stableで様子見決め込んでる 0360login:Penguin2018/02/05(月) 19:21:01.05ID:Nv69ARvL wine-staging2.21からwine-stable3.0にしたら 負荷とメモリ消費が素晴らしく改善されたから 開発版に手を出しかねてる
ちなみに、透明色とMDI Windowの組み合わせが必ず遅くなるわけではない事は、 単純なテストプログラムを作って分かっている。ではなぜ、このプログラムに限っては 遅くなるのかが分からないので調査中だった。 0394login:Penguin2018/02/17(土) 14:20:45.23ID:SLFwTllY 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. 0395login:Penguin2018/02/17(土) 16:25:52.12ID:XDWn7PKv 廃れたDOSコードを削除、か 0396login:Penguin2018/02/17(土) 16:26:50.92ID:KjUUJ1nJ Wineは、Desktopの直接の子であるような、Win32における「OVERLAPED WINDOW」 的な物しか、XWindow の Window を作らないのだろうか？？ Wineのソースをダウンロードして、FIXME(WARNでもいいはずだけど)で実行を調べてみた。 でも、良く分からない。ビルドとmake installに時間がかかるため、大変。 本当はもっと実験したいんだけど、時間的に難しくなる。
LinuxのARGB値は、ドット毎に指定できるので、Windowsの機能を包含していると 言えます。逆に Windowsでは、同じ事は出来ないはずです。 0410login:Penguin2018/02/17(土) 19:57:46.46ID:Tf7u8zkg /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; }; 0411login:Penguin2018/02/17(土) 20:00:42.49ID:Tf7u8zkg>>406 後半の二つ。自分に取っては、かなり貴重な情報です。助かります。 0412login:Penguin2018/02/17(土) 20:11:22.91ID:Tf7u8zkg>>406 XWindow で透明化。これはやってみて実際に出来ました： https://stackoverflow.com/questions/39906128/ how-to-create-semi-transparent-white-window-in-xlib
はっきりとは書いてなかったのですが、>>415の遅くなる条件であるところの 2,3 の場合 においても、CMainFrame、つまり、アプリケーション全体の Main の Window のタイトルバーを ドラッグした場合は、遅くなりません。いたって高速にドラッグできます。
>>418 が正しいなら、どうして、X は、この場合だけは速く、CMDIChildWnd の場合だけは 遅く動作するのでしょうか？？？ 0420login:Penguin2018/02/18(日) 04:57:21.33ID:HH6qVqdM ↓の構造体の dc_rect の矩形が子ウィンドウを模倣するために使われているかも知れません： /* X physical device */ typedef struct { struct gdi_physdev dev; GC gc; /* X Window GC */ Drawable drawable; RECT dc_rect; /* DC rectangle relative to drawable */ RECT *bounds; /* Graphics bounds */ HRGN region; /* Device region (visible region & clip region) */ X_PHYSPEN pen; X_PHYSBRUSH brush; int depth; /* bit depth of the DC */ ColorShifts *color_shifts; /* color shifts of the DC */ int exposures; /* count of graphics exposures operations */ } X11DRV_PDEVICE;
