[dojo-contributors] Re: Draft: Unified 2D graphics subsystem for Dojo
eugene at lazutkin.com
Tue Jun 6 01:38:25 EDT 2006
Bill Keese wrote:
> Tom Trenka wrote:
>> at the Dojo Dev Day [ we agreed ] we're going to take a different
>> approach with respect to VML handling, by creating an XSL stylesheet
>> that will attempt to translate SVG to VML...
> It's an interesting approach. It allows the server sends over a bunch
> of raw SVG to the client, regardless of browser type. Of course you
> could alternately run the stylesheet on the server.
Let me point out once again that VML has its own restrictions => our
"raw SVG" should be restricted and/or augmented. It's no biggie in most
cases, but it can be restrictive sometimes.
> I keep thinking that we shouldn't support canvas at all. I'm sure it's
> good for performance but it's hard to imagine one API that is well
> suited to both SVG/VML and canvas. I know that the currently released
> safari doesn't have SVG support but the nightlies do, apparently... not
> good enough?
I am not convinced at all that Canvas is good for performance ---
properly done DOM-based renderer can be even more efficient. Canvas
certainly is not good for almost any kind of interactive graphics. But
... you guessed it right --- Safari. I don't want Mac-heads to be left out.
It would be easier to support just SVG/VML. We can drop Canvas out of
the list. But I don't want to close the proverbial door for it --- it
would be better to have a possibility of supporting Canvas for whatever
reasons. Canvas is much easier to implement in browser than SVG --- it
may steer the future development toward Canvas. E.g., I've heard rumors
that MS is thinking about implementing Canvas. Take a look at Mozilla 2
Graphics Plan: http://wiki.mozilla.org/Mozilla2:GraphicsPlan. Mozilla's
Stuart Parmenter commented on my proposal and advised ... to ditch
SVG/VML citing several reasons. It all makes you think twice before
ditching Canvas completely.
That being said we can move to completely DOM-based API --- frankly I
prefer it to procedural approach because of my past experience. In this
case we can still make a Canvas renderer as a fallback, but the amount
of code may be relatively large. As Tom pointed out earlier it is
possible to implement event processing completely in the code. I did it
before and I know what it takes: a lot of code and a special
infrastructure. (Side note: Stuart Parmenter mentioned that they are
going to provide a helper function for that in Canvas --- the good old
What is the difference between these two possible APIs? The proposed API
can be implemented with small amount of code in SVG/VML/Canvas. Moving
to pure DOM-oriented API keeps SVG/VML implementation small, but
potential Canvas renderer will be relatively large. Maybe it is a small
price to pay for better functionality.
More information about the dojo-contributors