When this Retina mode is enabled and the primary display is in the user's
default configuration, Wine gets told that screen and window sizes and mouse
coordinates are twice what Cocoa reports them as in its virtual coordinate
system ("points"). The Windows apps then renders at that high resolution and
the Mac driver blits it to screen. If the screen is actually a Retina display
in a high-DPI mode, then this extra detail will be preserved. Otherwise, the
rendering will be downsampled and blurry.
This is intended to be combined with increasing the Windows DPI, as via winecfg.
If that is doubled to 192, then, in theory, graphical elements will remain the
same visual size on screen but be rendered with finer detail. Unfortunately,
many Windows programs don't correctly handle non-standard DPI so the results
are not always perfect.
The registry setting to enable Retina mode is:
[HKEY_CURRENT_USER\Software\Wine\Mac Driver]
"RetinaMode"="y"
Note that this setting is not looked for in the AppDefaults\<exe name> key
because it doesn't make sense for only some processes in a Wine session to see
the high-resolution sizes and coordinates.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Most queries are handled even by threads which are otherwise blocked in
OnMainThread(). There's a problem with QUERY_IME_CHAR_RECT, though, in that it
can be handled before a previously-queued IM_SET_TEXT event, in which case its
character range may be out of bounds. Some apps (e.g. Excel 2007) hang due to
the bad range.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Among other things, this fixes Syberia 2. That game shows, hides, and then
shows its window. Hiding it caused a WINDOW_LOST_FOCUS event to be queued.
By the time it was processed, the window was the foreground window again.
In response to being told it had lost focus, the game minimized its window.
Hiding the window should have prevented or discarded the WINDOW_LOST_FOCUS
event since the change was driven from Wine and the Win32 foreground/active
window state would already be correct. In addition, when the program
re-showed its window and made it foreground, that should have discarded the
event as being out of date. Now they do.
The main dispatch queue is a serial queue and is a shared resource. If we
submit a long-running task to it, then no other tasks, including those submitted
by the system frameworks, can run until it completes.
Some events get queued for all GUI-connected threads but are only processed
by the first to dequeue them. Other threads which tend their event queue
discard such already-processed events. However, some threads may be
connected to the GUI but never tend their event queue. To prevent such
threads from accumulating zombie events, the zombies are cleared each time a
new event is queued.
Some events are application-wide, not specific to a thread. Such an event
needs to be broadcast to all GUI-attached threads because we don't know which
are handling events, but we don't want the event to be processed in each.
Often it should only be processed by the first to pull it from its queue.
Brendan Shanks