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
Big drop in canvas performance above 3840px #18080
Big drop in canvas performance above 3840px #18080
Conversation
EWS run on previous version of this PR (hash c0fde81) |
c0fde81
to
28c6985
Compare
EWS run on previous version of this PR (hash 28c6985) |
28c6985
to
1a56d1f
Compare
EWS run on previous version of this PR (hash 1a56d1f) |
1a56d1f
to
56ee661
Compare
EWS run on previous version of this PR (hash 56ee661) |
56ee661
to
88ea72a
Compare
EWS run on previous version of this PR (hash 88ea72a) |
88ea72a
to
97dc78e
Compare
EWS run on previous version of this PR (hash 97dc78e) |
97dc78e
to
42f06ac
Compare
EWS run on previous version of this PR (hash 42f06ac) |
42f06ac
to
0a563c7
Compare
EWS run on previous version of this PR (hash 0a563c7) |
0a563c7
to
5d63817
Compare
EWS run on previous version of this PR (hash 5d63817) |
5d63817
to
c87002e
Compare
EWS run on current version of this PR (hash c87002e) |
https://bugs.webkit.org/show_bug.cgi?id=236173 rdar://88536159 Reviewed by Simon Fraser. Limiting the accelerted canvas 2d context to arbitrary 5120*2880 is not useful. The performance difference gets more beneficial to hardware rasterization the higher the resolution. The limit did not protect against hitting hardware rasterization limits, since the limits are always per dimension, not per area. As per above, capping based on any upper limit is not useful. Thus remove the upper limit. Reuse the unused lower limit as the trigger. The lower limit is justified, as very small areas might be useful to rasterize with CPU. Start the limit at 0, to match the previous behavior. The hardware acceleration limits are checked in the respective ImageBufferBackends, e.g. ImageBufferIOSurfaceBackend::calculateSafeSize. This is done in WP for both GPUP mode and in-process mode. Both will fall back to Unaccelerated. Changes the RemoteRenderingBackend::createImageBuffer() to use buffer options instead of rendering mode. The the buffer options may be honored, but rendering mode would imply that it must be honored. Later on when the rendering mode is more policy based on rendering purpose, this is more clear. * LayoutTests/compositing/canvas/accelerated-canvas-compositing-size-limit-expected.txt: * LayoutTests/compositing/canvas/accelerated-canvas-compositing-size-limit.html: * LayoutTests/compositing/canvas/accelerated-small-canvas-compositing-expected.txt: Removed. * LayoutTests/compositing/canvas/accelerated-small-canvas-compositing.html: Removed. * LayoutTests/fast/canvas/image-buffer-backend-variants-expected.txt: * LayoutTests/platform/ios/compositing/canvas/accelerated-canvas-compositing-size-limit-expected.txt: Removed. * LayoutTests/platform/ios/fast/canvas/image-buffer-backend-variants-expected.txt: * LayoutTests/platform/mac-wk1/compositing/canvas/accelerated-canvas-compositing-size-limit-expected.txt: Added. * LayoutTests/platform/mac-wk1/fast/canvas/image-buffer-backend-variants-expected.txt: * LayoutTests/platform/mac-wk2/TestExpectations: * LayoutTests/platform/mac-wk2/compositing/canvas/accelerated-canvas-compositing-size-limit-expected.txt: Removed. * LayoutTests/platform/wincairo/TestExpectations: * Source/WebCore/html/CanvasBase.cpp: (WebCore::CanvasBase::shouldAccelerate const): (WebCore::CanvasBase::allocateImageBuffer const): * Source/WebCore/html/CanvasBase.h: * Source/WebCore/page/Settings.yaml: Canonical link: https://commits.webkit.org/268440@main
c87002e
to
45446c5
Compare
Committed 268440@main (45446c5): https://commits.webkit.org/268440@main Reviewed commits have been landed. Closing PR #18080 and removing active labels. |
45446c5
c87002e