Comments on: SVG Using Nothin’ But JavaScript http://www.codedread.com/blog/archives/2006/02/05/svg-using-nothin-but-javascript/ Sun, 07 Mar 2010 07:18:03 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Groups http://www.codedread.com/blog/archives/2006/02/05/svg-using-nothin-but-javascript/comment-page-1/#comment-373 Groups Thu, 23 Aug 2007 00:46:49 +0000 http://blog.codedread.com/?p=221#comment-373 The JavaScript drawing library is basically a worst-case scenario - it’s a fallback for all browsers that have no better method. The JavaScript drawing library is basically a worst-case scenario – it’s a fallback for all browsers that have no better method.

]]> By: Kae Verens http://www.codedread.com/blog/archives/2006/02/05/svg-using-nothin-but-javascript/comment-page-1/#comment-372 Kae Verens Sun, 12 Feb 2006 14:21:26 +0000 http://blog.codedread.com/?p=221#comment-372 Paul - true. However, I originally wrote the thing with only simple cases in mind - icons, and small logos, for example. If the client is in the business of printing out images, then they should really be using proper plugins anyway. I believe the script to be an acceptable alternative for simple SVG cases. In fact, the original case I had in mind is probably ideal - in that case, I wanted to be able to load a toolbar full of icons with just one or two http requests. SVG was a solution to that problem, but I needed to ensure that non-SVG browsers could read the icons as well; hence the script. I was really not considering larger cases at all. Paul – true.

However, I originally wrote the thing with only simple cases in mind – icons, and small logos, for example. If the client is in the business of printing out images, then they should really be using proper plugins anyway.

I believe the script to be an acceptable alternative for simple SVG cases. In fact, the original case I had in mind is probably ideal – in that case, I wanted to be able to load a toolbar full of icons with just one or two http requests. SVG was a solution to that problem, but I needed to ensure that non-SVG browsers could read the icons as well; hence the script.

I was really not considering larger cases at all.

]]> By: Paul http://www.codedread.com/blog/archives/2006/02/05/svg-using-nothin-but-javascript/comment-page-1/#comment-371 Paul Sun, 12 Feb 2006 10:45:09 +0000 http://blog.codedread.com/?p=221#comment-371 Hi Kae, legitimate claim, my comment doesn't come across vividly at all;-) Let me give you an example that will make things clear. Supposed case: you've to draw a couple of circles. In Firefox these circles will get rasterized/more or less antialiased to a bitmap. It doesn't make any difference how many circles are drawn using native svg or your library, the bitmap is one gdi object. It's a different story in internet explorer. If I get you right, the circles will get tessellated to a number of separate rectangular div elements? More precisely, if you strive for an acceptable (print:-) image of these circles, you've to consider antialiasing as well- and you'll end up with a vast amount of different colored divs. Each div will chew up a gdi object for display and printout. I've got no idea how many div objects a decent representation of an ordinary svg file will require. I dunno. On the other hand I do know that you cannot expect a determinable upper limit at the time of rendering at the client's system. For instance, a '3000 div' svg instantiation (OMG, bloated dom) at the clients system probably won't be printable anymore. The background printing thread would require another 3000 gdi objects as well. Well, you plan to employ ie's vector graphics behaviour for your ie rendering. That's another story... Hi Kae,
legitimate claim, my comment doesn’t come across vividly at all;-)
Let me give you an example that will make things clear. Supposed case: you’ve to draw a couple of circles.
In Firefox these circles will get rasterized/more or less antialiased to a bitmap. It doesn’t make any difference how many circles are drawn using native svg or your library, the bitmap is one gdi object.
It’s a different story in internet explorer. If I get you right, the circles will get tessellated to a number of separate rectangular div elements? More precisely, if you strive for an acceptable (print:-) image of these circles, you’ve to consider antialiasing as well- and you’ll end up with a vast amount of different colored divs. Each div will chew up a gdi object for display and printout.
I’ve got no idea how many div objects a decent representation of an ordinary svg file will require. I dunno. On the other hand I do know that you cannot expect a determinable upper limit at the time of rendering at the client’s system. For instance, a ‘3000 div’ svg instantiation (OMG, bloated dom) at the clients system probably won’t be printable anymore. The background printing thread would require another 3000 gdi objects as well.
Well, you plan to employ ie’s vector graphics behaviour for your ie rendering.
That’s another story…

]]> By: Kae Verens http://www.codedread.com/blog/archives/2006/02/05/svg-using-nothin-but-javascript/comment-page-1/#comment-370 Kae Verens Thu, 09 Feb 2006 09:17:13 +0000 http://blog.codedread.com/?p=221#comment-370 Paul, I'm not sure if I understood anything you just said there... The renderer that I'm using at the moment is a "fast" (for javascript values of "fast") graphics library that renders using as few resources as possible. If you check out Walter Zorn's library (http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm), you'll see he has optimised it quite well. It's not like I'm rendering every pixel one at a time! Besides - now that I have it working basically in every browser that I have a copy of (that can handle JavaScript, of course), I'll be optimising on a per-browser basis. For example, in IE, I will adapt the code so that it draws using Emil E Eklund's canvas implementation (http://me.eae.net/archive/2005/12/29/canvas-in-ie/). This should help reduce the resources worry that you have. The JavaScript drawing library is basically a worst-case scenario - it's a fallback for all browsers that have no better method. Paul, I’m not sure if I understood anything you just said there… The renderer that I’m using at the moment is a “fast” (for javascript values of “fast”) graphics library that renders using as few resources as possible. If you check out Walter Zorn’s library (http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm), you’ll see he has optimised it quite well.

It’s not like I’m rendering every pixel one at a time!

Besides – now that I have it working basically in every browser that I have a copy of (that can handle JavaScript, of course), I’ll be optimising on a per-browser basis. For example, in IE, I will adapt the code so that it draws using Emil E Eklund’s canvas implementation (http://me.eae.net/archive/2005/12/29/canvas-in-ie/). This should help reduce the resources worry that you have.

The JavaScript drawing library is basically a worst-case scenario – it’s a fallback for all browsers that have no better method.

]]> By: Paul http://www.codedread.com/blog/archives/2006/02/05/svg-using-nothin-but-javascript/comment-page-1/#comment-369 Paul Wed, 08 Feb 2006 11:36:34 +0000 http://blog.codedread.com/?p=221#comment-369 What a fantastic idea??? Hi Jeff, this idea is wrong in many ways. Conceptual, practicability, resources consumption, performance, consequences, … Regarding windows clients we’ve to recognize that there are browsers out there implementing rasterizing renderers- and gdi (graphics device interface) rendering on the other hand. There are pros and cons for each of the implementation decision. No matter for discussion here. Most foolish procedure is to implement a rasterizer (or mosaicer?) with individual gdi objects (other than a bitmap:-). Gdi objects are precious resources and depending on the available memory. For Windows there are per process and per session upper limits. E.g. for a Win2k System there’s a limit of max 2^14 gdi handles per session. I.e. you can’t expect more than a few thousand individual fragments for this kind of tessellated vector display in an IE window. Finally a lousy maximum image resolution for the entire scalable vector overhead involved here? What a fantastic idea???

Hi Jeff,
this idea is wrong in many ways. Conceptual, practicability, resources consumption, performance, consequences, …

Regarding windows clients we’ve to recognize that there are browsers out there implementing rasterizing renderers- and gdi (graphics device interface) rendering on the other hand. There are pros and cons for each of the implementation decision. No matter for discussion here.
Most foolish procedure is to implement a rasterizer (or mosaicer?) with individual gdi objects (other than a bitmap:-). Gdi objects are precious resources and depending on the available memory. For Windows there are per process and per session upper limits. E.g. for a Win2k System there’s a limit of max 2^14 gdi handles per session. I.e. you can’t expect more than a few thousand individual fragments for this kind of tessellated vector display in an IE window. Finally a lousy maximum image resolution for the entire scalable vector overhead involved here?

]]> By: Kae Verens http://www.codedread.com/blog/archives/2006/02/05/svg-using-nothin-but-javascript/comment-page-1/#comment-368 Kae Verens Mon, 06 Feb 2006 14:24:21 +0000 http://blog.codedread.com/?p=221#comment-368 Thanks Jeff; The library indeed does not produce a high level of quality, but I am developing it at the moment for simple graphics such as graphs and charts. I may go further and expand it to manage animation and scripting, but as you said, for now, it will only be useful for static images. Thanks Jeff; The library indeed does not produce a high level of quality, but I am developing it at the moment for simple graphics such as graphs and charts. I may go further and expand it to manage animation and scripting, but as you said, for now, it will only be useful for static images.

]]>