Bug 267291
| Summary: | Umbrella: Using Canvas image sources between different canvases and canvas types is slow | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Kimmo Kinnunen <kkinnunen> |
| Component: | Canvas | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ciprian.grigor, dino, kevmoo, kyle.finlinson+bugzilla, mwyrzykowski, paul.neave, rafi.apollo, simon.fraser, simontaylor1, stillonline, webkit-bug-importer, yegor.jbanov, yura.yaroshevich |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Local Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 234920, 267290, 294602, 301925, 302527, 266215, 297852, 300088, 301914 | ||
| Bug Blocks: | |||
Kimmo Kinnunen
Umbrella: Using Canvas image sources between different canvases and canvas types is slow
- Video
- Offscreen canvas
- WebGL
- 2DContext
- Bitmaprenderer
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/120916864>
Yegor
Here's a couple of repro cases:
Plain JS repro: https://jsfiddle.net/yjbanov/0vurdt42/8/
Flutter Web repro: https://image-bitmap-stress-test.web.app/
Fixing this will help us make Flutter web apps run much smoother in Safari and consume less memory.
Simon Fraser (smfr)
https://jsfiddle.net/yjbanov/0vurdt42/8/ seems fast but https://image-bitmap-stress-test.web.app/ is still slower in Safari than Chrome.
Yegor
This is exciting! We'll kick the tires in the newest Safari. This variant is still drastically slower compared to Chromium-based browsers:
https://jsfiddle.net/6e4dz57v/4/
Yegor
The difference may be in transferToImageBitmap vs createImageBitmap
Yury Yarashevich
I'd like to contribute two additional demos that cover scenarios not currently represented in this ticket:
1. The efficiency of `HTMLCanvasElement.captureStream` implementation: https://github.com/mstyura/webkit-issues/blob/main/video-transform-pipeline/README.md#mirror-4k-canvas-to-video-element-via-htmlcanvaselementcapturestream
2. The efficiency of `VideoTrackGenerator` when produce frames via `new VideoFrame(offscreenCanvas)`: https://github.com/mstyura/webkit-issues/blob/main/video-transform-pipeline/README.md#produce-a-mediastreamtrack-via-videotrackgenerator-from-an-offscreencanvas-rendered-in-a-worker
Simon Taylor
One thing I've noticed in the WebKit source is that I believe any use of IOSurfaces looks to set kIOSurfaceCacheMode to write combined:
https://github.com/WebKit/WebKit/blob/46f0a4c36be821652d1582cbfabe5e51cfee5176/Source/WebCore/platform/graphics/cocoa/IOSurface.mm#L200
This is the default in AVAssetWriter too and in a separate project I discovered reading those buffers on the CPU had a large performance penalty (10x or more).
There's a comment in iOS SDK the IOSurfaceTypes.h header that says this:
/*
** Note: Write-combined memory is optimized for resources that the CPU writes into, but never reads.
** On some implementations, writes may bypass caches, which avoids cache pollution. Read actions may perform very poorly.
** Applications should investigate changing the cache mode only if writing to normally cached buffers is known to cause
** performance issues due to cache pollution, as write-combined memory can have surprising performance pitfalls.
*/
Perhaps worth someone at Apple reviewing the reasoning for setting write combined here and if the benefit is worth the penalty for CPU access.