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

Eugene Lazutkin eugene at lazutkin.com
Mon Jun 5 21:34:18 EDT 2006

Tom Trenka wrote:
> 1st thing, foremost--instead of emulating existing APIs, perhaps we 
> should try something a little different--maybe a more functional 
> approach.  For instance, we could have the Path functions return a 
> reference to a path object, so that we could draw something in one fell 
> swoop, like so:
> surface.beginPath().moveTo(1,1).lineTo(20,20).closePath().end();


> ...which looks more complex but is kind of in keeping with some of the 
> coding style trends we've been using with Dojo (thinking about Deferred 
> here, but other things as well).

No, it's perfect. All these methods "return void", so it is easy to 
convert them to this style of use.

> Another overall comment I'd make is that we should probably try to use 
> named argument objects more (similar to the way dojo.io.bind works), 
> particularly when it comes to functions that require point coordinates. 
> For instance:
> surface.createLinearGradient({x:0,y:0},{x:20,y:20});
> ...that kind of thing.


> Lastly, I'd advocate something like this for general audience usage, but 
> I'd recommend against it (unless there were a really good reason to) for 
> any widgets that Dojo releases itself that need to be high performance 
> (and not functioning as an example).  I'd think that the goal would be 
> to bring vector drawing, in a Dojo style, to the general audience but we 
> (being the Masters of the Universe(tm)) would take a tip from game 
> development and go as raw as possible.

I understand your point. My only worry is the codebase will be bigger, 
if we don't use the unifying base. But if we have performance problems, 
or we need SVL/VML/Canvas-specific tricks, I would advocate the "raw" 
approach too. Otherwise, I think we should use a foundation.



More information about the dojo-contributors mailing list