klog has written a library that handles drawing "about 80% of basic shapes" for SVG using nothing but DHTML. I haven't tried it out yet, simply because all the browsers on all of my machines support SVG (Internet Explorer with the Adobe plugin, of course). I might actually uninstall ASV on one of my machines just to see how his library works.

What a fantastic idea! I had stumbled upon Walter Zorn's library about a month ago, but was unimpressed with the speed and had considered it irrelevant (er, i mean "dated") with SVG on the rise. However, I'm glad that someone smarter than me looked past this and has taken the initiative to adapt it to handle SVG for everywhere JavaScript is supported. It will never be as nice as an SVG plugin (Adobe/Renesis/whoever), especially for animated/dynamic aspects, but for static images it just might do the trick. Getting people to download/install the plugin is often the stumbling block.

I hope to see this library mature. Maybe he could enlist support from the SVG web developer community.

§221 · February 5, 2006 · JavaScript, Software, SVG, Technology, Web · · [Print]

Leave a Comment to “SVG Using Nothin’ But JavaScript”

  1. Kae Verens says:

    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.

  2. Paul says:

    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?

  3. Kae Verens says:

    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.

  4. Paul says:

    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…

  5. Kae Verens says:

    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.

  6. Groups says:

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