Vector graphics library: canvas, SVG, VML

[Mark Bakker]

Hi guys,

I have been doing some work on SVG on GWT. I am interested to
implement canvas, SVG, and VML support for GWT. I have been doing some
research for these formats and this resulted in the following:

- All of these formats need at least at some browsers a plug-in see
link; http://media.liquidx.net/js/plotkit-doc/SVGCanvasCompat.html

I think it would be a good idea to implement beside these formats
(SVG, VML, canvas) a extra implementation (I will call it from now on
the Vector implementation) that will dependable of the used browser
select one of the above formats.

lets say;
- I am a user on FireFox it will use as default the SVG implementation
- I am a user on IE it will use as default the VML implementation
- etc etc

probably this Vector implementation API can not be as rich as the
separate format API's, there will be some functionality gaps between
SVG, VML, and canvas.

what do you guys think about this?

[Emily Crutcher]

One thing to consider is that one of GWT's design goals is not to create separate APIs for separate browsers, so the SVG or VML specific API would be  discouraged. On the other hand, the "Vector API" is one we have been heavily looking at, and could be a very valuable API for the GWT community. Are you familiar with the deferred binding subsystem?  If not, check it out in the user docs, as that would probably be the most efficient way to implement the system.   If you have some ideas of what the Vector API could look like and successfully model SVG, VML, and probably, long term, Flash, that would be really awesome to see as well.

 

  Cheers,

 

          Emily

[Mark Bakker]

Okee that is clear, thanks... I still need to do some investigation in
the VML API for implementation in the Vector API. I will get back to
you. Flash is also a interesting one...

[ash]

hi emily, mark,

my current project does a lot of overlays on top of a google map
mounted in gwt appl. the nature of the application requires that a
large number of polygons be drawn within the view port.

after some research my conclusion is that the google maps overlay api
does not scale for my requirements. this caused me to do some
preliminary design on a gwt vector api.
i was tracking in a similar way to what emily described with deferred
binding. however, i anticipate that my api would be server centric.
that is, the geometries would be constructed at the server as either
svg or vml elements and client just setting the inner html in order for
the renderings to scale.

rgds ash
http://www.gworks.com.au

[Mark Bakker]

Okee that sounds nice! although I believe the Vector API for GWT
should be a client centric solution.

thanks for the input, I will look into that

[ivar]

Dojo ( http://dojotoolkit.org ) is a mature javascript toolkit with a
decent cross-browser (SVG & VML) vector graphics implementation. I
notice that the license options for Dojo code includes the BSD
license.. assuming the APL & BSD play nicely together, perhaps it would
be viable to work with them to create an uber vector graphics library
that could be used via gwt and/or dojo ? I'm just an interested third
party, but that seems like it would be the ideal case.. at the very
least, the work they've done on an abstracted vector API is worth a
close look.

sweet draggable vector image demo -
http://archive.dojotoolkit.org/nightly/demos/gfx/circles.html

As an aside, Jot (a recent Google acquisition) was a prominent
corporate contributor to Dojo.. any chance we might see some dojo/gwt
love ?

Sincerely,
Ivar Vasara

[Mark Bakker]

I must say I like the functionalities of DOJO. I think the
functionalities of DOJO should be very nice addition for GWT, but I
don't think GWT should be dependant on DOJO. These functionalities can
also be just created within GWT in the GWT way...

Disclaimer This is my personal opinion, I am not related to the GWT project

[Henry]

I completely agree with you, for several reasons. Creating the
graphics functionality within GWT enables a pay-as-you-go
functionality, since the GWT compiler can remove all code that is not
needed. This makes the extra download for most graphics clients much
smaller than if we relied on the DOJO library.

Also, within GWT, we need to account for the case of Safari. The
current released Safari has neither a usable SVG nor VML. Canvas is
unattractive, because it has no text facilities. That leaves us with
Flash or a funky Java2D applet. Any graphics library will
unfortunately have to be designed around the frailties of all the
platforms involved.

That being said, there's nothing preventing us from learning how they
did it :-).

Cheers,

Henry

[Ivar Vasara]

for more information, there's a new article this morning on the
dojo.gfx.* package..

http://www.thinkvitamin.com/features/design/create-cross-browser-vector-graphics

[kebernet]

I have a nearly "straight port" cribbed off of Dibona's "Explorer
Canvas" to GWT I am using now:
http://code.google.com/p/explorercanvas/

It really isn't that bad. I am 100% sure about Opera though, as I
haven't tried it.

On Dec 19, 6:05 am, "Mark Bakker" <bakker.m...@gmail.com> wrote:
> I must say I like the functionalities of DOJO. I think the
> functionalities of DOJO should be very nice addition for GWT, but I
> don't think GWT should be dependant on DOJO. These functionalities can
> also be just created within GWT in the GWT way...
>
> Disclaimer This is my personal opinion, I am not related to the GWT project
>
> On 12/19/06, ivar <vas...@gmail.com> wrote:
>
>
>

> > Dojo (http://dojotoolkit.org) is a mature javascript toolkit with a