Commit Graph

10 Commits

Author SHA1 Message Date
Chun-wei Fan
7b47e3225b GDK/Win32: Remove layered windows usage
In GTK4, we are now defaulting to the OpenGL renderer with the Cairo renderer
only used as a fallback, so there is no point keeping the code paths that use
layered windows as layered windows do not work well with OpenGL nor Vulkan.
2021-01-18 12:48:16 +08:00
Chun-wei Fan
46a8a3fe31 gdk[cairo|gl]context-win32.c: Use gdk_win32_surface_handle_queued_move_resize()
Use the shared function that was added in the previous commit, to simplify
things.

Also make gdk_win32_surface_get_queued_window_rect() and
gdk_win32_surface_apply_queued_move_resize() back into static functions, since
they are now used only by the code in gdksurface-win32.c
2020-08-05 16:23:14 +08:00
Chun-wei Fan
69bb4f8beb GDK-Win32: Move some functions around
Move gdk_win32_surface_get_queued_window_rect() and
gdk_win32_surface_apply_queued_move_resize() to gdksurface-win32.c, since these
functions are not only used for Cairo draw contexts, but is also used for GL
draw contexts, and will be used for Vulkan draw contexts.
2020-08-05 15:38:08 +08:00
Benjamin Otte
d7266b25ba Replace "gint" with "int" 2020-07-25 00:47:36 +02:00
Matthias Clasen
09ec88d0ce win32: Build fixes 2019-05-28 20:25:15 +00:00
Chun-wei Fan
3a56da60dd gdk/win32/gdkcairocontext-win32.c: Make functions shared in backend
Make gdk_win32_surface_get_queued_window_rect() and
gdk_win32_surface_apply_queued_move_resize() not static functions, as we
want to use them in gdkglcontext-win32.c, to fix resizing and moving.
2019-04-01 14:51:13 +08:00
Руслан Ижбулатов
aaa4e23a77 Fix gdk_win32_cairo_context_end_frame prototype 2018-06-10 21:21:02 +00:00
Руслан Ижбулатов
58fc1229c1 Remove unused variables (mostly in W32 code) 2018-06-10 21:21:01 +00:00
Руслан Ижбулатов
7002f08cc1 GDK W32: Switch to GdkCairoContext
* 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
2018-04-24 23:24:55 +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