Branch: refs/heads/webkitglib/2.54
Home: https://github.com/WebKit/WebKit
Commit: 4a295aa70d4fd86c8e821c956f2b53f90ad3a554
https://github.com/WebKit/WebKit/commit/4a295aa70d4fd86c8e821c956f2b53f90ad3a554
Author: Mariyan Borisov <[email protected]>
Date: 2026-10-08 (Thu, 08 Oct 2026)
Changed paths:
M Source/WebKit/UIProcess/gtk/AcceleratedBackingStore.cpp
Log Message:
-----------
Cherry-pick 322671@main (48b35bda44fd).
https://bugs.webkit.org/show_bug.cgi?id=324551
[GTK] Wayland protocol error with DMABUF renderer on NVIDIA: explicit sync
enabled on toplevel surface, then a wl_shm buffer committed without acquire
point
https://bugs.webkit.org/show_bug.cgi?id=324551
Reviewed by Carlos Garcia Campos.
With GTK 3, AcceleratedBackingStore creates its GdkGLContext while painting
the first EGLImage
buffer. GTK 3 decides at the start of a frame whether the window is painted
with GL, so that frame
is still committed from shared memory, but creating the window's first GL
context has already made
GDK create the EGL window surface. NVIDIA's EGL platform sets up explicit
sync on the surface at
that point, and the compositor disconnects the client for committing a
wl_shm buffer without an
acquire point.
Create the GL context in frame() instead, when an EGLImage buffer arrives,
which is between frames,
so GTK starts the frame that paints it with GL.
No new tests: this needs NVIDIA's EGL platform and a compositor with
explicit sync.
* Source/WebKit/UIProcess/gtk/AcceleratedBackingStore.cpp:
(WebKit::AcceleratedBackingStore::frame):
Canonical link: https://commits.webkit.org/322671@main
Canonical link: https://commits.webkit.org/317695.431@webkitglib/2.54
Commit: 8e8521e5877d4ade67e4c2dbb8644ad0ee1edabe
https://github.com/WebKit/WebKit/commit/8e8521e5877d4ade67e4c2dbb8644ad0ee1edabe
Author: Mariyan Borisov <[email protected]>
Date: 2026-10-08 (Thu, 08 Oct 2026)
Changed paths:
M Source/WebKit/UIProcess/gtk/AcceleratedBackingStore.cpp
Log Message:
-----------
Cherry-pick 322670@main (94d5b6e0ae10).
https://bugs.webkit.org/show_bug.cgi?id=326202
[GTK] GTK 3: partial repaints leave areas unpainted when the UI process
uses GBM buffers
https://bugs.webkit.org/show_bug.cgi?id=326202
Reviewed by Carlos Garcia Campos.
For GBM buffers, Buffer::paint() applies the vertical flip before adding
clipRect to the path, so it
fills the mirror image of clipRect. This went unnoticed while the whole
view was redrawn every
frame, but queuePendingDamageDraw() now invalidates only the damaged rects,
so most of each damaged
area stays unpainted when the UI process uses GBM buffers, for example
under X11.
Clip to clipRect in widget coordinates before applying the flip.
* Source/WebKit/UIProcess/gtk/AcceleratedBackingStore.cpp:
(WebKit::AcceleratedBackingStore::Buffer::paint const):
Canonical link: https://commits.webkit.org/322670@main
Canonical link: https://commits.webkit.org/317695.432@webkitglib/2.54
Compare: https://github.com/WebKit/WebKit/compare/ff5834ad00a3...8e8521e5877d
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
