This only really affects OpenGL child windows. GDI rendering to the window
surface is still only blitted to the window's content view. The descendant
views don't draw and so are transparent, letting the content view show through.
Using Cocoa views for child windows fixes a problem where changes to the
position and visibility of child GL windows didn't properly affect the Cocoa GL
view. Hiding, showing, and moving the top-level window affected the Cocoa
window and thus, indirectly, the GL view. Moving the child GL window itself
was propagated to the GL view, so that worked. But hiding, showing, or moving
any of the intervening ancestors of the child GL window didn't properly affect
the GL view. Neither did hiding or showing the child GL window itself.
This also slightly improves the clipping of the GL view by its ancestors,
although it still doesn't work quite right due to Cocoa bugs. There are also
remaining bugs with z-order among multiple GL views and clipping by overlapping
siblings. I hope to eventually fix those using Core Animation layers, for
which this is a prerequisite.
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 reverts commits 38f579f9ba and
02416314ab.
No extant application uses this, nor are the wined3d maintainers
interested in using it.
Signed-off-by: Charles Davis <cdavis5x@gmail.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The spec for GL_ARB_framebuffer_object (and thus, OpenGL 3.x and up) is
quite clear on what happens when a context is made current with no
drawable(s). In fact, the WGL_ARB_create_context extension amends
WGL_ARB_make_current_read (as well as the base spec for wglMakeCurrent)
specifically to allow this.
Signed-off-by: Charles Davis <cdavis5x@gmail.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Charles Davis <cdavis5x@gmail.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
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.
It's not necessary. Unlike with X11, on Mac OS X the pixel format doesn't affect
the properties of windows and views. The pixel format is a property of the GL
context, which can attach to any view.
Andrey Gusev