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

Bill Keese bill at dojotoolkit.org
Tue Apr 18 02:07:14 EDT 2006


Well, let's decide what API we want first, and then think about what 
implementations (canvas/svg/vml) we support.  Extending your example, 
can I do this?

var line = dojo.draw.line(...);
line.setOnClick( function(){ alert("hi!"); });

(and then later on, line.destroy();)

Bill

Tom Trenka 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 
> <mailto: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
>     <mailto:dojo-contributors at dojotoolkit.org>
>      >> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>     <http://dojotoolkit.org/mailman/listinfo/dojo-contributors>
>      > _______________________________________________
>      > dojo-contributors mailing list
>      > dojo-contributors at dojotoolkit.org
>     <mailto:dojo-contributors at dojotoolkit.org>
>      > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>     _______________________________________________
>     dojo-contributors mailing list
>     dojo-contributors at dojotoolkit.org
>     <mailto: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



More information about the dojo-contributors mailing list