Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 6cd29fa8c4e7d7e0d7b58cdece6f00ee2614bcc3
https://github.com/WebKit/WebKit/commit/6cd29fa8c4e7d7e0d7b58cdece6f00ee2614bcc3
Author: Carlos Garcia Campos <[email protected]>
Date: 2025-12-17 (Wed, 17 Dec 2025)
Changed paths:
M
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/ThreadedCompositor.cpp
M Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/ThreadedCompositor.h
Log Message:
-----------
[GLIB] Flaky debug crashes due to assertion failure in
ThreadedCompositor::renderLayerTree
https://bugs.webkit.org/show_bug.cgi?id=304204
Reviewed by Nikolas Zimmermann.
Since 303824@main the compositor can be in Scheduled state, but with the
render timer not active, because the only composition request was for a
rendering update and tiles were not ready yet. Other composition requests
are handled while waiting for tiles, when a request is made when
already in Scheduled state and the timer is not active, the timer is
then activated. RunLoopGLib sets the timer as inactive right before
calling the timer callback. It can haoppen that after the timer is set
inactive and before the callback is called or the state lock is acquired
by renderLayerTree the main thread is noitified that the last tile has
been rendered, which calls scheduleUpdateLocked() in a Scheduled state
with the timer inactive, activating the timer again instead of switching
to ScheduledWhileWaitingForRenderer. This causes that we end up
compositing twice in a row in the same frame. This patch uses its own
flag to track if the render timer is active, also protected by the state
lock, to ensure that when renderLayerTree acquires the lock the flags is
still active and state is Scheduled.
Canonical link: https://commits.webkit.org/304581@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
