When changing DPI, a "fix blurry apps" popup may appear on Windows 10. The popup may interfere with
other tests as it steals focus, causing them to fail. So set IgnorePerProcessSystemDPIToast to 1 to
temporarily disable the popup.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When changing DPI, a "fix blurry apps" popup may appear on Windows 10. The popup may interfere with
other tests as it steals focus, causing them to fail. So set IgnorePerProcessSystemDPIToast to 1 to
temporarily disable the popup.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52108
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This array is accessed at index 5 on line 5138.
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Matteo Bruni <mbruni@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Also check StrokeContains result on the last segment when the last vertex
of a bezier curve coincedes with the first vertex of the figure and
the figure is explicitly closed.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
While the reason for doing this is to allow draws referencing mapped buffer
resources to succeed, the behaviour of the application in the referenced bug
report (FlatOut) appears to be slightly different; it does end up drawing
while buffer objects are mapped due to reordering of map operations inside the
command stream, but as far as I can tell those buffer objects are not
referenced by the draw. The driver in question (fglrx/Catalyst) appears to
simply be a bit overzealous with throwing errors, and unfortunately doesn't
provide much more information than "glDrawElementsBaseVertex has generated an
error (GL_INVALID_OPERATION)". The issue is not reproducible with Mesa
radeonsi.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46118
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Ideally we should be using sock_get_poll_events() and sock_poll_event() instead,
but that seems like an overly risky change for this late in code freeze.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51442
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
DefWindowProc() does not propagate the wparam; it updates it instead.
Spotted by YAL.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52327
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Device context bit depths other than 32-bit are emulated and the real bit depth for display DCs is
still 32-bit. Thus, a 32-bit DDB should be allowed to be selected into a display compatible DC even
if the DC reports a different bit depth.
Fix a regression from d171d11.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51805
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Otherwise, async_waiting() returns 0, leading the socket object to
believe that the previous async request has not yet been acknowledged.
This results in I/O hang for subsequent reads (until shutdown).
Also, async_destroy() calls async_reselect() only after removing the
async request from the queue. Make async_set_result() consistent with
this behaviour.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52332
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This can happen after the window surface has been destroyed.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52231
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Nikolay Sivov