Codepen demo is slower with gpu-canvas compared to non-gpu-canvas
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
People
(Reporter: mayankleoboy1, Assigned: lsalzman)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
Enable gpu-canvas
Go to https://codepen.io/Mertl/pen/GRdGNJL
Move your mouse inside the demo pane
ER: The demo changes fast in response to the mouse movement
AR: The demo lags quite a bit
Non-GPU Canvas: https://share.firefox.dev/3SZXhFL
GPU canvas: https://share.firefox.dev/3SWYOfG
Reporter | ||
Comment 1•2 years ago
|
||
Reporter | ||
Updated•2 years ago
|
Comment 2•2 years ago
|
||
The gpu-canvas profile is all in the GPU process, looks like texImage uploads, hitting traffic and waiting for previous?
@lsalzman will know more maybe.
Sounds like a case where we just want to bail to software, maybe?
Assignee | ||
Comment 3•1 year ago
|
||
If we have stroked paths whose bounds cover a lot of screen area, that can lead
to a lot of empty area in the interior that bloats the path cache textures up
with unused pixels that still need to be uploaded. Try to avoid this by not
trying to accelerate paths with the path cache that take up a large amount
of screen area.
Updated•1 year ago
|
Pushed by lsalzman@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/77d1e4dcbe67 Limit the size of stroked path uploads. r=aosmond
Comment 5•1 year ago
|
||
bugherder |
Reporter | ||
Comment 6•1 year ago
•
|
||
Profile with latest nightly : https://share.firefox.dev/3TIOHfk
This is much better now. Thanks!
Updated•1 year ago
|
Comment 7•1 year ago
|
||
I was able to reproduce the issue on Mac 10.13 using FF build 108.0a1(20221017213658), image from description moves slow on this version.
Verified as fixed on Win10/Mac10.13/Ubuntu 20.04 using FF build 108.0(20221205155917) and 109.0a1(20221206164509).
Description
•