GitLab

XSetWindowBackgroundPixmap() will throw BadMatch only in the case of a
different parent window depth. Different visuals are fine and actually
expected in Gtk+ 3.16 (since we don't stick to the system default visual
but try to pick a better one).

https://bugzilla.gnome.org/show_bug.cgi?id=747524

There was a leftover HAVE_CAIRO_SURFACE_SET_DEVICE_SCALE ifdef
that broke things, now that we don't use this define anymore.

This is required for the X backend GL integration. If the
window has a height that is not a multiple of the window scale
we can't properly do the y coordinate flipping that GL needs.
Other backends can ignore this and use the default implementation.

https://bugzilla.gnome.org/show_bug.cgi?id=739750

Rather than just rounding down the position *and* the size separately
we correctly calculate a rectangle in scaled window coords that fully
covers the real window size. This really only makes a difference
when the window size/position isn't a multiple of the window scale.

https://bugzilla.gnome.org/show_bug.cgi?id=739750

Keep track of the exact size of X windows in underlying pixels; we
generally use the scaled size instead, but to properly handle the GL
viewport for windows that aren't a multiple of window_scale,
we need to know the real size.

https://bugzilla.gnome.org/show_bug.cgi?id=739750

This is needed for cairo_set_device_scale()

These are the last two global GDK symbols that have a libgtk_only
suffix.

https://bugzilla.gnome.org/show_bug.cgi?id=739781

Commit afd9709a made us keep impl window
cairo surfaces around across changes of window scale. But the
window scale setter forgot to update the size and scale of the
surface. The effect of this was that toggling the window scale
from 1 to 2 in the inspector was not causing the window to draw
at twice the size, although the X window was made twice as big,
and input was scaled too. Fix this by updating the surface when
the window scale changes.

We used to have a weak ref to the cairo surface and it was keep
alive by the references in the normal windows, but that reference
was removed by d48adf9c, causing
us to constantly create and destroy the surface.

https://bugzilla.gnome.org/show_bug.cgi?id=738648

We always want to send the position in device pixels,
so apply the window scale before sending them out.

https://bugzilla.gnome.org/show_bug.cgi?id=738955

This adds the new type GdkGLContext that wraps an OpenGL context for a
particular native window. It also adds support for the gdk paint
machinery to use OpenGL to draw everything. As soon as anyone creates
a GL context for a native window we create a "paint context" for that
GdkWindow and switch to using GL for painting it.

This commit contains only an implementation for X11 (using GLX).

The way painting works is that all client gl contexts draw into
offscreen buffers rather than directly to the back buffer, and the
way something gets onto the window is by using gdk_cairo_draw_from_gl()
to draw part of that buffer onto the draw cairo context.

As a fallback (if we're doing redirected drawing or some effect like a
cairo_push_group()) we read back the gl buffer into memory and composite
using cairo. This means that GL rendering works in all cases, including
rendering to a PDF. However, this is not particularly fast.

In the *typical* case, where we're drawing directly to the window in
the regular paint loop we hit the fast path. The fast path uses opengl
to draw the buffer to the window back buffer, either by blitting or
texturing. Then we track the region that was drawn, and when the draw
ends we paint the normal cairo surface to the window (using
texture-from-pixmap in the X11 case, or texture from cairo image
otherwise) in the regions where there is no gl painted.

There are some complexities wrt layering of gl and cairo areas though:
* We track via gdk_window_mark_paint_from_clip() whenever gtk is
  painting over a region we previously rendered with opengl
  (flushed_region). This area (needs_blend_region) is blended
  rather than copied at the end of the frame.
* If we're drawing a gl texture with alpha we first copy the current
  cairo_surface inside the target region to the back buffer before
  we blend over it.

These two operations allow us full stacking of transparent gl and cairo
regions.

Before 5e325c4, the default BitGravity was NorthWestGravity.
When static gravities were removed in 5e325c4, the BitGravity regressed
to the X11 default, Forget. Forget causes giant graphical glitches and
black flashes when resizing, especially in some environments that aren't
synchronized to a paint clock yet, like XWayland.

I'm assuming that the author assumed that the default of BitGravity was
NorthWestGravity, which is the default of WinGravity. Just go ahead and
fix this regression to make resizing look smooth again.

... and remove all implementations. The API allows to not work "if the
server doesn't support it. So from now on, no server does!

window->parent must exist, it's dereferenced a few lines below.

Avoids clang complaints.

It triggers coverity warnings.

Remove checks for NULL before g_free() and g_clear_object().
Merge check for NULL, freeing of pointer and its setting
to NULL by g_clear_pointer().

https://bugzilla.gnome.org/show_bug.cgi?id=733157

The warning may have had some value at some point, but if
people uninstall large icons just to make the warning go
away, it does more harm than good. So just remove it.

Since we know what size was too large here, why not say it.

As pointed out in https://bugzilla.gnome.org/show_bug.cgi?id=710449,
XChangeProperty expects data to be a long array for format 32.

As a quick code cleanup.

Traditionally, the way painting was done in GTK+ was with the
"expose-event" handler, where you'd use GDK methods to do drawing on
your surface. In GTK+ 2.24, we added cairo support with gdk_cairo_create,
so you could paint your graphics with cairo.

Since then, we've added client-side windows, double buffering, the paint
clock, and various other enhancements, and the modern way to do drawing
is to connect to the "draw" signal on GtkWidget, which hands you a
cairo_t. To do double-buffering, the cairo_t we hand you is actually on
a secret surface, not the actual backing store of the window, and when
the draw handler completes we blit it into the main backing store
atomically.

The code to do this is with the APIs gdk_window_begin_paint_region,
which creates the temporary surface, and gdk_window_end_paint which
blits it back into the backing store. GTK+'s implementation of the
"draw" signal uses these APIs.

We've always sort-of supported people calling gdk_cairo_create
"outside" of a begin_paint / end_paint like old times, but then you're
not getting the benefit of double-buffering, and it's harder for GDK to
optimize.

Additionally, newer backends like Mir and Wayland can't actually support
this model, since they're based on double-buffering and swapping buffers
at various points in time. If we hand you a random cairo_t, we have no
idea when is a good time to swap.

Remove support for this.

This is technically a GDK API break: a warning is added in cases where
gdk_cairo_create is called outside of a paint cycle, and the returned
surface is a dummy that won't ever be composited back onto the main
surface. Testing with complex applications like Ardour didn't produce
any warnings.

Otherwise, the WM cannot take a grab on the pointer device, since we'll
still have the implicit grab.

We accept these now.

This avoids a bunch of policy problems with deciding how to lay
out the window menu under different WMs.

For now, we use the special event _GTK_SHOW_WINDOW_MENU, but we
hope to have this standardized in wm-spec quite soon, as KDE wants
it as well.

This lets us unmaximize a half-tiled csd window on a touch system.

It seems that some backends implemented get_root_origin wrong
and returned the client window coordinates, not the frame window
coordinates. Since it's possible to implement generically for all
windows, let's do that instead of having a separate impl vfunc.

And the counterpart to unmaximize when dragging a maximized window, if
touch devices aren't going to use EWMH moveresize, having this one at least
makes things feel a bit less awkward.

https://bugzilla.gnome.org/show_bug.cgi?id=709914

Sadly, EWMH moveresize mechanism can't work with touch devices for two
reasons:

1) As a mutter implementation detail, the device is queried in order
to check whether the dragging button is still pressed. Touch devices
won't report the button 1 being pressed through pointer emulation.
2) Even bypassing that check, on X11 touch events are selected prior
to sequences being started, either through XISelectEvents or
XIGrabTouchBegin, no late registering through active grabs is allowed,
as WMs do on reaction to EWMH moveresize messages.

So for the time being, make touch devices fallback on emulated window
dragging, which at least allows for moving windows.

https://bugzilla.gnome.org/show_bug.cgi?id=709914

It's unused by callers, and the historical return values are
undocumented, so just remove it now.

Instead of destroying the surface in the backend if this is
unable to resize, let the core code do it, and do it properly.

Based on a patch by Benjamin Otte.

https://bugzilla.gnome.org/show_bug.cgi?id=725172

Instead of Return value:

Reported in https://bugzilla.gnome.org/show_bug.cgi?id=724008
Author:    Ting-Wei Lan <lantw44@gmail.com>

https://wiki.gnome.org/Design/OS/Typography