GitLab

This lets use use a scaled Xft/DPI for old apps while not
blowing up the size of scaled windows. Only apps supporting
Gdk/WindowScaleFactor should supprt Gdk/UnscaledDPI.

The scale-factor property on the widgets will be notified, and the
scale will change on the style property, causing us to pick up
new css assets.

Any native windows need to also change size and position.
We don't change the size of any foreign windows since we
don't generally control these.

This xsetting can be used to tell Gtk to use a specific window
scaling for the screen.

We need to be able to compute different GtkCssImage values
depending on the scale, and we need this at compute time so that
we don't need to read any images other than the scale in used (to
e.g. calculate the image size). GtkStyleProviderPrivate is shared
for all style contexts, so its not right.

This means we draw faster, and automatically handle hidpi icons.

Right now this just uses the pixbuf load code and converts
it to a pattern. In the future we could cache the pattern
to allow reusing the pattern.

Dupport scales when falling back to loading icons from the
icon theme.

In order to actually render scaled icons we add gtk_icon_set_render_icon_pattern
which renders to a cairo_pattern_t which includes whatever scaling you
need for scaled icons.

Carlos Garnacho authored May 10, 2013 and Alexander Larsson committed Jun 28, 2013

An optional OutputScale integer key has been added to index.theme
subdirs description, so icon themes may provide icons that are
more suitable to render at a (typically 2x) integer upscaled
resolution. This way it is possible to make eg. a 16x16@2x icon has a
real size of 32x32, but contains a similar level of detail to the
16x16 icon so things don't look any more cluttered on high-dpi
screens.

The pixbuf lookup has changed so it prefers a minimal scale change
that yields the minimal real size difference, so if looking up for
a 16x16 icon at 2x, it would first prefer 16x16@2x, then 32x32, and
then any other icon that's closest to match

There is now *_for_scale() variants for all GtkIconTheme ways
to directly or indirectly fetch a GdkPixbuf.

This is based on code by Carlos Garnacho with changes by Alexander
Larsson

We render the source into a cairo_patter_t into a pixbuf so that
we can render it directly, rather than having to convert it every
time we render. We also specify the target window when creating
the cairo surface so that rendering can be faster.

This lets us get scaled icons if needed.

This is a hint on where the icon will be drawn. It
will allow us to pre-allocate cairo surfaces for the right
target.

Rather than creating a surface and drawing to it.

This draws an icon from a cairo_pattern. We want to use this more rather
than render_icon as this means we can skip the pixbuf to surface
conversion (including allocation and alpha premultiplication) at
render time, plus we can use create_similar_image which may allow
faster rendering.

This lets us create image surfaces that render faster on specific windows.
It also supports creating scaled image surfaces.

This is very useful for hidpi where the dpi is scaled to make
non-dpi aware apps larger. In that case a dpi aware gtk+ using
GDK_SCALE will be getting huge fonts. You can the set GDK_DPI_SCALE
to compensate for this.

If you set GDK_SCALE=2 in the environment then all windows will be
scaled by 2. Its not an ideal solution as it doesn't handle
multi-monitors at different scales, and only affects gtk apps.
But it is a good starting points and will help a lot on HiDPI
laptops.

We track the list of outputs each window is on, and set the
scale to the largest scale value of the outputs. Any time the scale
changes we also emit a configure event.

This has the new methods required for buffer scaling.

We bind to the newer version of the wl_output which supports
the new done and scale events, and if we use this to get the
scale for each monitor (defaulting to 1 if not supported).

We create similar windows in the right way to get the
device scale right.

If a cairo_surface for a window has a device scale set we need
to respect this when creating a similar window. I.e. we want
to then automatically create a larger window which inherits
the scale from the original.

We also need to calculate a different device_offset if there
is a device_scale set.