[Webkit-unassigned] [Bug 278452] [GTK][WPE][Skia] REGRESSION(282012 at main) Crash using threaded rendering

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Aug 21 02:16:30 PDT 2024


https://bugs.webkit.org/show_bug.cgi?id=278452

--- Comment #1 from Miguel Gomez <magomez at igalia.com> ---
What we're doing in both GTK and WPE is recording the commands needed to render the GraphicsLayer contents on the main thread, and then replaying them in some secondary renderer threads.

The code that does this is CoordinatedGraphicsLayer::paintTile() in CoordinatedGraphicsLayerSkia.cpp. We're creating the recording context with

auto recordingContext = makeUnique<DisplayList::DrawingContext>(tileRect.size());

And then moving that recordingContext to the renderer thread and replaying it with

recordingContext->replayDisplayList(context);


I think the problem is that non Apple platforms were always receiving nullptr when trying to get a ControlFactory, but they are now receiving the new EmptyControlFactory. But EmptyControlFactory is not a thread safe object and it's intended to be used on the main thread only, and I'm seeing calls to ControlFactory::shared() that are happening inside the rendering threads (in the Replayer constructor).

Probably just forcing GTK and WPE to return nullptr when trying to get ControlFactory would fix our problem, but I'd like to try to understand how is the feature intended to work before doing any change.

So I'm not sure what's exactly the problem here:
- Isn't DisplayList replay in threads not supported? The current implementation with the new EmptyControlFactory seems to suggest so.
- Maybe in order to replay in threads we need to use a RemoteDisplayListRecorder, which don't use the shared ControlFactory, but a new one?
- Is replaying in threads supported but this is a bug in how ControlFactory is handled? Can't ControlFactory be made thread safe? Is there any platform limitation for this?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240821/61819f6b/attachment.htm>


More information about the webkit-unassigned mailing list