[dojo-contributors] SVG/VML/Canvas API discussion

Dan Pupius dan.pupius at gmail.com
Tue Apr 18 02:13:17 EDT 2006


It might be worth looking at ExplorerCanvas that Glen and Erik worked on:
http://sourceforge.net/projects/excanvas

On 4/17/06, Tom Trenka <ttrenka at gmail.com> wrote:
>
> It's not so much of whether we should or shouldn't support Canvas, per
> se.  I know that some feel that canvas is very limited but I think that's
> because it really is just a canvas upon which you can draw raster
> primitives.  Both SVG and VML are vector languages (think the difference
> between a JPG and an EPS file).
>
> But we'd start off script-based, and so the *commands* currently
> implemented with canvas would probably be the best place to start--even
> though underneath they'd be rendering to SVG or VML.  That's essentially
> what I meant.  For instance, dojo.draw.line() would map to <svg:line />
> and <vml:line />, etc.
>
> Anyways, that's the thought.
>
> trt
>
>
> On 4/17/06, Bill Keese < bill at dojotoolkit.org> wrote:
> >
> > > I know one of the things Alex has asked me for is that any primitive
> > > drawn be able to fire and respond to events.  Not sure how we'll pull
> > > that off with actual Canvas drawings, but I'll cross that bridge when
> > > we get to it (probably it will involve looking for a mouse click on
> > > the canvas element itself--if that's supported--and then analyzing the
> > > current rendering to see what the top most element is that one clicked
> > > on, what fun).
> >
> > PS: I realized my last message wasn't clear.  What I meant was, maybe we
> >
> > shouldn't support Canvas.  If we just support SVG/VML then it's easier
> > to support events.  I'm not sure of all the pros/cons though.
> >
> > Bill
> >
> > Bill Keese wrote:
> > > Hi Tom,
> > >
> > > Thanks for handling this, and also for doing the bug triage.
> > >
> > > There's a guy named Gavin that promised to do this API but I haven't
> > > heard anything from him for a while; maybe he lost interest.  Here's
> > the
> > > link:
> > >
> > > http://thread.gmane.org/gmane.comp.web.dojo.user/5504/focus=5726
> > >
> > > (this is why I made that InProgressProjects page on the wiki)
> > >
> > > As for my comments: I'm not a graphics expert, but I wonder whether we
> >
> > > should support the canvas API model (like you suggested) or the SVG
> > > model.  The difference being that in SVG there's a handle to every
> > > object you draw, so you can attach event handlers / erase previously
> > > drawn objects, etc.  Presumably canvas is faster but SVG/VML are more
> > > powerful.
> > >
> > > Bill
> > >
> > > Tom Trenka wrote:
> > >> Hi all,
> > >>
> > >> Since the Iterator discussion went *so* well (&lt;sarcasm/&gt; but
> > not
> > >> really), I figure it's time to start asking questions about an
> > >> SVG/VML/Canvas library, since it would seem that some think this
> > would
> > >> be a very useful thing.  So let me kick off the discussion (since
> > I'll
> > >> probably write it)...
> > >>
> > >> The nominal purpose of an SVG+VML+Canvas library would be to add a
> > >> single layer of abstraction over the two vector (and one bitmap)
> > >> drawing languages so that a developer can write one set of code, and
> > >> have it render properly on the major browser platforms.  However, I
> > >> have some issues with this, so let me lay this out first before
> > diving
> > >> into a request for purpose+proposal.
> > >>
> > >> 1.  My personal feeling is that widgets (one of the core uses for
> > >> something like this) should not be limited to an encompassing API for
> > >> drawing, and that there's no real difference (aside from platform)
> > >> between writing markup in VML and SVG and writing markup in
> > HTML.  All
> > >> three are valid, existing markup languages; to force an API over two
> > >> of these languages would be a detriment to the system.
> > >>
> > >> Note the use of the term "force".  I'm not suggesting the API isn't
> > >> needed, just that we shouldn't force things to rely on it that we
> > >> release ourselves.
> > >>
> > >> 2.  In the same vein, we shouldn't ignore the need for core files in
> > >> the same vein as style.js and html.js for the other markup languages.
> > >> svg.js is already a part of the library (even though a good portion
> > of
> > >> the functionality in that file is stub functionality that isn't
> > >> working yet).  I might expect there to be a vml.js at some point as
> > >> well; I will certainly add it when I get a better sense of what kind
> > >> of helper functions are needed (particularly when we finally address
> > >> DnD with vector markup).
> > >> ---
> > >> All of which to say is that I'd like it to be clear that any vector
> > >> API could (and probably will) rely on some core files but it should
> > >> not be the other way around.
> > >>
> > >> Now that that disclaimer is out of the way...what do we think we want
> > >> out of such an API?  What kind of opinions are there as to the shape
> > >> of such an API?  What does Dojo really need in these terms?
> > >>
> > >> I'll put forth a suggestion, and then let's discuss:  I would say
> > that
> > >> we would start with a script-based API, modeled on the Canvas API,
> > >> upon which we could write general purpose widgets to represent
> > drawing
> > >> primitives (and eventually more complex ones).  Before anyone
> > objects,
> > >> let me try to be clear:  when I say "modeled" on the Canvas API, I'm
> > >> referring to methods and the general results of those methods.  The
> > >> Canvas API is based on OpenGL, which makes sense from a scripting
> > >> standpoint; I don't see any reason why we shouldn't use the same
> > >> approach.
> > >>
> > >> I know one of the things Alex has asked me for is that any primitive
> > >> drawn be able to fire and respond to events.  Not sure how we'll pull
> > >> that off with actual Canvas drawings, but I'll cross that bridge when
> > >> we get to it (probably it will involve looking for a mouse click on
> > >> the canvas element itself--if that's supported--and then analyzing
> > the
> > >> current rendering to see what the top most element is that one
> > clicked
> > >> on, what fun).  What other things would you want out of such an API?
> > >>
> > >> trt
> > >>
> > >> (for the record, I will certainly be looking at the Google
> > >> ExplorerCanvas code but I'm pretty sure we won't incorporate it
> > >> because of licensing...unless, Alex, you want to take a close look at
> >
> > >> it and see?  My inclination is to learn from it but not use it, just
> > >> to be safe, plus I'd hate for Dojo to be reliant on other
> > >> projects--since it seems like one of the goals here is to be the
> > other
> > >> way around).
> > >>
> > >>
> > >>
> > ------------------------------------------------------------------------
> > >>
> > >> _______________________________________________
> > >> dojo-contributors mailing list
> > >> dojo-contributors at dojotoolkit.org
> > >> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> > > _______________________________________________
> > > dojo-contributors mailing list
> > > dojo-contributors at dojotoolkit.org
> > > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> > _______________________________________________
> > dojo-contributors mailing list
> > dojo-contributors at dojotoolkit.org
> > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> >
>
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20060417/1567b39c/attachment.htm 


More information about the dojo-contributors mailing list