[udig-devel] Re: Rendering into GeoTools?

[jeichar@xxxxxxxxxxxxxxx]

Quoting 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?).
> 
I'll update the page later today or tomorrow and will notify the list when I
have done so.

> 
> 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.)
> 

The interfaces for map and layer are different between udig and geotools.
The concept of a layer are "basically" the same between Geotools and udig. 
Basically a layer, in udig, is data and a style.  Our layer is slightly
different because we have the idea that there may be multiple ways to obtain the
data.  For example a Web Map Server and a Web Feature Server may both server up
the same data, a layer would refer to both these services.  
In Geotools layer is a resource and a style, as opposed to data and a style
which is udig's concept.  
The udig interfaces are not geotools friendly right now, some changes would have
to be made.  For example some methods take an IProgressMonitor to provide
feedback to the user interface when long operation take place, for example
obtaining the bounds of a feature source.  
If we want to port the udig model into geotools I think we need to define
interfaces which have a subset of udig's interfaces that udig could extend for
its own use.  

> 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.
> 

I am certainly for this as well.  I personally think that having multiple
renderers is better than having one.  (This is from my experience in geotools
and udig).  There are a number of reasons.  One is that each renderer is easier
to understand because they each have a specific understandable job.  Further it
allows developers to choose the renderers for their specific application, rather
than being forced to use the generic renderer or write a new renderer. 

> 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!)
A note here.  Macs do not have the SWT_AWT bridge at all.  

> - adapters that convert SWT GC to AWT Graphics2D, f.e. "Graphics2DRenderer"
I have started this and with 3.1 and SWT advanced imaging it has gotten much 
easier.
> - the interface solution, where rendering is done to an interface
>   ("ViewportGraphics" in uDig), and AWT Graphics2D and AWT GC
>   implementations exist.
The adapter between GC and AWT Graphics 2D may be enough now.  Viewport graphics
may not be required any longer.  As an interfaces I would like Viewport graphics
interface to basically be the same as Graphics 2D.  This tells me that maybe it
should be discarded.  

> 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.

We should also look at geoapi and see how their interfaces map to udig interfaces.  

Jesse