Re: correct and incorrect uses of canvas

>-----Original Message----- 
>From: Kornel Lesinski Sent: Saturday, July 16, 2011 4:15 PM To: Andrew 
>Fedoniouk Subject: Re: correct and incorrect uses of canvas
>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.

Random lines means lines with random color and random location.
Think about starry sky or something like this.

SVG paths will not help you too much here.

>
>> 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.

Here is practical example:
http://i1-win.softpedia-static.com/screenshots/Norton-Internet-Security_38.png

Note the map there. It is implemented using two layers (Images) on canvas:
one is "pixelated"  map where each dot is a circle in fact. This layer is 
static.
Another layer is dynamic - data are coming in real time.
To redraw this scene you will need to BitBlt static layer + draw dynamic 
data
on top of it.
SVG estimation for this kind of image is about 40mb in memory. That is too 
much
for such widget and application in the whole. And again without any good for
a11y purposes.

It is quite optimistic to assume that such cases will be rare on the Web
and developers will not try to optimize such cases.

>
>> 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.

I wouldn't rely on implementation of "sophisticated collision algorithms in 
SVG"
as even in single cases UAs behave significantly different.

Here is an example:
http://terrainformatica.com/w3/grid-fixed-10000.htm
try to move mouse over the table. GC shows 100% CPU core load and FF behaves
significantly better. In such regular layouts you can use at least binary 
search
that will give you O(log(n)) complexity. Seems like GC don't bother itself 
by
such optimizations - linear search at it's best. I expect that SVG will work 
there
that way too (cannot test as GC seems does not support :hover in SVG).
Test case: http://www.terrainformatica.com/w3/flower.svg

BTW: on this test browsers behave as if each DOM element (~14000 of them
there) takes around 5k each.

>
>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.
>

My points are simple:

1. there are few tasks where SVG is better and there are task where
    <canvas> is significantly more optimal.
2. A11y of SVG is rather theoretical than practical - it is too low level 
for
   that.
3. Neither <canvas> nor <svg> have acceptable a11y value. <svg> and Graphics
   shall be used only as images in CSS or content of <img>.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Sunday, 17 July 2011 02:28:22 UTC