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

Bill Keese bill at dojotoolkit.org
Mon Apr 17 22:06:36 EDT 2006


 > 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 (<sarcasm/> 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



More information about the dojo-contributors mailing list