- 07 Sep, 2016 9 commits
-
-
Sebastian Lackner authored
Signed-off-by:
Sebastian Lackner <sebastian@fds-team.de> Signed-off-by:
Alexandre Julliard <julliard@winehq.org>
-
Bruno Jesus authored
Signed-off-by:
Bruno Jesus <00cpxxx@gmail.com> Signed-off-by:
-
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Akihiro Sagawa authored
Signed-off-by:
Akihiro Sagawa <sagawa.aki@gmail.com> Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com> Signed-off-by:
-
Bruno Jesus authored
Signed-off-by:
-
Bruno Jesus authored
Signed-off-by:
-
- 06 Sep, 2016 19 commits
-
-
Huw Davies authored
In practice this bug is not observed since midl, unlike widl, does not generate ranges in inline stub mode. For interpreted stubs, where midl does generate ranges, the [out] parameters are zero-initialised by the runtime. Signed-off-by:
Huw Davies <huw@codeweavers.com> Signed-off-by:
-
Andrey Gusev authored
Signed-off-by:
Andrey Gusev <andrey.goosev@gmail.com> Signed-off-by:
-
Jacek Caban authored
Signed-off-by:
Jacek Caban <jacek@codeweavers.com> Signed-off-by:
-
Jacek Caban authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
Hans Leidekker <hans@codeweavers.com> Signed-off-by:
-
David Keijser authored
Signed-off-by:
David Keijser <keijser@gmail.com> Signed-off-by:
-
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Aric Stewart authored
Signed-off-by:
Aric Stewart <aric@codeweavers.com> Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Henri Verbeet authored
Signed-off-by:
Henri Verbeet <hverbeet@codeweavers.com> Signed-off-by:
-
Jacek Caban authored
Signed-off-by:
-
Sebastian Lackner authored
Signed-off-by:
-
Sebastian Lackner authored
Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Jacek Caban authored
Signed-off-by:
-
Michael Stefaniuc authored
Signed-off-by:
Michael Stefaniuc <mstefani@redhat.de> Signed-off-by:
-
- 02 Sep, 2016 12 commits
-
-
Alexandre Julliard authored
Signed-off-by: -
Hugh McMaster authored
Signed-off-by:
Hugh McMaster <hugh.mcmaster@outlook.com> Signed-off-by:
-
Akihiro Sagawa authored
Signed-off-by:
-
Sebastian Lackner authored
Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Huw Davies authored
Signed-off-by:
-
Stefan Dösinger authored
Signed-off-by:
Stefan Dösinger <stefandoesinger@gmx.at> Signed-off-by:
-
Stefan Dösinger authored
Signed-off-by:
-
Stefan Dösinger authored
Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Ken Thomases authored
When a window is shown, it may not have drawn its content into the backing surface, yet. Cocoa will draw the window, starting with its standard light gray background and then the content view. However, the content view won't have anything to draw, yet, though, so the window background is not drawn over. A short while later, usually, the app will paint its content into the window backing surface and Cocoa will be told to redraw the window. This works, but the user can often see the flash of the window background color first. This is especially visible for windows with dark content. Part of the fix is to set the window background to transparent until the content view has actually drawn once since the window was shown. That's not sufficient on its own, though. We had disabled Cocoa's automatic display mechanism for windows and put display on a display-link timer. This meant that the window was not actually cleared to its transparent color. When the window was shown, the Window Server displayed a white backing buffer. It is the app process which should fill that backing buffer with clear color but, because we had disabled auto-display, that wasn't getting done at the same time the window was displayed. It was happening some time after. Again, the result was a visible flicker of white. So, we now temporarily re-enable auto-display just before showing a window. Signed-off-by:
Ken Thomases <ken@codeweavers.com> Signed-off-by:
-
