Re: Non-goal for HTML: Picture-perfect rendering

> On Tue 4/17/2007 10:28 PM Karl Dubost wrote:
> >Would you consider that the authoring part is irrelevant?
> >I'm not saying it is bad, just looking for use case scenario on how =20
> >it is difficult or not for authors to produce a graphics.

It actually isn't that difficult to create graphics pixel by pixel.
However, generating graphics with lines, shapes, and fills require
lots of code and effort, especially if we want to be able to use the
functionality for creating images in general and not just generating
one specific image or set of images following a general pattern.

There are also lots and lots of different ways to generate "graphics"
in a browser. There's string concatenation building a data: URI of any
chosen graphics format; building tables using string concatenation and
innerHTML; building tables using the DOM; making lines, fills, shapes
using divs and CSS; generating SVG; generating VML; and probably
several I've missed.

They all have various problems. JavaScript performance at string
manipulation and math isn't that great, and lack of true arrays can be
a performance kludge. DOM element based drawing can take up
significant amounts of memory, especially if using a pixel grid where
each pixel is an element. Animating even small DOM based graphics can
be expensive, especially in browsers such as Opera that do layout and
redrawing while script is still executing. Not to mention the fact you
might not want to bloat your documents with loads of elements just to
generate a single image. And of course there's the browser support
differences for technologies like SVG, VML and data: URIs.

Canvas doesn't really do anything we can't do in other ways already,
but it gives us a good API instead of having to build a custom one, it
gives faster graphics manipulation, reduced memory footprint compared
to DOM based drawing, ability for users to save a generated  image,
smaller code size than having to write the API as well as the code
actually generating the images yourself etc. Taken together, those
factors make it easier for authors to generate images and animations.
They may make it worthwhile where otherwise it was not, where
performance, code size, memory size etc. made it prohibitively
expensive before.

On 18/04/07, Dailey, David P. <david.dailey@sru.edu> wrote:
> Here's a use case for how easy (or not) it is to create graphics using JavaScript without either <canvas> or <svg>. Click on the "concatenate" button (in the example) to compare time efficiency of different bitmap-like objects in different browsers.
>
> http://srufaculty.sru.edu/david.dailey/javascript/stringtimer.html
>
> This was actually built to contrast under-the-hood string-concatenation algorithms in the different browsers rather than to make real images, but to make a long story short, creating a 100px x 100px bitmap-like object in Opera, IE and FF takes a maximum of about 700 milliseconds using the fastest of the three algorithms exhibited on a three year old computer.

Nothing you'd like for a Flash-like animation in other words, but
maybe something you could take for one time generation.




As an aside, I did a performance comparison on string concatenation
methods a while ago, using 10 000 random strings (so similar to your
100x100 grid in number of strings to merge), and I found that
performance of string concatenation is very different between the
browsers. In IE I'd even stretch as far as saying anything else than
Array.prototype.join is pathologically bad.

<uri:http://testsuite.liorean.net/stringconcatenationperformance.html>

In this test, IE does only a single iteration instead of one hundred
as the other browsers do, and it still gets similar numbers!

A performance comparison on my 2.2GHz Athlon64, perhaps a bit unfair
to both Opera and Firefox since I had several other programs open (but
idle) when doing those tests:

________________ff2.0_____op9.10_____swift0.2_________ie6w__
String concat   1 063ms      500ms        468ms      1 094ms
Array join      3 657ms      610ms        547ms         47ms*
+ op/vars       1 078ms    1 140ms      8 078ms      1 453ms
+ op/lits           0ms      938ms     10 782ms      1 125ms
+= op           1 484ms    1 110ms      5 984ms      4 625ms

NOTE: ie6w timings are doing ONE iteration,
other browser timings are doing ONE HUNDRED iterations.

* This one I tried with 100 iterations as well. The result then was 515ms.
-- 
David "liorean" Andersson

Received on Wednesday, 18 April 2007 14:55:04 UTC