- From: liorean <liorean@gmail.com>
- Date: Wed, 18 Apr 2007 16:54:58 +0200
- To: "HTML WG" <public-html@w3.org>
> 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