- 18 Sep, 2023 20 commits
-
-
Rémi Bernon authored
And avoid checking a possibly freed message.
-
Eric Pouech authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55560Signed-off-by: Eric Pouech <epouech@codeweavers.com>
-
Connor McAdams authored
Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>
-
Ally Sommers authored
-
Esme Povirk authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54031
-
Alistair Leslie-Hughes authored
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
-
Jinoh Kang authored
Windows seems to recognize Unicode codepoints above U+007F as a valid identifier character regardless of their actual character class. Mimic that behaviour.
-
Nikolay Sivov authored
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
-
Rémi Bernon authored
-
Rémi Bernon authored
-
Rémi Bernon authored
-
Rémi Bernon authored
-
Rémi Bernon authored
-
Rémi Bernon authored
-
Rémi Bernon authored
-
Rémi Bernon authored
-
Huw Davies authored
-
Connor McAdams authored
Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>
-
Connor McAdams authored
Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>
-
Connor McAdams authored
Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>
-
- 15 Sep, 2023 20 commits
-
-
Alexandre Julliard authored
-
Esme Povirk authored
If the SendMessageTimeout call takes a long time, we can get other messages which also set the observed wparam value. Apparently, this is especially likely on Windows 7. This also removes the (wParam == 0xbaadbeef) check which may have been intended to serve the same goal but doesn't work because the observed wParam value is still assigned. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54194
-
Alex Henrie authored
-
Alex Henrie authored
-
Eric Pouech authored
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
-
Gabriel Ivăncescu authored
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
-
Gabriel Ivăncescu authored
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
-
Gabriel Ivăncescu authored
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
-
Gabriel Ivăncescu authored
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
-
Gabriel Ivăncescu authored
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
-
Gabriel Ivăncescu authored
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
-
Gabriel Ivăncescu authored
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
-
Gabriel Ivăncescu authored
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
-
Zebediah Figura authored
-
Matteo Bruni authored
This is in the same vein as e106bbdd and further fallout from 2ddb6b66.
-
Matteo Bruni authored
-
Matteo Bruni authored
It can be unnecessary at best and unsupported at worst (e.g. no ARB_texture_multisample or MultisampleTextures setting disabled).
-
Matteo Bruni authored
-
Matteo Bruni authored
To wined3d_context_gl_apply_fbo_state_explicit(). It's not really related to blitting in principle; what it does is attaching specific textures to the FBO instead of the d3d render targets, which was the "original" use of FBOs in wined3d. BTW even that original use case (currently handled by context_state_fb()) is not using render_targets[] directly anymore and we end up kind of abusing the blit_targets[] arrays in struct wined3d_context_gl. Maybe we could rename that array as well.
-
Matteo Bruni authored
All the callers (i.e. the blitters) also call context_gl_apply_texture_draw_state() that does that part of the setup anyway.
-