This was originally done to improve performance at the expense of visually-
correct rendering. I've reconsidered that trade-off.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The window being ordered was first put in the correct place and then was moved
to the other end of the children list by the loop that was intended to adjust
the windows strictly between the window and the ancestor.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Cocoa will draw the window frame immediately but if autodisplay of its content
view is disabled, that may leave the content area black briefly. This change
avoids that flicker.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes an issue where some windows (on some systems) would never display
their content area. If they had a title bar, they'd just display that and
nothing else.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The display link may be stopped even if there are associated windows, due to
idleness. So, it may need to be started when a window is added even if it's
not the first window.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
... rather than whether it currently has one.
This is for OpenGLSurfaceMode=behind. In that mode, we need to make the window
transparent wherever a GL-rendered view should not be clipped by GDI-rendered
children or sibling views.
Some apps attach a GL context to the view only temporarily, do some rendering,
and then detach it. But the GL surface remains, with the rendered graphics.
In order for those to show, the window needs to remain transparent even though
none of its views has a GL context currently attached.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The -fire method called by the display link callback also synchronizes on self
(while accessing the windows array). Display link operations use a lock to
synchronize, too, and it's held while the callback is running.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
They shouldn't get a separate space; they should stick with their parent (owner).
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Simply ordering them out leaves the user on the full-screen space, which is now
an empty black screen. Closing the window closes the space, too.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Cocoa doesn't handle the window being ordered out or closed during the
animation well and leaves a ghost window around.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The code had been handling ordering sibling windows relative to each other,
including windows neither of which were child windows. However, it wasn't
properly handling other relationships (e.g. cousins, nieces, uncles, etc.).
The reason this is complicated is that Cocoa keeps child windows in a fixed
relative order to their parent and siblings. The normal -orderWindow:relativeTo:
method doesn't work. One has to remove the children from the parent and re-add
them in the desired order.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Cocoa does this automatically for non-owned windows and informs the back end
via a different mechanism (WINDOW_BROUGHT_FORWARD). However, for owned windows
(child windows in Cocoa parlance), Cocoa does not change their z-order relative
to the owner (parent) or sibling owned windows when clicked. So, we have to
move the window in user32's z-order so that it gets moved appropriately on
screen in response.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Even if the (un)hidden view doesn't have attached GL contexts itself, its
descendants may. It doesn't make sense not to check them just because this
view doesn't have GL contexts.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Sierra (macOS 10.12) changed the behavior of key repeat. In previous versions
of macOS, key repeat stops when a modifier key is pressed or released. In
Sierra, it does not; it just keeps repeating as newly-modified.
On Windows, key repeat stops when a modifier key is pressed, although not when
one is released. Some programs depend on this behavior. So, the Mac driver
emulates it.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Hiding a view seems to semi-detach any attached OpenGL contexts such that
rendering no longer works. There's no GL surface for the view. Calling
-[NSOpenGLContext update] is not sufficient to reattach the context. So,
fully detach the contexts and reattach them.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
There's no reason for them to be synchronous and this improves performance.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We had been posting it when exiting fullscreen mode ended. However, certain
events during exiting could provoke the back-end to assert the window frame as
it knows it, which would be the one from full-screen mode. This would be
handled by the Cocoa thread after exiting full-screen mode. So, the window
would animate to its pre-fullscreen frame and then spontaneously go back to
covering the screen. This would be Windows-style fullscreen rather than
Cocoa-style and there'd be no obvious way to get out.
The problem occurs on macOS 10.12 (Sierra) due to a change in what methods it
calls on the window while exiting fullscreen.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
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: Alexandre Julliard <julliard@winehq.org>
This works around a Cocoa bug that causes an exception and hang if the view is
being re-ordered within its current superview (as opposed to being moved to a
new superview).
This reverts commit 9fbc364ea1 but adds some
conditions around the call to avoid the flicker on platforms where it's
unnecessary.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This avoids a Cocoa bug where, if an app in the background which is not
hidden calls -unhide:, its main menu bar window is brought forward. The
active app hasn't actually been changed. Key events continue to go to
the app in the foreground. But it's confusing to the user when they
look at the menu bar and, if they click in the menu bar, the background
app really will be activated.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Apple added the same enum declaration to their headers, causing a build failure.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It's only obliquely documented, but -[NSView addSubview:positioned:relativeTo:]
will remove the view from its old superview if it's changing superviews. If
it's just changing z-order within its current superview, it won't.
This avoids some flicker of OpenGL surfaces being removed and re-added.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-[NSView subviews] returns the views in back-to-front order, not front-to-back
as I had thought.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
As opposed to just the immediate subviews of the window contentView.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Callers can use macdrv_set_view_superview() to do that separately.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Remove the no-longer-used functionality of potentially moving the view from one
window to another. That has been taken over by macdrv_set_view_superview().
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This allows for nesting views in a hierarchy rather than only ever adding them
as direct subviews of the window content view. This functionality will be used
in subsequent commits.
This takes over some of the functionality of macdrv_set_view_window_and_frame(),
which will be removed in a subsequent commit.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
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>
This is so negative coordinates are adjusted in the same direction as
positive ones (left and up).
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>
It had been using the synchronous OnMainThread() to submit its work to the
Cocoa thread, but only queries are processed while OnMainThread() waits for the
work to complete. This led to QUERY_IME_CHAR_RECT queries being processed out
of order relative to IM_SET_TEXT events, making the character range out of
bounds with respect to the composition string.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It was added as an observer in commit 3beec95a0. Failing to remove it caused
the notification center to have a dangling pointer and caused crashes and hangs.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
[image drawInRect:rect] is documented as being "exactly equivalent to calling
[image drawInRect:rect fromRect:NSZeroRect operation:NSCompositeSourceOver
fraction:1 respectFlipped:YES hints:nil]". So, that's what I replace it with.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The change to a CVDisplayLink-driven display mechanism introduced a problem: a
Wine process never went completely idle for long periods. The display link
would fire for every refresh cycle of the display, waking a CPU from idle and
wasting energy.
To fix that, I have the display link stop itself when it determines that none
of its windows need to be displayed. When a window is subsequently marked as
needing display, it either temporarily re-enables Cocoa's normal autodisplay
mechanism so that it displays at the end of the current turn of the run loop,
or it restarts the display link. It chooses the former if it's been a long
time since the window was last displayed so that the display is done more
immediately.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes a problem where child windows ("owned" windows in Windows
parlance) would never display their contents on OS X 10.8 or earlier.
Beginning with 10.9, Cocoa calls -windowDidChangeOcclusionState: when
the window becomes visible, which is why they display on that version
and later.
Reported by Huw Davies.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It's redundant with the new CVDisplayLink-driven display mechanism.
This reverts commits d55d2ec85 and 94dc91a45.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some Windows apps cause user32 to flush the window surface much faster than the
display refresh rate. The Mac driver only marks its window as needing to be
redrawn and lets Cocoa decide how often to actually redraw. Unfortunately,
Cocoa redraws each time through the run loop and, since the Mac driver uses a
run loop source to convey messages from background threads to the main thread,
it redraws after every batch of messages.
On some versions of OS X, this excessive drawing provokes synchronization with
the window server's buffer swaps, preventing the main thread from being
responsive. Even when that doesn't happen, it's wasteful.
So, we set our windows' autodisplay property to false so that Cocoa never
displays windows itself. Then, we arrange to call -displayIfNeeded once per
display refresh cycle using a CVDisplayLink. We maintain one CVDisplayLink per
display (on demand), move windows among them as the windows change screens,
start them when they acquire their first window, and stop them when they have
none left.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some apps create a zero-sized window as their "main" window and then create
all of the other top-level windows as owned windows with that main window as
the owner. The user interacts with these owned windows. When the user
attempts to minimize one of these owned windows, the app instead minimizes the
zero-sized owner window. When an owner window is minimized, all of its owned
windows are hidden.
The Mac driver faithfully carries out these window operations. The only
visible windows are hidden and the zero-sized window is minimized. This
results in an invisible animation of the window down to a slot in the Dock -
a slot which appears mostly empty. The invisible window thumbnail is badged
with the app icon, but it still looks strange.
On Windows, the Alt-Tab switcher uses the image of the owned window to
represent the zero-sized owner.
This commit attempts to do something similar. It takes over drawing of the
Dock icon for minimized, zero-sized window. It grabs a snapshot of one of the
owned windows and draws the app badge onto it. Since the owned windows are
hidden before the zero-sized owner is minimized and we can't take snapshots of
hidden windows, we use heuristics to guess when it may be useful to grab the
snapshot. If the user minimizes an owned window from the Cocoa side, we grab
that window's snapshot. If an owned window is being hidden and no snapshot has
been taken recently, we grab its snapshot on the theory that this may be the
beginning of hiding all of the owned windows before minimizing the owner.
Unfortunately, this doesn't address the invisible animations when minimizing
and unminimizing the zero-sized owner window.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When the display mode changes such that the screen height changes, we'd like
our windows to keep their position relative to the top-left of the primary
screen. That's how WinAPI's coordinate system works and we want the WinAPI
position of the window to not change just because the display mode changed.
Unfortunately that's not achievable in Cocoa. Cocoa keeps the window
stationary relative to the screen it's on, not necessarily the primary screen,
and it's sometimes relative to the bottom-left and sometimes the top-left of
that screen.
So, what we do instead is queue an event to get the back end to reassert the
WinAPI position of the window. This is queued before Cocoa can adjust the
Cocoa position of the window which would queue a WINDOW_FRAME_CHANGED to the
back end and mess up the WinAPI position. The back end's reassertion of the
WinAPI position won't be processed by the Cocoa thread until after Cocoa has
adjusted the position and will thus override it. It will also discard any
wrong WINDOW_FRAME_CHANGED that may have been queued.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
The default behavior is that GL surfaces are on top of all non-GL content in
the window. This maximizes the performance for the common case of games, but
clipping by parents, siblings, and child windows isn't respected.
Setting OpenGLSurfaceMode to "behind" pushes the GL surface to be behind the
Mac window. The window has transparent holes punched through it so that the GL
surface shows through. USER32 and the wineserver take care of making sure the
holes are only where the GL windows would be unclipped and unoccluded. Because
the OS X window server has to composite the GL surface with the window, this
limits the framerate.
Since the Mac driver has no server-side rendering path, GDI rendering to a
window which has a GL surface doesn't work. As a partial workaround, mostly
for cases where a GL surface is created but never used, setting
OpenGLSurfaceMode to "transparent" allows the GDI rendering to show through the
transparent parts of the GL surface. The GDI rendering is drawn to the
top-level window's surface as normal. (The behavior of user32 to exclude the
portion covered by a GL window from GDI rendering is disabled.) The GL surface
is in front of the window but potentially wholly or partially transparent. It
is composited with the window behind it.
The GL surface is initially cleared to be completely transparent. So, if
no GL rendering is done, the window will appear as though the GL surface didn't
exist.
Ken Thomases