1berry/qtbase
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

macOS: Restore logic to set wantsBestResolutionOpenGLSurface

Browse Source 
The logic was removed in 1fc7ca091b3fdda52381a383318a3a752ec21132 when
we removed support for surface-backed views, based on the documentation
for wantsBestResolutionOpenGLSurface noting that layer-backed views
ignore the property.

But in some cases, when plugin views are embedded into host views, and
the host was built with a pre-10.14 SDK, AppKit seems to get confused,
and we still need to set this property.

Fixes: QTBUG-93770
Change-Id: Id67f2fcb8c090c0e01c05d00792eaef311146df1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 40878e75176880e95398604d9e63be2138cc642b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This commit is contained in:
Tor Arne Vestbø 2021-05-20 14:26:47 +02:00 committed by Qt Cherry-pick Bot
parent d7ea41ab03
commit 4e58b19b0c
1 changed files with 8 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
src/plugins/platforms/cocoa/qcocoaglcontext.mm
View File

@ -393,6 +393,14 @@ bool QCocoaGLContext::setDrawable(QPlatformSurface *surface)
if (view == QT_IGNORE_DEPRECATIONS(m_context.view)) if (view == QT_IGNORE_DEPRECATIONS(m_context.view))
return true; return true;
// We generally want high-DPI GL surfaces, unless the user has explicitly disabled them.
// According to the documentation, layer-backed views ignore wantsBestResolutionOpenGLSurface
// and configure their own backing surface at an appropriate resolution, but in some cases
// we've seen this fail (plugin views embedded in surface-backed hosts), so we do it anyways.
QT_IGNORE_DEPRECATIONS(view.wantsBestResolutionOpenGLSurface) = qt_mac_resolveOption(YES,
cocoaWindow->window(), "_q_mac_wantsBestResolutionOpenGLSurface",
"QT_MAC_WANTS_BEST_RESOLUTION_OPENGL_SURFACE");
// Setting the drawable may happen on a separate thread as a result of // Setting the drawable may happen on a separate thread as a result of
// a call to makeCurrent, so we need to set up the observers before we // a call to makeCurrent, so we need to set up the observers before we
// associate the view with the context. That way we will guarantee that // associate the view with the context. That way we will guarantee that