[udig-devel] Rendering into GeoTools?

[Matthias Basler <Matthias.Basler@xxxxxxxxxxx>]

Hi, developers, hi Jesse in particular

Last weekend I peeked into rendering in GeoTools and uDig. I did that because I
need some sound rendering concept onto which to build any map pane widgets in
GeoWidgets.

Side question:
Jesse, I've looked at uDig's rendering source code, but I got lost somewhere
between IMapWindow, IRenderContext, IMap and IViewportModel. ;-) The uDig
documentation on this
(http://udig.refractions.net/confluence/display/DEV/Renderers) just told me
that you use separate renderes for every layer, but I still need to get the
"whole picture" of how all these rendering-related interfaces play together.
Maybe something like a rendering UML diagram, but with explainations? I find
that the Javadoc's are a bit short of explaining how the whole concept plays
together and why some interfaces were built the way they are now.
Also, I got the impression that different rendering approaches are used for the
actual map and the legend icons (glyphs?).


Now back to the main topic:
The rendering code pieces in GeoTools and uDig obviously use different concepts:
- uDig gives every layer another renderer while, in geotools
  one renderer, such as the LiteRenderer, is used for the whole mapContext.
- uDig and GeoTools have different classes/interfaces for "maps"
  (as a stack of map layers): MapContext vs. IMap. If I'm not mistaken
  the map layer concepts are also different.
(Correct me if tell rubbish.)

I propose carefully that we decide on ONE rendering model - the better one of
course - and then put it into Geotools, so that other projects, like
GeoWidgets, can take use of it. I believe rendering is so substantial, there
MUST be a good rendering package in GeoTools. Jody obviously likes the idea as
well.

The future GeoTools rendering model should imho:
- include a sound concept for Maps and Map layers, since Geotools
  obviously lacks any interface for maps.
- be easy to use and not too abstract,
  i.e. do with the minimum necessary number of interfaces
  and classes that still allow to develop extensions for it. We might
  possibly need to find out which interfaces or their extensions are
  specific for uDig and which are universally reusable.
- be directly usable in uDig with as few changes as possible - so there
  isn't a problem for uDig switching to the new GeoTools rendering model
  I propose. This includes that it must fulfill the needs of uDig.
- be UI toolkit independent by default (AWT/Swing/SWT,SwingWT, ...)*
- be easy to extend to OpenGL or 3D rendering in general,
  whatever you have in mind for that.
- some more goals?

* Side note:
I've now seen three approaches to this so far:
- a bridge that allows to use AWT UI elements (eg panels) on SWT panels.
  This would mean that the renderer can use Java2D even in a SWT context.
  Class "SWT_AWT", see "www.dpunkt.de/leseproben/3-89864-281-X/Kapitel_8.pdf"
  (section 8.8, German!)
- adapters that convert SWT GC to AWT Graphics2D, f.e. "Graphics2DRenderer"
- the interface solution, where rendering is done to an interface
  ("ViewportGraphics" in uDig), and AWT Graphics2D and AWT GC
  implementations exist.

Now, I admit that I don't have the insight to evaluate the current uDig
rendering model and the above three approaches for UI toolkit independence, so
I explicitely ask about your opinions on all that. I also suggest collecting
aims, implementation ideas and such stuff at one some wiki page.

I'm willing to put time into this and help with whatever I am able to do, but I
can't do this alone, of course.

Any comments are welcome.

Matthias Basler
c9bama@xxxxxxxxxxx

P.S. I'm not sure on which list this discussion should be done, so I sent it to
both.

----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de