October 2013 - Wine-Devel - list.winehq.org

Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.

by Henri Verbeet

On 8 October 2013 13:44, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Are you sure? E.g. if a texture is used with srgb=true and sRGB_decode > is supported, wined3d_texture_bind sets WINED3D_TEXTURE_IS_SRGB. If > the application later calls PreLoad manually, texture2d_preload is > called with SRGB_ANY. Because of the set IS_SRGB flag it chooses to > load the srgb copy. It correctly uses the rgb texture structure and > binds the rgb GL texture, but still passes srgb=true to > surface_load(), which results in SFLAG_INSRGBTEX being passed to > surface_load_location, even though we want to load the RGB copy. > Right. It should be pretty easy to fix that by taking EXT_TEXTURE_SRGB_DECODE into account in texture_srgb_mode() though.

Oct. 8, 2013

Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-10-08 12:06, schrieb Henri Verbeet: > On 8 October 2013 00:27, Stefan Dösinger <stefan(a)codeweavers.com> > wrote: >> diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c >> index 52eac16..eb8ca7e 100644 --- a/dlls/wined3d/surface.c +++ >> b/dlls/wined3d/surface.c @@ -5608,8 +5608,6 @@ HRESULT >> surface_load_location(struct wined3d_surface *surface, DWORD >> location, c } } >> >> - if (location == SFLAG_INSRGBTEX && >> gl_info->supported[EXT_TEXTURE_SRGB_DECODE]) - location = >> SFLAG_INTEXTURE; >> >> if (surface->flags & location) { @@ -5671,12 +5669,6 @@ HRESULT >> surface_load_location(struct wined3d_surface *surface, DWORD >> location, c surface_evict_sysmem(surface); } >> >> - if (surface->flags & (SFLAG_INTEXTURE | SFLAG_INSRGBTEX) - >> && gl_info->supported[EXT_TEXTURE_SRGB_DECODE]) - { - >> surface->flags |= (SFLAG_INTEXTURE | SFLAG_INSRGBTEX); - } - >> return WINED3D_OK; } >> > This change seems good on its own, as far as I can tell all > callers already handle this correctly. Are you sure? E.g. if a texture is used with srgb=true and sRGB_decode is supported, wined3d_texture_bind sets WINED3D_TEXTURE_IS_SRGB. If the application later calls PreLoad manually, texture2d_preload is called with SRGB_ANY. Because of the set IS_SRGB flag it chooses to load the srgb copy. It correctly uses the rgb texture structure and binds the rgb GL texture, but still passes srgb=true to surface_load(), which results in SFLAG_INSRGBTEX being passed to surface_load_location, even though we want to load the RGB copy. I'll see if I can simplify the sRGB_decode handling while still keeping it in the texture. Patches 4 and 5 should apply without this one by the way. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSU/AfAAoJEN0/YqbEcdMwIP8P/iJUb9d3dfTQgdDAYNSx0fFc wp7tJZSZKDNlSLz8oTNx7k2Lmcv7ZSInce+R1oaGxS7QjkhxD7U25CdnvgaXV+Oy IInOFuauZ7m6zO+FfBbHd9ujM1pC1Mi7BtsE59LNypJT9ym6iqe2MLocLUjDCfbL koro3I3rzjkMb3XVUQapMevobYBr0jfl3G3q7zirrVuh1fYnL3a1Ge4ckIGsRneL 98ZjmcQyfT8lo9zxtwXPTOR23j1oLnJDNWhn63he1sX6Vg7XQvPZwszXwbN30Jof CjbrTzBmaKq/yY4jXnffu84tDygvWFr0a9sklX7qtaGd4cNBaiSscR6gBAgvZQdI 1533llMChhOqIUBrS5i8d3t24DLdAzd6PiD4LBCjJXzqfTiqWp3JjChR9FUvq+P1 G5gEldxF+MHPXKhZgpq1MoAy13NDYAFNT/EZSgIH/yRGcm9qVTnI98A6gFZnvel4 DQ3p05mMN4dSvGsQJt/l42k8I5IT1nYqetE1ybZd/45LgHKyjYc80z8lt6f0fhrS j9KtY3Pu6Ks8hIjsIrnVPX7SSbiaNzytEwTpECXsmnB6T2Co+d5YOYzKmWLIqOqL ZSTBkStiBzfxi+2KWlnfUHzWmOthaPo98ZRsiwtaux9W+8xvIDMnWD5x51EPlcjt ca93bMIW9i8aPNOOMeKb =dp6t -----END PGP SIGNATURE-----

Oct. 8, 2013

Re: [1/3] xmllite: Use buffer offset instead of pointers

by Nikolay Sivov

On 10/8/2013 10:56, Alexandre Julliard wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> writes: > >> On 10/6/2013 19:06, Nikolay Sivov wrote: >>> It's normal to grow destination buffer, in this case all stored >>> pointers will be trashed. This patch uses offsets from start of a >>> buffer instead. >>> >> Hi, Alexandre. >> >> Patches list shows a build failure for this one, and I don't see any >> failures on testbot for it so assuming something it fails on your >> machine. So what's the exact failure you get? > It's compiler warnings, you have several uninitialized or unused > variables. Please review your changes carefully. > Okay, will do. Strangely I see no warnings here, but that's probably a different gcc version.

Oct. 8, 2013

Re: riched20: Set control content in WM_CREATE message

by Piotr Caban

Hi Akihiro, On 10/08/13 12:51, Akihiro Sagawa wrote: > On Sat, 05 Oct 2013 14:54:07 +0200, Piotr Caban wrote: >> + if (!(editor->styleFlags & ES_MULTILINE)) >> + { >> + len = 0; >> + while(textW[len] != '0' && textW[len] != '\r' && textW[len] != '\n') >> + len++; >> + } > > Although this patch has been committed as e660bf676c111ce20d9e868280094f1c5bb81c79, > I doubt that it works properly. Did you mean '\0' or 0? I meant to check for terminating null-character. I'll fix it. Thanks, Piotr

Oct. 8, 2013

Re: riched20: Set control content in WM_CREATE message

by Akihiro Sagawa

On Sat, 05 Oct 2013 14:54:07 +0200, Piotr Caban wrote: > + if (!(editor->styleFlags & ES_MULTILINE)) > + { > + len = 0; > + while(textW[len] != '0' && textW[len] != '\r' && textW[len] != '\n') > + len++; > + } Although this patch has been committed as e660bf676c111ce20d9e868280094f1c5bb81c79, I doubt that it works properly. Did you mean '\0' or 0? Regards, Akihiro Sagawa

Oct. 8, 2013

Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.

by Henri Verbeet

On 8 October 2013 00:27, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index 52eac16..eb8ca7e 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -5608,8 +5608,6 @@ HRESULT surface_load_location(struct wined3d_surface *surface, DWORD location, c > } > } > > - if (location == SFLAG_INSRGBTEX && gl_info->supported[EXT_TEXTURE_SRGB_DECODE]) > - location = SFLAG_INTEXTURE; > > if (surface->flags & location) > { > @@ -5671,12 +5669,6 @@ HRESULT surface_load_location(struct wined3d_surface *surface, DWORD location, c > surface_evict_sysmem(surface); > } > > - if (surface->flags & (SFLAG_INTEXTURE | SFLAG_INSRGBTEX) > - && gl_info->supported[EXT_TEXTURE_SRGB_DECODE]) > - { > - surface->flags |= (SFLAG_INTEXTURE | SFLAG_INSRGBTEX); > - } > - > return WINED3D_OK; > } > This change seems good on its own, as far as I can tell all callers already handle this correctly. I'm less sure about the other changes, the texture code seems like the right place to handle EXT_texture_sRGB_decode.

Oct. 8, 2013

Re: winemac.drv: add fullscreen mode support for Mac OS X 10.7+

by Ken Thomases

Hi, I finally got around to working on support for Cocoa full-screen mode in the Mac driver, based on the work of Kevin Eaves. I've attached a new patch. This patch can only be applied on top of the other Mac driver patches I just submitted to wine-patches. Some changes from Kevin's original, in no particular oder: * I have not used the user32 hack to increase the max tracking size and let windows grow so their non-frame area covers the screen. Instead, the call to SetWindowPos() that results from a WINDOW_FRAME_CHANGED event uses SWP_NOSENDCHANGING for Cocoa-full-screen windows. That prevents any immediate modification of the new window rect to be within the max tracking size. However, some programs (e.g. Guild Wars) end up moving the window again shortly afterward and then it gets constrained. This results in a window that doesn't quite fill the screen, showing a plain background around the edges. This isn't ideal. As previously discussed, this may require a new driver entry point to allow it to override the size limits. (Although I got slapped down for trying to add a similar entry point for some other work.) * Cocoa understandably refuses to minimize a window that's in full-screen mode. So, if Win32-land tries to programmatically minimize a full-screen window, Cocoa just immediately tells it that it's been unminimized. This shouldn't come up much. (One can access a window's system menu using the keyboard to test.) * We can't distinguish the program trying to make a window Win32 full-screen vs. it merely echoing back the frame set by Cocoa full-screen. So, we never consider a window to be in Win32 full-screen mode if it's in Cocoa full-screen mode. That means that the menu and Dock auto-unhide. Many (most?) apps will modify the window style in addition to just setting the frame such that it becomes incompatible with Cocoa full-screen mode. In that case, the window is first taken out of Cocoa full-screen and then put into Win32 full-screen mode. The menu and Dock are properly hidden, but the window went back to its original space, which may not be what the user wants. * I have added the standard menu item for controlling Cocoa full-screen, Enter Full Screen, to the Window menu. Cocoa automatically renames that to Exit Full Screen and back as the window enters and exits full-screen mode. As with other items in the Mac menus, I don't allow keyboard shortcuts that don't include Option among the modifiers. So, I've used Command-Option-Control-F instead of just Command-Control-F. * The menu item and the window widget are properly disabled when the window is disabled. * The maximum tracking size set by the app for the window is respected in full-screen mode. If the app leaves the default max tracking size alone, then the full-screen size is unconstrained (and so fills the screen) even though the Win32 default is slightly too small to allow that. * If the app programmatically changes the window rect while the window is in Cocoa full-screen mode, that change is honored. This may end up looking a bit odd, but is necessary for correctness. Furthermore, the changed rect is maintained as the window exits full-screen mode, which is not what Cocoa would normally do. (Cocoa restores the window to the size and position it had before entering full-screen.) This is necessary when, for example, a game switches from windowed (in Cocoa full-screen mode) to Win32 full-screen. It will often change the window style in such a way that forces it out of Cocoa full-screen and changes its size to fill the screen. We don't want Cocoa negating that size change as it transitions out of Cocoa full-screen mode. Programmatic changes of the window rect that occur during and shortly after the transition into full-screen are not interpreted as setting the frame that should be restored when exiting full-screen mode. Those are probably just responses from Wine and the app to the changes that Cocoa has initiated. * I set NSWindowCollectionBehaviorFullScreenAuxiliary on any windows which don't get NSWindowCollectionBehaviorFullScreenPrimary. I'm not certain that this is right. That flag is not as clearly documented as I would like. My intent is to allow other Wine windows to share the space with a full-screen-primary window. * WS_EX_TOOLWINDOW windows (utility windows, in Cocoa parlance) are not eligible for Cocoa full-screen. This means that they get NSWindowCollectionBehaviorFullScreenAuxiliary as per the previous point, so they can share a space with a full-screen primary window. * I have left out any attempt to reconcile Cocoa full-screen with changes to the display mode which result in the displays being captured. I don't know of an app which does that while leaving its window eligible for Cocoa full-screen, although I haven't tested many yet. I invite everybody who's interested to test and/or review. Cocoa full-screen was introduced in Mac OS X 10.7, so you have to be running that or later. Kevin, first, thanks again for your original work on this. Second, you seem to have tested with a variety of apps, including some games or other full-screen apps or ones which changed the display mode. Can you run some new tests and let me know about failures and rough edges? I'd welcome your review and feedback. Thanks, Ken

Oct. 8, 2013

Re: [1/3] xmllite: Use buffer offset instead of pointers

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > On 10/6/2013 19:06, Nikolay Sivov wrote: >> It's normal to grow destination buffer, in this case all stored >> pointers will be trashed. This patch uses offsets from start of a >> buffer instead. >> > Hi, Alexandre. > > Patches list shows a build failure for this one, and I don't see any > failures on testbot for it so assuming something it fails on your > machine. So what's the exact failure you get? It's compiler warnings, you have several uninitialized or unused variables. Please review your changes carefully. -- Alexandre Julliard julliard(a)winehq.org

Oct. 8, 2013

Re: msi/tests: Use BOOL type where appropriate (resend)

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://newtestbot.winehq.org/JobDetails.pl?Key=2667 Your paranoid android. === wvista (32 bit msi) === Timeout === w2008s64 (32 bit msi) === Timeout Failure running script in VM: network read timed out === w2008s64 (64 bit msi) === Timeout

Oct. 8, 2013

Re: msi/tests: Use BOOL type where appropriate

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://newtestbot.winehq.org/JobDetails.pl?Key=2660 Your paranoid android. === wvista (32 bit msi) === The test timed out === w2008s64 (32 bit msi) === The test timed out === w7pro64 (32 bit msi) === No test summary line found Failure running script in VM: network read timed out === w2008s64 (64 bit msi) === Timeout === w7pro64 (64 bit msi) === Timeout

Oct. 7, 2013