[Webkit-unassigned] [Bug 195325] Canvas elements not garbage collected immediately in Safari on iOS 12

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=195325

--- Comment #14 from Dean Jackson <dino at apple.com> ---
After a rather lengthy discussion with folks about this, we're down to three options for a "solution":

A. Do nothing - this is expected behaviour [1]. The workaround of setting the canvas size to 0 is probably the best solution.

B. Remove the canvas-specific limit. This would allow pages to create more/bigger canvas elements, although this means they are more likely to hit the overall Web page limit (iOS process limit) at which point the whole page will crash. [2]

C. Implement a different algorithm such as LRU eviction. The canvas that was used least recently would get evicted. A "use" would be any paint or API call (i.e. a canvas visible on the page wouldn't get evicted).

It is too late in the iOS 16 cycle to consider C. Also, there is no way to tell an exiting canvas/context that its backing store has been evicted (WebGL has a way, but 2d contexts do not).

[1] The canvas objects that are set to null may still be referenced from other places, such as their 2d contexts, or possibly internal references such as the stack or JIT tiers. i.e. it's not always easy to determine if they are reachable.

[2] Is it worse for the page to break more often because a canvas didn't get created, or for the entire page to disappear because too many canvases were created? At least the former is recoverable, and has a partial workaround. One could also wait for a bit until GC actually kicks in and then try creating the canvas again.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220622/682cc537/attachment.htm>