Commit Graph

3 Commits

Author SHA1 Message Date
Matthias Clasen
a1c5a806b3 Convert headers to #pragma once
The conversion was done by guard2one.
2023-03-31 15:11:10 -04:00
Benjamin Otte
4aac0760b3 wayland: Rewrite Cairo rendering
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.
2018-04-24 23:16:58 +02:00
Benjamin Otte
813e9c95fb gdk: Add Cairo context implementations for all backends
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.
2018-04-24 23:16:12 +02:00