September 2015 - Wine-Devel

Re: [2/2 v3] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION.

by Jactry Zeng

Hi Ken, 2015-09-30 17:05 GMT+08:00 Ken Thomases <ken(a)codeweavers.com>: > > Since FlashWindowEx() is the more general function — that is, FlashWindow() could be fully implemented in terms of FlashWindowEx(), but not the other way around — shouldn't the driver entry point be FlashWindowEx()? Otherwise, when FlashWindowEx() is eventually implemented more completely, the driver entry will have to be changed. > > For now, since user32 implements FlashWindow() but FlashWindowEx() is a stub (or semi-stub after your next patch), FlashWindow() would have to create a FLASHWINFO structure, fill it in, and pass that along. I think that dwFlags would be either FLASHW_ALL or FLASHW_STOP, depending on bInvert. uCount would be 1, I guess. > Thanks for your review! Yes, function() will be implemented by functionEx() commonly in Wine. But I didn't find a perfect way to implement FlashWindowEx() and then implement FlashWindow() with FlashWindowEx(). Because in X11, how many times will the window be flashed is depend on design of window manager/desktop environment.(For example, in XFCE, taskbar will always flashes when _NET_WM_STATE_DEMANDS_ATTENTION is sent until the user active the window again; In Ubuntu Unity, it'll only be flashed one time and then highlight taskbar until the user active the window again.) And I don't think it's necessary (and any possible?) to follow Window's design. In this way, implementing uCount and other parameters may be useless, because all we need to do is sending _NET_WM_STATE_DEMANDS_ATTENTION to WM/DE one time when FlashWindow()/FlashWindowEx() is called. Similarly, Windows's FlashWindowEx() can decide which part it want to flash - only flash taskbar or only flash caption or flash both. But it'll depend on WM/DE's design in X11. So I implemented FlashWindowEx() by calling FlashWindow() simply. > Shouldn't pFlashWindow (or pFlashWindowEx) be added to the USER_DRIVER structure among the "windowing functions" (see the comments), in alphabetical order (after pDestroyWindow)? Of course, that affects the changes to driver.c in terms of where things are added. The order in winex11.drv.spec is less clear, but it seems to be mostly alphabetical after a certain point. I'd put it after EnumClipboardFormats() in that list. Agree. > > Why does FlashWindow() only call the driver entry point if the window is minimized? Shouldn't the driver get the opportunity to act for a non-minimized window, too? > Same as above, different WM/DE may have different UI effect, that makes it hard to follow Windows's design. In Windows, different UI effects will be showed when window is minimized and non-minimized. And in my opinion, it is a little noisy if USER_Driver->pFlashWindow( hWnd, bInvert ) is called all the time. So I'll prefer to only let the user notice new message when the window is minimized (it may hard to be noticed when it's minimized). > For the X11 implementation, shouldn't something potentially remove the _NET_WM_STATE_DEMANDS_ATTENTION state, presumably when bInvert is false (or when dwFlags doesn't include FLASHW_CAPTION or FLASHW_TRAY)? You are right. It seems flashing will be stopped when bInvert is false. I'll improve it for this case. Thanks again! :) -- Regards, Jactry Zeng

Sept. 30, 2015

Re: Videos or Slides from WineConf

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-28 um 16:06 schrieb Julian Rüger: >> Thanks Stefan, I'm really looking forward to watching. >> >> Joel > > +1 Here they are: Alexandre: https://www.youtube.com/watch?v=GTN5ksxzFnE Jeremy: https://www.youtube.com/watch?v=EzR9RPlWi7c Michael: https://www.youtube.com/watch?v=QdcFNqWTja4 I haven't yet worked on Aric's, André's and Qian's talks. Volunteers to work on those videos are welcome, it's a tedious task and after about one week of work I need a break for a while :-) . Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWC+qsAAoJEN0/YqbEcdMwUCQQAITSp51CVLfl4GeO1ILZdUsN MVq+SSRn7Z4YR9QcxDCe0LFY6z5qnDqFqt6WKpIIvxIMB/yJSOi66IwIT+gy9usA 7G1ONAmZJeWH3LWuJ1KvUP04lvzfxj4FM2L1/7fcxOoLANSpcN2C7tlYxvH+KzrN /d1hi6Ea4mjAEmSGhdD4Yx/aEsfd2bBh2adkoHiKMCVM+HmBD5n9Vbvciht0z2jJ vBdtXiuKt63Ojhu0nuo0YYfg7lfIeEchOlVvYDqR67ixoB7E5yMPoLwdIr22YdH2 f5JJ+0Ku13rVjczr9ZOIPAwYUyKTQLAEAjdbcl+8yR/3iwBLgfnv9eolXLJr+hWk BLVc4erJ/+/Cg1Sg1SNX5v8GmZL/crJDNQfCtybii2TUU11nitbn8Bk8AVuZHsZf xwM2xpBRe2nDFimrt0AUrtCtz2zszKnlWsFmen60h4i6GUGiiZxPwF3Uiu6sm/xv nmjsAcIErXT1bs3jC3gRX0wgOoFVAEX+egMfRywiuOV5JgfjshNhzO+SxrkFlxBO SxCQLbCQ/w41klzNj9NzqW0BZa7SMdQOEh1VIViChTsU6xrJEAhzguIXJn9vSxEi qSuhvwdTdv2yrWcLoqnFnYt8QjudNk7JVzVLkAXvG2S1p4sy5QmJQSJCSNrlnIpi r9devJTqQKH/q6C7NeM3 =Bb6a -----END PGP SIGNATURE-----

Sept. 30, 2015

Re: [2/2 v3] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION.

by Ken Thomases

On Sep 30, 2015, at 2:53 AM, Jactry Zeng <jzeng(a)codeweavers.com> wrote: > dlls/user32/driver.c | 16 ++++++++++++++-- > dlls/user32/user_private.h | 1 + > dlls/user32/win.c | 1 + > dlls/winex11.drv/window.c | 29 +++++++++++++++++++++++++++++ > dlls/winex11.drv/winex11.drv.spec | 1 + > dlls/winex11.drv/x11drv.h | 1 + > dlls/winex11.drv/x11drv_main.c | 1 + > 7 files changed, 48 insertions(+), 2 deletions(-) Since FlashWindowEx() is the more general function — that is, FlashWindow() could be fully implemented in terms of FlashWindowEx(), but not the other way around — shouldn't the driver entry point be FlashWindowEx()? Otherwise, when FlashWindowEx() is eventually implemented more completely, the driver entry will have to be changed. For now, since user32 implements FlashWindow() but FlashWindowEx() is a stub (or semi-stub after your next patch), FlashWindow() would have to create a FLASHWINFO structure, fill it in, and pass that along. I think that dwFlags would be either FLASHW_ALL or FLASHW_STOP, depending on bInvert. uCount would be 1, I guess. Shouldn't pFlashWindow (or pFlashWindowEx) be added to the USER_DRIVER structure among the "windowing functions" (see the comments), in alphabetical order (after pDestroyWindow)? Of course, that affects the changes to driver.c in terms of where things are added. The order in winex11.drv.spec is less clear, but it seems to be mostly alphabetical after a certain point. I'd put it after EnumClipboardFormats() in that list. Why does FlashWindow() only call the driver entry point if the window is minimized? Shouldn't the driver get the opportunity to act for a non-minimized window, too? For the X11 implementation, shouldn't something potentially remove the _NET_WM_STATE_DEMANDS_ATTENTION state, presumably when bInvert is false (or when dwFlags doesn't include FLASHW_CAPTION or FLASHW_TRAY)? -Ken

Sept. 30, 2015

Re: [PATCH 03/12] msvcp110: Add tr2_sys__Open_dir implementation.(resend)

by Piotr Caban

On 09/29/15 18:03, YongHao Hu wrote: > Hi, > > On 15/9/28 下午7:51, Piotr Caban wrote: >> Hi, >> >> On 09/07/15 16:21, YongHao Hu wrote: >>> +/* ?_Open_dir(a)sys@tr2(a)std@@YAPAXAAY0BAE(a)DPBDAAHAAW4file_type@123@@Z */ >>> +/* >>> ?_Open_dir(a)sys@tr2(a)std@@YAPEAXAEAY0BAE(a)DPEBDAEAHAEAW4file_type@123@@Z */ >>> +void* __cdecl tr2_sys__Open_dir(char* target, char const* dest, int* >>> err_code, enum file_type* type) >>> +{ >>> + HANDLE handle; >>> + WIN32_FIND_DATAA data; >>> + char temppath[MAX_PATH]; >>> + TRACE("(%s %s %p %p)\n", debugstr_a(target), debugstr_a(dest), >>> err_code, type); >>> + strcpy(temppath, dest); >>> + strcat(temppath, "\\*.*"); >> Is native limiting the path to MAX_PATH characters? What happens if >> longer path is passed? >> > As far as I know, we can not create a file or directory when their path > longer than MAX_PATH on Windows, so it is impossible to pass a longer > valid path to tr2_sys__Open_dir. > If we pass a longer invalid path, I think that it's err_code would be > ERROR_PATH_NOT_FOUND( GetLastError() ) You can specify a longer path by prepending it with "\\?\" prefix. Even if longer paths are not supported you should probably detect that case instead of possibly crashing in strcpy call. Thanks, Piotr

Sept. 30, 2015

Re: [1/2 resend] user32: Implement semi-stub for FlashWindowEx.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=16898 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 000601B0 message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w864 (64 bit win) === win.c:3417: Test failed: hwnd 000000000003012C message 0118 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

Sept. 30, 2015

Re: Wined3d wireframe rendering

by Aaryaman Vasishta

On Wed, Sep 30, 2015 at 2:47 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > > Am 29.09.2015 um 18:12 schrieb Aaryaman Vasishta < > jem456.vasishta(a)gmail.com>: > > While you have a point, but (theoretically, judging from Bruno's > experience in the game X-moto) texture mapping might be more exacting than > rendering all vertices together without texture mapping in some cases. > Though I'm not sure about it myself. > Note that wireframe rendering doesn't disable texture mapping. It just > assembles the vertices to geometry in a different way. Instead of filling > the entire triangle defined by the vertices it just fills the lines between > the vertices. The lines that are drawn still have the normal fragment > processing (including shaders and textures) applied. > Right, my bad, I forgot to mention that.

Sept. 30, 2015

Re: Wined3d wireframe rendering

by Matt Durgavich

Yeah this really won’t work well if the goal is to speed up games on older hardware. As noted, if you are GPU bound then reducing the resolution should help. -Matt > On Sep 29, 2015, at 11:50 AM, Gediminas Jakutis <gediminas(a)varciai.lt> wrote: > > On 2015.09.29 17:15, Stefan Dösinger wrote: > [...] >> Re performance: Wireframe mode will only fix games that are limited by fragment processing. If you're CPU bound (which is the case in Wine most of the time without CSMT) you'll gain absolutely nothing. Also vertex processing limted setups won't improve, but those are fairly rare. If you're truly fragment processing limited lowering the resolution should help... >> >> Cheers, >> Stefan > > I experimented with making some games run in wireframe under wine around a year ago and can say the results can be quite disappointing in some cases, with performance dropping by an order of magnitude. In some cases, objects that normally get culled due to being occluded by other objects suddenly become visible in wireframe, and thus, get rendered. Since this can lead to processing *a lot* of objects that don't get processed otherwise, it can choke the CPU up badly. > > note: I'm no expert; just writing from experience. > > -- > Gediminas Jakutis > LDK Varčiai www.varciai.lt > >

Sept. 29, 2015

Re: Wined3d wireframe rendering

by Stefan Dösinger

Am 29.09.2015 um 18:12 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > While you have a point, but (theoretically, judging from Bruno's experience in the game X-moto) texture mapping might be more exacting than rendering all vertices together without texture mapping in some cases. Though I'm not sure about it myself. Note that wireframe rendering doesn't disable texture mapping. It just assembles the vertices to geometry in a different way. Instead of filling the entire triangle defined by the vertices it just fills the lines between the vertices. The lines that are drawn still have the normal fragment processing (including shaders and textures) applied.

Sept. 29, 2015

Re: Wined3d wireframe rendering

by Matt Durgavich

Yeah this really won’t work well if the goal is to speed up games on older hardware. As noted, if you are GPU bound then reducing the resolution should help. -Matt > On Sep 29, 2015, at 11:50 AM, Gediminas Jakutis <gediminas(a)varciai.lt> wrote: > > On 2015.09.29 17:15, Stefan Dösinger wrote: > [...] >> Re performance: Wireframe mode will only fix games that are limited by fragment processing. If you're CPU bound (which is the case in Wine most of the time without CSMT) you'll gain absolutely nothing. Also vertex processing limted setups won't improve, but those are fairly rare. If you're truly fragment processing limited lowering the resolution should help... >> >> Cheers, >> Stefan > > I experimented with making some games run in wireframe under wine around a year ago and can say the results can be quite disappointing in some cases, with performance dropping by an order of magnitude. In some cases, objects that normally get culled due to being occluded by other objects suddenly become visible in wireframe, and thus, get rendered. Since this can lead to processing *a lot* of objects that don't get processed otherwise, it can choke the CPU up badly. > > note: I'm no expert; just writing from experience. > > -- > Gediminas Jakutis > LDK Varčiai www.varciai.lt > >

Sept. 29, 2015

Re: Wined3d wireframe rendering

by Aaryaman Vasishta

On Tue, Sep 29, 2015 at 9:20 PM, Gediminas Jakutis <gediminas(a)varciai.lt> wrote: > On 2015.09.29 17:15, Stefan Dösinger wrote: > [...] > > Re performance: Wireframe mode will only fix games that are limited by > fragment processing. If you're CPU bound (which is the case in Wine most of > the time without CSMT) you'll gain absolutely nothing. Also vertex > processing limted setups won't improve, but those are fairly rare. If > you're truly fragment processing limited lowering the resolution should > help... > > > > Cheers, > > Stefan > > I experimented with making some games run in wireframe under wine around a > year ago and can say the results can be quite disappointing in some cases, > with performance dropping by an order of magnitude. In some cases, objects > that normally get culled due to being occluded by other objects suddenly > become visible in wireframe, and thus, get rendered. Since this can lead to > processing *a lot* of objects that don't get processed otherwise, it can > choke the CPU up badly. > > note: I'm no expert; just writing from experience. > > -- > Gediminas Jakutis > LDK Varčiai www.varciai.lt > > While you have a point, but (theoretically, judging from Bruno's experience in the game X-moto) texture mapping might be more exacting than rendering all vertices together without texture mapping in some cases. Though I'm not sure about it myself. Cheers, Aaryaman

Sept. 29, 2015