SSIA.
Is this planed for near future? Since webkit does not support Webp, OffscreenCanvas is the only performant way to convert such images on a background thread. Not having Offscreen canvas means no Webp (or any other image format not supported y Safari). OffScreen canvas will also enables mapping engines such as Mapbox to render tiles on background threads - significantly speeding up maps. It would be great if Webkit were to implement Offscreen canvas - it will unlock huge potential for the web. Thank you for considering it a priority.
I'm working on updating/finishing Zan's patches.
Just to note that I'm still working on this, and my current work is available on GitHub here: https://github.com/Cwiiis/webkit/tree/offscreen-canvas Many tests are passing and the 2d functionality is fairly complete, but there's still a fair amount of work to tidy it up and start submitting patches for review. I expect some of the choices I've made will need to be inspected and re-thought by people with more knowledge of the code-base.
Finishing OffscreenCanvas support with 2D rendering would be a fantastic addition to WebKit! Thanks for working on it! The WebKit team at Apple would be happy to help and answer any questions you have. We're really looking forward to seeing this happen!
One note of caution: it's going to be very hard for us to verify, via review, that you'd done all the correct locking to make off-main-thread canvas drawing, and all the called code (text, fonts, images etc) thread-safe. Anything you can do to convince us that you got it right will help with review. "I added some locking and it seems to work" won't be entirely convincing :)
(In reply to Simon Fraser (smfr) from comment #5) > One note of caution: it's going to be very hard for us to verify, via > review, that you'd done all the correct locking to make off-main-thread > canvas drawing, and all the called code (text, fonts, images etc) > thread-safe. Anything you can do to convince us that you got it right will > help with review. "I added some locking and it seems to work" won't be > entirely convincing :) This is absolutely fair :) I've been making sure that all tests run in debug mode (there are a *lot* of thread-related asserts), but really I'm not sure how to best fully guarantee this. I'm reasonably confident that it's only the font bits that are worrisome... Do you have any suggestions beyond relying on tests? Assuming we can get to the point where everyone is happy that there aren't any obvious concurrency issues, is this something we could land (perhaps disabled on release by default? What's the best way to go about that?) to increase testing?
I'd like to point out that user gesture requirements equivalent to Chrome's "User Activation v2" are important for some OffscreenCanvas use cases. In our case we can host our entire game engine in a web worker, forwarding input events over postMessage, and posting back for certain DOM APIs not available in workers (e.g. requestFullscreen). If user activation is limited to synchronous callbacks in input events, this blocks the use of any input-restricted APIs (like requestFullscreen), which would block our use of OffscreenCanvas. With User Activation v2, the restrictions are relaxed enough that it keeps working and means we can use OffscreenCanvas. I'm not sure what the status of user gestures are in WebKit but it might be worth reviewing this for OffscreenCanvas.
<rdar://39882956>
Now that bug 224178 has landed, all major OffscreenCanvas features are now implemented, I believe, and enabled on Linux platforms. There's still a fair amount of work to solidify and optimise this implementation, and of course to enable it on all platforms, but the foundations are there. Hurray!
That's great news! Looking forward to being able to do effective off-main-thread rendering via OffscreenCanvas in WebKit!