GNOME Bugzilla – Bug 682178
Offscreen windows render into low-resolution pixel space
Last modified: 2018-04-15 00:03:29 UTC
Created attachment 221731 [details] "Rotated widget" demo upscaled from 1x to a 2x userspace If an application is compiled against the Quartz backend on OS X Lion and up, GTK+ applications by and large adopt a high-resolution user interface, provided the system is in Hi-DPI ("Retina") mode for an accommodating display. Text and UI elements that don't involve pixmap images are crisp and sharp as intended. Applications that use any form of offscreen rendering, such as the GTK+ Demo, seem to pick an arbitrary scaling factor for the offscreen windows and are therefore stuck in a 1x pixel space, which is scaled up for the original screen. Steps to reproduce: 1) Enter system into a Hi-DPI mode 2) Build pango/cairo/gtk with the Quartz backend 3) Run gtk(3)-demo 4) Gawk at pretty fonts. (Optional) 5) Select either "Offscreen windows" demo, observe jaggies Expected results: Offscreen window contents are rendered at the same resolution as the host window, creating seamless sharp graphics Actual results: Offscreen window contents are rendered in a strict 1:1 pixels-to-points ratios, resulting in upscaling of their contexts back onto a hi-res screen Build Date & Platform: Built 8/18/2012 on 10.8; GTK+ 3.4.4 using modified Homebrew build scripts Additional Builds and Platforms: Problem occurs on any version of GTK+ with the Quartz backend running on a Hi-DPI device running 10.7 or later. Additional Information: I'm not entirely sure if this is an issue more in the GDK Quartz backend or is something that would be better fixed in Cairo, though poking around in the GDK Quartz backend has certainly been more promising. On the Objective-C side of things, both NSScreen and NSWindow in the later versions of 10.7 have awareness of their own densities, as do Core Graphics contexts. However, the image contexts that Cairo and GDK Quartz create as part of offscreen rendering procedures are not. Apple provides guidelines for this: http://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/HighResolutionOSX.pdf
Corresponding Cairo bug: https://bugs.freedesktop.org/show_bug.cgi?id=69796
(In reply to comment #1) > Corresponding Cairo bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=69796 Worth noting is that the cairo bug above for this problem is currently considered a release blocker for the next stable version, 1.14, according to their bug tracker so might be nice to get some collaboration going between the projects to not block potentially new cairo 1.14 functionality that might be a benefit to Linux users.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new