[dojo-contributors] Re: Kicking off Dojo 2D project

Gavin Doughtie gavin at dfmm.org
Thu Jun 22 02:05:34 EDT 2006


Ioannis Baltopoulos wrote:

> Guys,
>
> please find attached the code i've been working on for the past couple 
> of days.
>
> Copy into src/gfx and tests/gfx respectively and try it out. Naturally 
> you should use IE for this.
>
> I've now completed most of the basic shapes from the VML spec and will 
> spend some more time ironing out the code and adding functionality.
>
> Cheers,
>
> Yiannis


Excellent -- and a lot of shapes, too.

Kun and Ioannis, it's not too soon to test each others' code if you can. 
We should be able to have a "test_gfx.html" that can load in either 
Firefox or IE. Ioannis, it should be easy for you to load your tests in 
Firefox (since it's free and available for Windows). I think Kun's on a 
Mac or Linux, though. (if so, you might try running the samples through 
Opera 9 and/or the Safari SVG nightlies).

Ioannis, you've implemented specific functions that map more directly to 
VML, such as

setFill(bool)
setFillColor(r, g, b)
setStrokeColor(r, g, b)

etc.

Eugene's concept was that there would be "fill" and "stroke" objects 
that would carry all properties generically, and the interface would 
only need to be "setFill" or "setStroke", like:

shape.setFill({opacity: 0.5, color: dojo.graphics.color.Color(255, 255, 0)})

etc.

I'm attaching a sample __package__.js to be loaded in the gfx directory. 
You can then

require("dojo.gfx.*");

var g = dojo.gfx.defaultRenderer;
var surf = g.createSurface(body, width, height);

and so on

I'll contribute some actual test samples for unified things on Saturday 
unless you beat me to it.

Gavin

>
>
> On 6/21/06, *Gavin Doughtie* <gavin at doughtie.com 
> <mailto:gavin at doughtie.com>> wrote:
>
>     Kun Xi wrote:
>
>     > Hi Gavin,
>     >
>     > On 6/20/06, Gavin Doughtie <gavin at doughtie.com
>     <mailto:gavin at doughtie.com>> wrote:
>     >
>     >> Some general coding stuff -- other folks please chime in if you
>     see me
>     >> giving bad advice :-)
>     >>
>     >> For starters, I'd define the root set of shape primitives with a
>     >> "nodeType" member, like so:
>     >>
>     >> dojo.declare("dojo.gfx.svg.Rect ", dojo.gfx.svg.Shape, {
>     >>     nodeType: 'rect',
>     >>     initializer: function() {
>     >> etc.
>     >>
>     >> That way you don't have to keep passing it around in the creation
>     >> functions, and you can use it to dynamically maintain the
>     dispatch table
>     >> you currently have coded as a switch statement for
>     instantiating shapes
>     >> based on node tags.
>     >
>     >
>     > I keep passing "rect", "line", since this is the tag name in
>     svg. That
>     > sounds a good idea, but I am not quite sure whether I have followed
>     > it. I would try it and give feedback later.
>
>
>     I was saying that you could declare the tag name in the shape objects
>     (in C++ it would be the equivalent of a static const member), then
>     whenever you needed the tag name, you
>     could just do "someShape.nodeType", so createObject becomes:
>
>         createObject: function(shape, obj) {
>             if(!this.rawNode) return null;
>             var n = document.createElementNS(dojo.svg.xmlns.svg,
>     shape.nodeType);
>             // FIXME: hideous hack
>             shape.rawNode = n;
>             this.rawNode.appendChild(n);
>             shape.setParams(obj); // calls through to setPath,
>     setRect, etc.
>             return shape;
>         },
>
>
>     > As for your createObject question, the way Eugene originally set
>     it up
>     >
>     >> was so the client code would have to do:
>     >>
>     >> surface.createRect ().setRect({ x: 0, y: 0, width: 100, height:
>     100 });
>     >>
>     >> But we think it would feel more natural to be able to do:
>     >>
>     >> surface.createRect({ x: 0, y: 0, width: 100, height: 100 });
>     >>
>     >> although we'd still need setRect for changing the shape.
>     >
>     >
>     > Why we still need to call setRect? it works without any problem
>     to do
>     > just
>     > surface.createRect({ x: 0, y: 0, width: 100, height: 100 });
>     >
>     You'd still want to be able to reshape an existing rect, like so:
>
>     var myCoolRect = surface..createRect({ x: 0, y: 0, width: 100, height:
>     100 });
>
>     // Then, later, possibly as a result of a value changing -- imagine
>     // an animated bar chart...
>
>     myCoolRect.setRect({ height: 500 });
>
>
>     > The code I am working has implemented the bezier curve but now is
>     > still quite messy, I would merge your advice refactor it more
>     > throughly before send it out if the svn is not setup at that time.
>
>     Alex is pretty adamant that we all just become regular dojo committers
>     by patching a couple of bugs in trac.dojotoolkit.org
>     <http://trac.dojotoolkit.org>. I submitted a
>     trivial one last night myself :-)
>
>     This is a good idea as it will help make sure that each of us has
>     internalized enough of the toolkit architecture that our
>     submissions for
>     gfx "play well."
>
>     Ultimately we'll have a gfx branch to submit on, then merge back
>     in for
>     0.4 or later.
>
>     > Currently, working on the new feature: linearGradient. Felt a little
>     > lost here. Gradient is defined in <defs> tag, and referred by
>     fill or
>     > stroke. But gradient is not shape, am I right, so the best approach
>     > migth be like this:
>     > grad = new dojo.gfx.svg.LinearGradient( id="MyId" );
>     > grad.addStop( new dojo.gfx.svg.Stop( {offset:"5%", color: [128,
>     255,
>     > 200, 0] });
>     > grad.addStop( new dojo.gfx.svg.Stop( {offset:"95%", color: [255,
>     255,
>     > 200, 0] });
>     >
>     > when you use it:
>     > setFill( grad )
>     >
>     > This is quite straightforward for the user, do you think it is a
>     good
>     > design ?
>
>
>     Yes, but it would be:
>
>     // addStop returns the gradient, so you can chain:
>     var grad = surface.createGradient().addStop({offset:"5%", color: [128,
>     255, 200, 0] }).addStop({offset:"95%", color: [255, 255, 200, 0] });
>
>     // And you can share gradients:
>     shape1.setFill(grad);
>     shapeFoo.setFill(grad);
>
>     The fact that you need to create a node in the defs section and
>     refer to
>     it by ID would be an implementation detail in Shape.
>
>
>     > Some problems need your advices:
>     >
>     > 1) the gradient is not declared inline, so we have to define it
>     in the
>     > container, instead of the shape, like this:
>     >
>     > shape.addStyle( grad ) // we can reuse it for pattern as well.
>     > shape.createRect(...).setFill(grad)
>     >
>     > Do you think this is a good idea ?
>
>     Sounds fine to me.
>
>     > 2) I love type safe and overload in C++, do we have the same feature
>     > in JavaScript? For instance, setFill
>     > setFill( [r, g, b, alpha] ) // color
>     > setFill("lime") // stock color
>     > setFill( grad ) // gradient object
>     >
>     > do we have overload and type safe, let me put it in another way,
>     any
>     > idea to throw exception if wrong parameters are fed, or how to make
>     > sure the right function is called according the parameter?
>
>     You have to do this yourself at runtime. For primitive types you
>     can use
>     the "typeof' operator:
>
>     // Will return "function", "object", "number", "string", "boolean"
>     if (typeof  obj == 'string') {
>        // do string stuff
>     } else if (typeof obj == 'number') {
>         // do number stuff
>     } else if (typeof obj == 'function') {
>         // function will be returned as
>         // the type of all the object "classes"
>         // like 'Array' and 'Node'
>     } else {
>        // pretty good bet it's going to be "object"
>        // at this point, and you can use....
>
>         if (obj instanceof dojo.Color) {
>            // setting the color
>        } else if (obj instanceof Array) {
>           // setting the color with a component array
>        }
>         // And so on.
>         // At this point you could also use double-dispatch, like so:
>
>         if ('setOnShape' in obj) {
>            obj.setOnShape(this); // "this" is always a shape, so now
>     obj is
>     responsible for doing the appropriate thing
>        }
>     }
>
>     You can get some additional help from dojo -- go read
>     dojo/src/lang/type.js
>
>     > 3) the last but not least, what are our plan for the svg render? The
>     > SVG spec 1.1 is really scaring, I almost regret for my decision,
>     :-)
>     > just kidding.  Are we going to implement the whole spec, or just
>     > finish the major part and move on to some advanced features
>     developers
>     > and users may take interest in, e.g widget, event, scripting.. and
>     > complete in the succeeding version?
>
>     I think all we really need is what Eugene outlined. I'll write some
>     demos and tests against your next rev.
>
>     >
>     > #3 is: surface, group, shape.
>     > if text box is not shape, gradient and pattern is not in our
>     horizon
>     > right now, I am almost finish #3. :-). If everything works well, I
>     > might clean the code, release it and start working on widget next
>     > week.
>
>     Text is a big enough effort that we could leave it for the next
>     revision, too.
>
>     > Another queston out of topic, is there any tool to benchmarking the
>     > javascript performance and memory footprint? I would not
>     optimize the
>     > code right now, just curious. :-)
>
>     You absolutely need Firefox with Venkman:
>
>     http://www.mozilla.org/projects/venkman/
>
>     and Firebug:
>
>     http://www.joehewitt.com/software/firebug/
>
>     Venkman has a "Profile" menu.
>
>     If you're deep in Microsoft-land, there's some useful stuff in Visual
>     Studio, too.
>
>     Gavin
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: __package__.js
Type: application/x-javascript
Size: 289 bytes
Desc: not available
Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20060621/a2539ffa/attachment.bin 


More information about the dojo-contributors mailing list