W3C home > Mailing lists > Public > public-html@w3.org > July 2011

Re: correct and incorrect uses of canvas

From: Kornel Lesiński <kornel@geekhood.net>
Date: Sun, 17 Jul 2011 00:20:57 +0100
To: "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.vyqi47s0te2ec8@aimac.local>
On Sat, 16 Jul 2011 18:42:42 +0100, Andrew Fedoniouk
<andrew.fedoniouk@live.com> wrote:

> Let's consider for example SVG line (x1,y1-x2,y2), that will
> take 2k of RAM (DOM memory).

SVG has a pretty efficient way of representing paths, so not all lines
have to be DOM nodes.

> Software engineering lemma: any generic solution is less
> optimal than ad hoc solution optimized for solving particular task.

On the web you can't assume that most ad-hoc solutions will be optimized.
Animation by clearing and complete redrawing is common. I haven't seen
more sophisticated solutions than a single dirty rectangle + caching of
whole background as a bitmap, and such optimisations could be done by
browsers in SVG.

> Consider the task of handling mouse click event on the scene above -
> to find click on the "button".
>
> In SVG you will need to check 101 elements - complexity is O(n)
> in general.

DOM enables use of more sophisticated collision algorithms in SVG, so this
might be closer to O(log(n)) for most documents. Browsers already do
hit-testing in HTML DOM on every mouse move (for :hover) and generally
don't seem to have problem with that.

OTOH I wouldn't expect typical page author to bother with anything complex
for this, so I think your 1-button example is more like n=1 case of O(n).

>> So in theory, if SVG has performance issues, they should be attributable
>> to the DOM. If a sub-DOM is used for accessibility in the <canvas> case,
>> then the <canvas> case has a DOM, too.
>
> SVG has performance issues by its generic nature.

Assuming that browsers aren't able to take advantage of SVGs declarative
nature and native implementation to their advantage (e.g. cache rendered
parts of DOM that doesn't change, GPU-accelerate animations, avoid cost of
reading rendered pixels back from the GPU).

In cases where scene graph is needed, a <canvas> solution won't
necessarily be better performing — authors might just roll their own
SVG-like solution or use a library (e.g. fabric.js) that gives up
possibility of very specific optimisations and has to work with scene
graph in a high-level language and has no direct control over the GPU.

-- 
regards, Kornel Lesiński
Received on Saturday, 16 July 2011 23:21:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:26 UTC