[dojo-contributors] Re: Draft: Unified 2D graphics subsystem for Dojo

Eugene Lazutkin 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 
is-a-point-inside-a-polygon? method).

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.

Thanks,

Eugene



More information about the dojo-contributors mailing list