So in re-reading the proposal, I've a few more definite comments...and one inspired by Bob's reply here.<br><br>1st thing, foremost--instead of emulating existing APIs, perhaps we should try something a little different--maybe a more functional approach.&nbsp; 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:
<br><br>surface.beginPath().moveTo(1,1).lineTo(20,20).closePath().end();<br><br>...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).
<br><br>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:
<br><br>surface.createLinearGradient({x:0,y:0},{x:20,y:20});<br><br>...that kind of thing.<br><br>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).&nbsp; 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.
<br><br>trt<br><br>(otherwise it looks pretty good, we should compare it to the other spec that's floating out there)<br><br><div><span class="gmail_quote">On 6/5/06, <b class="gmail_sendername">Bob Ippolito</b> &lt;<a href="mailto:bob@redivi.com">
bob@redivi.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>On Jun 5, 2006, at 10:55 AM, Eugene Lazutkin wrote:<br>
<br>&gt; Tom Trenka wrote:<br>&gt;&gt; I'll look it over well today and post more commentary.&nbsp;&nbsp;I do agree<br>&gt;&gt; with the Canvas emulation approach (although I would consider<br>&gt;&gt; going back to OpenGL and seeing if there's more we can do) but I
<br>&gt;&gt; would definitely like<br>&gt;<br>&gt; I still remember OpenGL reasonably well. What exactly caught your eye?<br><br>The only thing I can think of is that Canvas forces you do do scale/<br>translate/rotate separately where in OpenGL you can just use a matrix
<br>to do all three in one fell swoop. Because of this, affine transforms<br>seem especially painful to do in Canvas.<br><br>-bob<br><br>_______________________________________________<br>dojo-contributors mailing list<br>
<a href="mailto:dojo-contributors@dojotoolkit.org">dojo-contributors@dojotoolkit.org</a><br><a href="http://dojotoolkit.org/mailman/listinfo/dojo-contributors">http://dojotoolkit.org/mailman/listinfo/dojo-contributors</a>
<br></blockquote></div><br>