When pressing e.g. a window manager shortcut, which acquires keyboard grab,
Xorg would send FocusOut NotifyGrab then FocusIn NotifyUngrab. Currently
gdk would then deactivate the current surface, which makes accessibility
screen readers think that we have switched to a non-accessible application
and came back again, and thus reannounce the application frame etc. which we
don't want when e.g. just raising volume.
And actually, receiving FocusOut NotifyGrab does not mean losing the
X focus, it only means an application aqcuired a grab, i.e. it is
temporarily stealing keyboard events. On Wayland, this isn't even
notified actually.
This commit makes gdk only deactivate surfaces when there was an actual
focus switch to another window, as determined by has_focus_window (instead
of just has_focus), which happens either normally through FocusOut with
NotifyNormal, or during grabs through FocusOut with NotifyWhileGrabbed.
Fixes#85
gdk_win32_keymap_check_compose() shouldn't be called for
non-W32 displays (i.e. when using broadway or other backends
that could be made to run on Windows).
to retreive paper size specific hard margins and use this
to set the hard margins in the print context.
(modified by Marek Kasik <mkasik@redhat.com>)
https://bugzilla.gnome.org/show_bug.cgi?id=686109
gtk_get_current_event() returns a new reference to the event, it should
be freed across various return branches to avoid the event leak, or we
just fetch the little stuff we're interested in.
Now that all Cairo contexts are ported to managing cairo surfaces
themselves, the old fallback code that didi the managing is no longer
needed.
Also clarify the behavior of gdk_cairo_context_cairo_create() wrt the
vfunc by doing the early exit and the clipping outside of it.
* Remove DC refcounting (we trust GDK to always do
begin_frame/end_frame calls in pairs)
* Now that there's no GDK-provided double-buffer up the stack,
double-buffering is implemented here
(though it's disabled by default - in my tests it didn't provide
any visual improvements, but did decrease performance).
* For some reason delaying window resizes until the point where
we need to blit the double-buffer into the window leads
to visual glitches, so doulbe-buffered windows are resized
in begin_frame, same as non-double-buffered ones.
* New code to clear the paint region, for all drawing modes.
Hopefully, it isn't duplicated anywhere up the stack.
* GL has its own context now, so remove any GL-related comments.
* Layered windows are still used (because cairo actually works
better with them)
* A bit more code re-use for layered windows
* Some functions that were local to gdksurface-win32.c are made
usable for the whole backend
* Drag-indicator drawing is temporarily commented out to match
a similar change in X11 backend
We used to pass 2 regions to GdkDrawCotnext.end_frame() but code was
confusing what they meant. So we now don't do that anymore and only pass
the region that matters: The frame region.
This makes the previous gdk_draw_context_is_drawing() function public
under a new name.
I decided against the old name because we use the term "frame" for a
drawing operation, so I wanted to have this boolean flag reuse the term.
As they require a draw context and the draw context is already bound to
the surface, it makes much more sense and reduces abiguity by moving
these APIs to the draw context.
As a side effect, we simplify GdkSurface APIs to a point where
GdkSurface now does not concern itself with drawing anymore at all,
apart from being the object that creates draw contexts.
Previously, we got the damage, then computed the changed area, then
started a frame with that changed area.
But starting a frame computes the damage for us.
So now we start a frame, then get the damage area from that, then
compute the change area.
Also, split it into its own file - which was the original reason for
looking at this code, the rewrite was an unintentional side effect.
This changes the context to create surfaces on demand.
So whenever the compositor holds onto a surface while GDK wants to
render, it just creates a new surface. If the compositor releases
surfaces, we will retain one for the next frame to be rendered, but free
all extra ones.
This way, we should get to a stage where we have exactly as many
surfaces as needed and never allocate/free any.
Also, don't implement SurfaceClass.ref_cairo_surface() anymore. This
means calls to it will crash now. But as they only happen in the generic
GdkCairoContext implementation, we shouldn't be affected by that.
Plus, once all backends have been ported, that call is going away
anyway.
And make the GdkCairoContext as abstract.
The idea of this and thje following commits is to get rid of all
Cairo code in gdksurface.c (and $backend/gdksurface-$backend.c)
by moving that code into the Cairo context files.
In particular, the GdkSurfaceClass.begin_frame/end_frame()
functions (which are currently exclusively used by the Cairo code
should end up being moved to GdkDrawContextClass.begin/end_frame().
This has multiple benefits:
1. It unifies code between the different drawing contexts.
GL lives in GLContext, Vulkan in VulkanContext and Cairo in
CairoContext. In turn, this makes it way easier to reason about
what's going on in surface-specific code. Currently pretty much
all backends do things wrong when they want to sync to drawing
or to the frame clock.
2. It makes the API of GdkSurface smaller. No drawing code (apart
from creating the contexts) needs to remain.
3. It confines Cairo to the Drawcontext, thereby making it way
more obvious when backends are still using it in situations
where it may now conflict with OpenGL (like when doing the dnd
failed animation or in the APIs that I'm removing in this
branch).
4. We have 2 very different types of Cairo contexts: The X/win32
model, where we have a natively supported Cairo backend but do
double buffering ourselves and use similar surfaces and the
Wayland/Broadway model where we use image surfaces without any
Cairo backend support and have to submit the buffers manually.
By not sharing code between those 2 versions, we can make the
actual code way smaller. We also get around the need to create
1x1 image surfaces in the Wayland backend where we pretend
there's a native Cairo surface.
This does nothing but disallow passing NULL to gdk_surface_begin_paint()
and instead require this context.
The ultimate goal is to split out Cairo drawing into its own source file
so it doesn't clutter up the generic rendering path.
