November 2014 - Wine-Devel - list.winehq.org

Re: [PATCH 2/2] mshtml: Added IHTMLDocument2::execCommand implementation.

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=10428 Your paranoid android. === w2000pro (32 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED dom.c:6147: Test failed: execCommand returned 0 === wxppro (32 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED dom.c:6147: Test failed: execCommand returned 0 === wvistau64 (32 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED === w2008s64 (32 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED === wvistau64 (64 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED === w2008s64 (64 bit dom) === dom.c:6138: Test failed: execCommand failed: 80070057, expected OLECMDERR_E_NOTSUPPORTED

Nov. 24, 2014

Re: [PATCH 5/5] d3d8: Only one fullscreen swapchain is allowed.

by Henri Verbeet

On 21 November 2014 at 18:32, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if(!desc.windowed) Formatting. (Also present in the d3d9 version.)

Nov. 24, 2014

Re: [PATCH 2/5] d3d9/tests: Fix test_cursor().

by Henri Verbeet

On 21 November 2014 at 18:32, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + window = CreateWindowA("d3d9_test_wc", "d3d9_test", WS_OVERLAPPEDWINDOW | WS_VISIBLE, > + 0, 0, 640, 480, NULL, NULL, NULL, NULL); > + > + ret = SetCursorPos(50, 50); > + ok(ret, "Failed to set cursor position.\n"); > + flush_events(); > memset(&info, 0, sizeof(info)); > info.cbSize = sizeof(info); > ok(GetCursorInfo(&info), "GetCursorInfo failed\n"); > cur = info.hCursor; > > - window = CreateWindowA("d3d9_test_wc", "d3d9_test", WS_OVERLAPPEDWINDOW, > - 0, 0, 640, 480, NULL, NULL, NULL, NULL); > ok(!!window, "Failed to create a window.\n"); I think I'd prefer the ok() moved as well, like in the d3d8 version.

Nov. 24, 2014

Re: [1/3] wined3d: Add a new enum for GL_EXT_geometry_shader4

by Henri Verbeet

On 22 November 2014 at 00:16, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > --- I don't think we want this. We're never going to use EXT_geometry_shader4, and in fact are likely to drop ARB_geometry_shader4 in favour of just using core contexts. We should just do the work to make core contexts work. Matteo has some initial patches if you'd like to help out with that.

Nov. 24, 2014

Re: gdiplus:GdipDrawImagePointsRect has a nosie vertical lineoutputafter resampled

by Vincent Povirk

I don't think switching to doubles will help. The extra precision should get our result closer to 6.0, but 5.999999 will still fail. We should look for a more direct way to calculate src_pointf, to avoid introducing rounding errors. Maybe if we start by subtracting ptf[0] from dst_point, we can more directly transform that to coordinates relative to the source rectangle, then add srcx,srcy. This needs more thought than I can put in right now, but I suspect the current solution is more complicated than it needs to be. On Sun, Nov 23, 2014 at 9:23 PM, Liu Changhui <liuchanghui(a)linuxdeepin.com> wrote: > Dear Vincent: > The PixelFormat32bppRGB shuld be PixelFormat32bppARGB in the > test_GdipDrawImagePointsRectNeedResample function of my patch. > > In test_GdipDrawImagePointsRectNeedResample, the first src_pointf valuse is > : > X=5.992676, src_pointf.Y=0.000000 when the destination pixel is(x=699,y=0), > and srcx=6.000000,srcy=0.000000,srcwidth=48.000000,srcheight=26.000000, > > so the follow if statement will test false : > if (src_pointf.X >= srcx && src_pointf.X < srcx + srcwidth && src_pointf.Y >>= srcy && src_pointf.Y < srcy+srcheight) > > then the destination pixel (x=699,y=0) will be filled with zero value, > but we expect that pixel shoule be filled a color same as the source image. > > I think make these variables: > dst_to_src_points, src_pointf, x_dx, x_dy, y_dx, y_dy all use 64bit double > float type maybe can fixed this situation. > But GpointF and GpMatrix has used 32bit float type, and many gdiplus > functions depended on them. > > Can you give me some advice ? Thank you! > > > ------------------ Original ------------------ > From: "Vincent Povirk"<madewokherd(a)gmail.com>; > Date: Sun, Nov 23, 2014 12:57 PM > To: "刘昌辉"<liuchanghui(a)linuxdeepin.com>; > Cc: "Sebastian Lackner"<sebastian(a)fds-team.de>; > "wine-devel"<wine-devel(a)winehq.org>; > Subject: Re: gdiplus:GdipDrawImagePointsRect has a nosie vertical > lineoutputafter resampled > > This will cause us to draw outside of the destination when the image > is both enlarged and rotated. > > That if statement is there to make sure we only draw to the area > inside the shape defined by the points array. src_pointf should be > within the range defined by srcx/srcy/srcwidth/srcheight if and only > if (x,y) is within that shape. If that's not the case, it probably > means we're calculating src_pointf incorrectly for the whole image, > not just the edges. > > I'm not sure Sebastian realized this, but in this case > GdipBitmapGetPixel is different from reading the image directly. > Because PixelFormat32bppRGB does not store alpha data in the bitmap, > GdipBitmapGetPixel will always return an alpha value of 255, and you > will get a non-zero value even if the pixel is black. I suggest > testing for the exact value you expect. That should also remove the > need for the trace() calls.

Nov. 24, 2014

Re: gdiplus:GdipDrawImagePointsRect has a nosie vertical lineoutputafter resampled

by Liu Changhui

Dear Vincent: The PixelFormat32bppRGB shuld be PixelFormat32bppARGB in the test_GdipDrawImagePointsRectNeedResample function of my patch. In test_GdipDrawImagePointsRectNeedResample, the first src_pointf valuse is : X=5.992676, src_pointf.Y=0.000000 when the destination pixel is(x=699,y=0), and srcx=6.000000,srcy=0.000000,srcwidth=48.000000,srcheight=26.000000, so the follow if statement will test false : if (src_pointf.X >= srcx && src_pointf.X < srcx + srcwidth && src_pointf.Y >= srcy && src_pointf.Y < srcy+srcheight) then the destination pixel (x=699,y=0) will be filled with zero value, but we expect that pixel shoule be filled a color same as the source image. I think make these variables: dst_to_src_points, src_pointf, x_dx, x_dy, y_dx, y_dy all use 64bit double float type maybe can fixed this situation. But GpointF and GpMatrix has used 32bit float type, and many gdiplus functions depended on them. Can you give me some advice ? Thank you! ------------------ Original ------------------ From: "Vincent Povirk"<madewokherd(a)gmail.com>; Date: Sun, Nov 23, 2014 12:57 PM To: "刘昌辉"<liuchanghui(a)linuxdeepin.com>; Cc: "Sebastian Lackner"<sebastian(a)fds-team.de>; "wine-devel"<wine-devel(a)winehq.org>; Subject: Re: gdiplus:GdipDrawImagePointsRect has a nosie vertical lineoutputafter resampled This will cause us to draw outside of the destination when the image is both enlarged and rotated. That if statement is there to make sure we only draw to the area inside the shape defined by the points array. src_pointf should be within the range defined by srcx/srcy/srcwidth/srcheight if and only if (x,y) is within that shape. If that's not the case, it probably means we're calculating src_pointf incorrectly for the whole image, not just the edges. I'm not sure Sebastian realized this, but in this case GdipBitmapGetPixel is different from reading the image directly. Because PixelFormat32bppRGB does not store alpha data in the bitmap, GdipBitmapGetPixel will always return an alpha value of 255, and you will get a non-zero value even if the pixel is black. I suggest testing for the exact value you expect. That should also remove the need for the trace() calls.

Nov. 24, 2014

Re: [PATCH 1/5] dxgi/tests: Test fullscreen and multiple swapchains.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-11-21 19:11, schrieb Marvin: > === w7u (32 bit device) === > device.c:458: Test failed: SetFullscreenState failed, hr 0x887a0022. > device.c:469: Test failed: Got unexpected hr 0x87a0001. > device.c:475: Test failed: Got unexpected hr 0. Please skip this patch for now. The errors reported by the testbot happen because the application is not in foreground. I've come up with a workaround for this(https://testbot.winehq.org/JobDetails.pl?Key=10418), but the Win7 machines have some follow-up errors I have not been able to resolve. My real Win7 machines work just fine. The other 4 patches are valid without this patch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUckZTAAoJEN0/YqbEcdMwHzkP+wREsPj2IyjMejBFj2oq+Rj3 k1zgyuRpDXlZOhRTR90w6T/F+gIu/ohxtBLdNDAaLDR3b6GuK9yAeOZiBHmevdQv hcvZN+p5oxJNMorY+ILGHhGg6qD0mypTrMFeOkFCS2x64p1lC2gtXaF+TH2/KIC9 3EgiGg83QcA/gHsKG+qblhnb2fXldKYKFyTOF7xvwYliaTC+n95wT6Sd4mqkdItM HlsKM4iNOKQgxquxOZZ487ujGKEPLRAQrdUy3Pj840A14Mz1YpzZWHfMebZFQ1iM 2h3Z4X2CkwWRk4OWUQir5L20KcSexMGJOsQXbScSNY8ggk+lL/cuH6eM4E0r6F9G xnRKoeE8zqeHcD6KIihOySp1FIJF+8CgOj4pX7fASYIToqf4vnB26dLyVLdUnUlY dZdf8fz3wQmPmr95ENEnuBpS59R1sdikG3PGsLpAr/06tJxYAxC9OvN8uL9xGLkT +hN1WITxvRX9QjsrJt7YwubA4KwFoiHCXe7pgyhqW36rF3LVkH+Uxu/3xUoM2y5e VZBnmiGnuObd+MsidDSNwbQpqxdaXihXyKf4is+K6lQBIyfkoJfXoe2MEQUFjUtl bbn9ctmHsuhHmzs776oB9R2hmFugknIdsSU2AZD4zP/9+T7q/kXLefIxijzpan83 QWURTLTj5pXcr/v1bV/M =veOZ -----END PGP SIGNATURE-----

Nov. 23, 2014

Re: [PATCH] winex11.drv: call XRRSetScreenSize when changing resolution

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've done a bit more testing. As I suspected, increasing the resolution with Wine is indeed broken. With a single monitor set to 1024x768, running a d3d game in 1920x1080 sets the monitor to 1920x1080 but displays only the first 1024x768 pixels. The radeon driver doesn't enforce the monitor vs screen size restrictions properly, so we end up with this seemingly invalid configuration: Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192 DisplayPort-0 disconnected (normal left inverted right x axis y axis) HDMI-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm 1920x1080 60.0*+ 50.0 50.0 50.0 59.9 I guess the Nvidia driver would abort with an error instead. For the rest of the testing I have attached a second monitor DVI-0. HDMI-0 1920x1080, absolute coordinate 0, 0. DVI-0 uses 1280x1024, right of HDMI-0. This gives a virtual screen size of 3200x1080. DVI-0 is at 1920x0 in absolute coordinates. When I change the resolution of HDMI-0 with xrandr --output HDMI-0 - --crtc 0 --mode 1024x768, DVI-0 stays at an absolute position of 1920x0. There is a gap between HDMI-0 and DVI-0 where windows and the mouse pointer can disappear. xrandr sets the screen dimensions to the smallest rectangle required for the active monitors, i.e. 3200x1024. (Down from 3200x1080). The logic for that appears to be in set_screen_size() in xrandr.c, in the "fit fb to output" path. KDE's screen setup tool uses the same logic as xrandr, but if you spend close attention to the preview you can see that it is going to create a gap between your monitors. Windows appears to use a slightly different logic. It changes the position of extra monitors to close the "gap" xrandr creates. The question is if we clone the behavior of Windows or the behavior of xrandr. From a testability point of view cloning the Windows behavior is probably better, but from a desktop integration point of view we may want to clone the xrandr behavior. With the xrandr behavior it is easier to restore the old screen setup once a fullscreen game exits. Writing tests for the single monitor case is the first step either way. A way to outsource the screen sizing logic would be nice - it would be nicer if we didn't have to bother about this. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUcjWXAAoJEN0/YqbEcdMwUwcP/iJIR/NV7yEWhQs63lKkLHOw 3kek15ghTGgxqCvFugy9q9hzi3ulvVlS278p8jCQ39iWk3IUrGcDLk/7Cw9QwkSi q9QgqJJTuzRp7VsGJ+MdatLaUifcvxl0BfFNi5rrMePwfqOy0HwKRFIZGN1zSjgg FaC6EKN37ujlMi5f72FVtYH0R2O6v4ngPcd98TPSecSMs2bbRVpv3wnfq6qB5c8t WsnUKEWhFr+/74QoeyUYbWfvLNR7o3qVziBk0AI15V/8XhqomfK/oq3pNtHceqx+ hDn0JS0Xatrp0ZR1ToQs+fk5uo75QTbV5nFGE1RSSYrlawNAzhdfQkyXCdXVYRCt YEETDpSAyFMYBqqzcKsylfsfpQp2erLcKf1EvlyCZTWLm6JC6XL3l5YiJYoo/Y9a C/A1LF9MuqGOGRYexc9BAOu1wZbf5HEQcwJg2gfqM+2oL6+PPLkYZR/ahx9iFkKg d7nEmN7tVjof2TM2jNSJBmeh51AwS8CCw5Ro3ONZTGGioOCCyADMhFyI4uufD7M0 ReulEb88gNHRDCGmZiLYMZPu9fdE6xUOEYjaRTlttMKI6BKY68ClTWsfvFvxHG+t rmW2Wq7nRGV2RZ1o5rLWXSdSSti3ixo/k2RuqsEoPWA5VFTA/VyAMF3O6Yb3zS2J T2QR7BRqdSvfTcJuv2It =VvNQ -----END PGP SIGNATURE-----

Nov. 23, 2014

Re: gdiplus:GdipDrawImagePointsRect has a nosie vertical line outputafter resampled

by Vincent Povirk

This will cause us to draw outside of the destination when the image is both enlarged and rotated. That if statement is there to make sure we only draw to the area inside the shape defined by the points array. src_pointf should be within the range defined by srcx/srcy/srcwidth/srcheight if and only if (x,y) is within that shape. If that's not the case, it probably means we're calculating src_pointf incorrectly for the whole image, not just the edges. I'm not sure Sebastian realized this, but in this case GdipBitmapGetPixel is different from reading the image directly. Because PixelFormat32bppRGB does not store alpha data in the bitmap, GdipBitmapGetPixel will always return an alpha value of 255, and you will get a non-zero value even if the pixel is black. I suggest testing for the exact value you expect. That should also remove the need for the trace() calls.

Nov. 23, 2014

Re: gdiplus:GdipDrawImagePointsRect has a nosie vertical line outputafter resampled

by 刘昌辉

Dear All, I'm sorry for my mistakes. I modified my patch, please review it again if you have time. Thanks a lot! ------------------ Original ------------------ From: "Sebastian Lackner"<sebastian(a)fds-team.de>; Date: Sat, Nov 22, 2014 00:19 AM To: "wine-devel"<wine-devel(a)winehq.org>; "liuchanghui"<liuchanghui(a)linuxdeepin.com>; Subject: Re: gdiplus:GdipDrawImagePointsRect has a nosie vertical line outputafter resampled Hi, while looking quickly over your patch I noticed a couple of mistakes / things you should probably change: On 21.11.2014 15:32, 刘昌辉 wrote: >+ int src_img_height = src_rect.Height; >+ int dest_img_width = dest_rect.X + dest_rect.Width; >+ int dest_img_height = dest_rect.Height; >+ BYTE* src_img_data = malloc (src_img_width*src_img_height*4); >+ BYTE* dest_img_data = malloc (dest_img_width*dest_img_height*4); You shouldn't use malloc(...) and free(...) in wine source, use HeapAlloc(...) and HeapFree(...) instead. >+ >+ /*first line*/ >+ value = *( (DWORD*)dest_img_data + dest_rect.X) ; >+ /*printf ("pixel(%d,%d) = %08x\n", dest_rect.X, 0, value );*/ I assume the printf was for debugging, remove it, or if it is really very important then use trace(...) instead. Other tests use GdipBitmapGetPixel(...) for reading the color of specific pixels. If its possible to use that here too, it would look a bit better than directly accessing the memory. >+ ok ( value > 0, >+ "dest image color should same as src image color\n"); You are switching between different styles in your patch several times. Try to make the style match a bit more the sourrounding code, especially whitespace before and after functions. In this case a linebreak is also not really necessary for example, other lines are much longer. Regards, Sebastian

Nov. 23, 2014