Re: correct and incorrect uses of canvas

>-----Original Message----- 
>From: Henri Sivonen
>Sent: Friday, July 15, 2011 8:11 AM
>To: Jonas Sicking
>Cc: Steve Faulkner ; HTMLWG WG ; Frank Olivier ; Richard Schwerdtfeger ;
>Cynthia Shelly ; David Singer ; Tab Atkins Jr. ; Edward O'Connor ; Canvas
>Subject: Re: correct and incorrect uses of canvas
>
>On Thu, 2011-07-14 at 13:40 -0700, Jonas Sicking wrote:
>> We can and should improve the
>> SVG DOM to attract more people, but I suspect there will always be a
>> group of people that choose to use canvas anyway due to better
>> performance or other reasons.
>
>Do you have examples of people choosing <canvas> over SVG for perf
>reasons? Are the perf reasons data-based or merely assumed? Are the perf
>reasons the kind of quality of implementation issues that can be
>considered to be transient and addressed over the next couple of years?

Educated and commonsense (I hope) reasoning:

Each DOM element with associated structures is about 200-5000 bytes in
browser memory (YMMV). Let's consider for example SVG line (x1,y1-x2,y2), 
that will
take 2k of RAM (DOM memory).
In reality you will need around 48 bytes for data structures to represent 
the
line in memory. Usually it is stack allocated data so reusable - takes zero 
memory
between draw calls.

Imagine that your task is to draw 100 lines randomly.

In SVG you will need to create DOM structure that will hold 200k of memory
when you actually don't need all those DOM elements at all.
Just to handle passively those 200k / 100 elements you will need additional
CPU power - memory management, GC, swapping, etc. Without doing anything
good at all. Even for people with disabilities - for them it is enough to 
pronounce
"100 lines replaced randomly" for example.

Value of SVG a11y in this case is zero if not even less - any accessible 
tool
is literally dying on large numbers of DOM elements.

>
>In theory, SVG should be able to outperform <canvas> for painting,
>because the browser engine gets to control how often to repaint, what
>parts to repaint and can avoid intermediate bitmaps when the path
>stroking and filling can be performed nearer hardware and there are
>guaranteed not to be readbacks because the browser knows there aren't
>filters in use.

Actually even in theory it is quite opposite.

Thought experiment:

Let's consider the same 100 lines image with a circle in the middle
(red button/disk on randomly generated background).

To draw it manually using canvas you have various options:
not caching at all, draw background and foreground layers separately
caching layers-bitmaps, etc. Depends on the task. In any case
background lines will not take additional resources in memory.
In SVG list of options is limited by suboptimal (for the task) one .

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

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.

With our custom solution the complexity is O(1)  - we just need
to check if point is inside the circle.

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

Yes, SVG has DOM. But that does not mean it has reasonable a11y value -
any given SVG element have significantly less semantics in it than
any HTML one.

I believe that decision to make SVG DOM to be a part of HTML DOM is
conceptually wrong - too different things. Crossing hedgehog and a snake
will give you piece of barbed wire but not an animal.

I also think that <canvas> as a dedicated DOM element is also a bad idea
- no semantic and a11y values indeed.

In my opinion SVG should not be different from PNG, GIF, EMF and other
image formats - SVG images should be used as backgrounds or <img src=".svg">

Instead of <canvas> we just need mechanism that allows to synthesize
images on client side (Image.getGraphics())  and use them as any other
image in HTML/CSS - in CSS and in <img>.

In this case developers will be forced to use HTML elements with proper 
semantic.
And so the scene with random lines and button above will be defined as:

<div style="background: url(in-memory:100-random-lines)">
   <button id="ignition" class="big-red-button"></button>
</div>


-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Saturday, 16 July 2011 17:43:14 UTC