| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We render the source into a cairo_surface_t so that we can render it
with cairo directly, rather than having to convert it from a pixbuf
every time. We also specify the target window when creating the cairo
surface so that rendering can be faster.
Using cairo surfaces also allows us to seamlessly support window scales.
We also add a GTK_IMAGE_SURFACE source type.
|
|
|
|
|
|
|
|
|
| |
Support 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_surface which renders to a cairo_surface_t
which includes whatever scaling you need for scaled icons.
|
|
|
|
|
|
|
|
| |
This draws an icon from a cairo_surface. 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.
|
|
|
|
|
|
| |
Right now this just uses the pixbuf load code and converts
it to a surface. In the future we could cache the pattern
to allow reusing the surface.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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 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.
|
|
|
|
|
|
|
|
| |
We've long had double precision mouse coordinates on wayland (e.g.
when rotating a window) but with the new scaling we even have it on
X (and, its also in Xinput2), so convert all the internal mouse/device
position getters to use doubles and add new accessors for the
public APIs that take doubles instead of ints.
|
|
|
|
| |
If things are hardcoded in the environment, that wins.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This xsetting can be used to tell Gtk to use a specific window
scaling for the screen.
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
| |
This lets us create image surfaces that render faster on specific windows.
It also supports creating scaled image surfaces.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
We will need this for the window scale support, but its not yet
in a stable cairo release (or even on a master yet), so we make
this optional.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
We create similar windows in the right way to get the
device scale right.
|
|
|
|
|
| |
These report the internal scaling factor, mapping from UI pixels
to hardware pixels.
|
|
|
|
| |
The _gdk_windowing_* stuff is not used anymore
|
|
|
|
| |
The _gdk_windowing_* stuff is not used anymore
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
We need to apply the shape for toplevels that have a shape.
https://bugzilla.gnome.org/show_bug.cgi?id=702831
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This adds a crypt(3) implementation for use with broadwayd as Visual Studio
does not support crypt(3) out of the box.
The public domain implementation is taken from the following URL,
http://michael.dipperstein.com/crypt/, where AFAICT this implementation
would not be subject to licensing restrictions that would prevent it from
being bundled.
|
|
|
|
|
|
|
| |
-Don't include unistd.h unconditionally as it's not available in Visual
Studio, but include io.h where necessary.
-Avoid C99isms, and use _chsize_s in place of ftruncate when unistd.h is
not available (as in the case of Visual Studio)
|
| |
|