Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LibWeb+LibGfx: Use GPU backend for <canvas> #1532

Draft
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

kalenikaliaksandr
Copy link
Contributor

This is implemented by using a GPU-accelerated surface for when
a GPU context is available.

A side effect of this change is that all canvas modifications have to be
performed through Gfx::Painter, and whenever its content has to be
accessed, we need to take a snapshot of the corresponding GPU surface.

A new DrawPaintingSurface display list command is introduced to allow
cheap blitting of canvas content without having to read GPU surface
content into RAM.This is a fix to the vcpkg package itself to fix some exported symbols.

This change depends on #1528 so I am marking it as a draft until it's merged.

trflynn89 and others added 4 commits September 26, 2024 17:15
This is a fix to the vcpkg package itself to fix some exported symbols.
This is required to share GPU context creation code between display list
player, which resides in LibWeb, and PainterSkia, which handles <canvas>
painting.
Adds a new class in LibGfx that represents GPU-accelerated surface and
will be used for both <canvas> and page rendering (display list player).
Since the Metal context is currently only used by LibGfx, it could be
moved there to avoid having Metal as a dependency for everything that
uses LibCore.
Since the Vulkan context is currently only used by LibGfx, it could be
moved there to avoid having Vulkan as a dependency for everything that
uses LibCore.
This is implemented by using a GPU-accelerated surface for <canvas> when
a GPU context is available.

A side effect of this change is that all canvas modifications have to be
performed through Gfx::Painter, and whenever its content has to be
accessed, we need to take a snapshot of the corresponding GPU surface.

A new DrawPaintingSurface display list command is introduced to allow
cheap blitting of canvas content without having to read GPU surface
content into RAM.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants