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

Tom Trenka ttrenka at gmail.com
Mon Jun 5 14:32:00 EDT 2006


I'm not remembering off the top of my head the OpenGL code I was thinking
of, I'll have to go back and take another look.  I *do* seem to remember
looking at the Canvas spec and noticing some limitations, but...

Before I go any further on the commentary, I think it's important to
reiterate something that came about at the Dojo Dev Day, in discussions with
Dylan, myself and Jon Ferraiolo (one of the prime movers behind both the SVG
spec and the Adobe SVG Viewer, now at IBM); we're going to take a different
approach with respect to VML handling, by creating an XSL stylesheet that
will attempt to translate SVG to VML, so that this is transparent, thereby
eliminating (hopefully) any need to deal with cross-browser issues (cough IE
cough).  As soon as I get a chance (probably this week), I'll be starting
the work on it, with the really hopeful goal that it makes it to
0.4(probably be more like
0.5 but we'll see).

So, that being said...more comments inline.

On 6/5/06, Eugene Lazutkin <eugene at lazutkin.com> wrote:
>
> Tom Trenka wrote:
> > I'm sorry I haven't commented on this yet, I'm still looking it over.
> > First impressions: it seems to be ok but it doesn't really seem to allow
> > for attaching any kind of events to individual rendering definitions
> > directly (just like Canvas doesn't)...at least at first run-through.
>
> surface.endPath() returns a DOM node, which can be used for attaching
> events in using dojo.event.connect().


Cool, didn't see that (still have to read it over again).

> I'll look it over well today and post more commentary.  I do agree with
> > the Canvas emulation approach (although I would consider going back to
> > OpenGL and seeing if there's more we can do) but I would definitely like
>
> I still remember OpenGL reasonably well. What exactly caught your eye?
>
> > to have a better definition of why this is being proposed; what problems
> > does it solve and how?  This was my initial issue with coming up with a
> > vector API; it seemed like I was working on a solution that had no
> > (well-defined) problem.
>
> Sorry for leaving whys out.


No worries--I personally have a good idea of your why but I think we need to
be explicit, since we are a group of developers with some pretty diverse
backgrounds.

It allows writing graphical widgets (e.g., charts of any kind) in a
> browser-independent way. Why do I want that? We keep all code for such
> widgets in one place instead of in SVG/VML/Canvas-specific files. It
> buys us:
>
> 1) Write a chart once.
> 2) Debug its logic once.
> 3) Reduce our overall code base.
> 4) If user uses several graphical widgets, we can reduce the download
> size.


I'm going to comment on all of this down below, but I'll point out here
quickly that the big issue with this API, with the reasoning you have here,
is that it places the widget definition usage back in the procedural domain
(as opposed to declarative), which is somewhat contrary to the Dojo
approach.  Not that I disagree with your sentiment here at all, but I think
it's something that needs to be pointed out.

Why vector graphics? Why DOM-based approach? I want an _interactive_
> graphics instead of pretty pictures.
>
> 1) Interact with charts: DOM-based event processing --- connect directly
> to your objects.
> 2) Animate objects: DOM-based picture modification (not in the spec yet,
> see notes in the original proposal).
> 3) Print your charts at printer's resolution.
>
> My short-term goal is: "As a proof of concept I want to have a simple
> demo, which shows a pie chart. When user hovers or clicks on a pie
> piece, a tooltip pops up offering additional information. Ideally it
> should work with both SVG and VML seamlessly. Canvas-able browsers
> should show the same picture, but no fancy tooltips."


While I don't disagree that interactive graphics are very important, I would
like to not have 3 different APIs competing for each other; we've got your
proposed spec, the one that the gentleman for XDraw is proposing, and the
approach we decided on at Dojo Dev Day.  I know that the OpenLazslo guys are
also wanting/looking for a drawing API--for some of the same reasons you've
described--and they were pretty keen on having it follow the Canvas spec as
best as possible.

I'd also like to point out that starting with charts is probably not the
best way to go; charting solutions are among the most complex things we can
try to pull, and starting with the most difficult thing (IMHO) is a really
bad idea.  This is why I'm working on a Gauge widget right now, as a test
platform for pure SVG and VML support.

There are two other stated "wants" right now, in terms of vector stuff--a
connector widget with anchors (a la Visio) and finishing up the
HslColorPicker (iirc, Dylan, jump in here if you would).  But the holy grail
is something that would make writing a shared whiteboard application fairly
easy to pull.

So...with that in mind, I'd *really* like to get a nice, big list of the
things we're really aiming to support *first*, and *then* start talking
about an API.  Let me start:

1. Interactive flowcharts.
2. Interactive drawing tools.
3. More informative charting.
4. The ability to use an API like this to create much prettier widgets (a la
Apple's Dashboard).

Anyone else want to take a stab?

Tom

(btw, if you'd like to work together on the chart stuff offlist, I'd love to
talk; the current Chart widget supports a lot more than you'd probably
expect, and I have some definite ideas on where it's going...including
support for pie charts, radar/polar charts, log charts, and 3d
contour/surface plots).

(Also, it *might* be possible to do event handling on canvas-drawn images
through the use of position detection, but I don't want to even attempt that
yet.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20060605/a14e6530/attachment.htm 


More information about the dojo-contributors mailing list