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

Eugene Lazutkin eugene at lazutkin.com
Thu Jun 22 13:39:55 EDT 2006

I had a chance to review the latest Kun's code. I think it was a very 
good start as far as we implementing simple shapes. Now let's get 
serious about Path and Fill.

Why Stroke, Fill, & Co. are renderer independent?

The idea is:

1) To be able to construct them in code using {}.
2) Pass them from server using JSON/RPC, if we need to calculate them 
dynamically server-side.

A server should not care what the underlying technology is. JSON/RPC 
requirement makes them pure method-less objects.

Obviously GradientFill breaks this rule defining a method. Maybe we 
should ditch it in favor of an array, which can be manipulated directly. 
  Something like that should work:

[{offset: 0.0, color: mycolor1}, {offset: 1.0, color: mycolor2}]

Let's treat all Fills and Strokes as simple method-less objects.

Regarding Path.

I think it is better to keep it independent. It should implement the 
API, which was outlined in the last proposal, building a valid SVG path, 
which can be used directly with setPath(). SVG's setPath() assignes it 
directly to "path" property. VML's setPath() is more complex: it should 
translate it on the fly during assignment. I don't think it will incur a 
noticeable overhead.

Why Path is independent?

The same reason applies: a server should not care about client's 
technology. In some cases it's better to build path server-side. One 
example of it is a routing, which is frequent in mapping technologies. 
We want to be able to pass it as a string using AJAX, or JSON, or RPC.

Regarding GradientFill.

SVG's implementation is quite complex. I included two sample files (SVG 
& VML), which demonstrate equivalent gradient features. Basically SVG 
defines a "defs" section, which is used for gradient definitions (among 
other things). This gradient definition is referenced by a shape. I 
think this structure should be generated automatically. It's not difficult:

1) Find "defs" section, otherwise create, if it is not found).
2) If you shape already references a fill, reuse it, otherwise create a 
new one.
3) For new attributes use some generated unique ids. AFAIK, Dojo already 
has it implemented. (Anybody! Please chime in, if you know where it is.)

How much SVG functionality would we cover?

The goal is to cover the most commonly used subset *shared by* SVG and 
VML. For complex stuff, users should use SVG/VML/Canvas directly.

More on Fill and Style.

What if I attached to an existing shape, and I want to read its fill 
attribute? It would be nice to be able to recreate our 
renderer-independent objects from scratch. Please think about it.

About constructing objects and setXXX() methods.

I think we need setXXX() methods, so we can modify existing objects. But 
in order to be rational, we should be able to pass the same arguments to 
constructors. Gavin pointed it out some time ago. The reason I didn't 
put them there because I wanted to have a minimal definition of Dojo's 
2D graphics. But for practical reasons we should have constructor's 
arguments as well. Gavin can explain it, if it is not clear.

Regarding error checking.

Of course we have to have in appropriate places. In general I am in 
favor of exceptions, but for now let's just ignore error making 
appropriate roll back. For example, if color is wrong, let's ignore the 
attribute in setPath/setFill, if coordinates are bad, let's skip on this 
shape, and so on. Later we can revisit this approach, if there are any 

Now I am going on my trip. I expect to check my e-mail starting from  6/26.



Gavin Doughtie wrote:
> Gavin Doughtie wrote:
>> 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)})
> Just re-read this and it's wrong. I actually think the idea is to have 
> first-class object "dojo.gfx.Stroke" and "dojo.gfx.Fill" with the 
> properties above, "Fill" for example would be returned both for 
> "dojo.gfx.createGradient" and "dojo.gfx.createPattern"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20060622/6d37bef5/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: svg.xhtml
Type: application/xhtml+xml
Size: 1254 bytes
Desc: not available
Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20060622/6d37bef5/attachment.xhtml 

More information about the dojo-contributors mailing list