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

Tom Trenka ttrenka at gmail.com
Tue Jun 6 10:15:53 EDT 2006

Is there any real reason we can't keep the two separate?  I know both Alex
and Dylan have expressed *major* reservations on the use of Canvas (in fact,
Dylan was dead-set against it until I showed him the Moz extension that will
do window snapshot previews of tabs, don't remember the name of the
extension off the top of my head)...and if we made the decision to support a
DOM-based API separate from a raster-based one (i.e. canvas), that might
help this discussion a bit.

I'd also throw out the suggestion that we *might* be able to emulate canvas
using Flash (gasp!); the drawing API in Flash is pretty similar to canvas,
and we'd not worry about any kind of event handling at all on it.

Some answers otherwise:

On 6/6/06, Eugene Lazutkin <eugene at lazutkin.com> wrote:
> 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.

Yes, this was/is a concern...the goal would be to support (or at least
emulate) SVG Tiny, probably with minimal text support.  I'm fairly certain
we can get that far (with the exception of some arc calculations, the
gradient issues you've mentioned, some grouping + transformation issues,

btw I've done matrix transformations in the past (I implemented it but
didn't release it with f(m)) based on the transformations available in SVG,
which I'll probably end up tapping into at some point.

Also, is Gavin on this mailing list?

re: the Stylesheet...the target browser here is IE/Win, of which all of
(our) supported versions included the MSXML parser; we can make the
propreitary stuff work *for* us here because we know that the XSL processor
is definitely there and takes a specific form :)  I've done a lot of work
with it in the past as well, so I'm not so concerned about that aspect.

> 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.

I'm in agreement with you here as well.  Maybe we should keep a canvas
implementation separate though...at least have some thoughts in that

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20060606/a8893fb1/attachment.htm 

More information about the dojo-contributors mailing list