Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] RenderContext

Jody Garnett wrote:

Justin Deoliveira wrote:

Jesse,

I am trying to create the decorator api. I figure the best way is to create an abstract class (Decorator) that implements Renderer and just have extenders fill in the bits. However I am not sure if this is line with the current workflow. Does each renderer get its own raster? If so my design may not be the best solution since dectorators wouldn't need their own raster.


Hi Justin,

I kind of thought RenderContext was simply a facade on the various services available to someone writing a renderer. But it does seem to have acquired additional functionality somewhere on route (namely managing a bufferedImage for you). I have no idea how that will work with respect to printing.

I am pretty sure we are flip flopping on the idea of who is responsible for "owning" the raster for each layer. ie Managing the buffered image for a Layer is a good idea. We just need a way for a mathematically generated layer like north arrow to indicate "Don't buffer me, I am super fast" so that raster( Graphics2d ) gets called.

Q: Should we just throw a flag into the Renderer interface for now?

Emphatic no. A better way is to have a composite decorator renderer so a set of decorators can be rendered to one raster. Remember not all decorators have a zorder that makes them appear on top. Most do so a logical short cut the decorator renderer can make is to draw to the display graphics layer if the render() method is called and the zorder of the layer indicates that it is the top layer. Render is not called by the printing API so this should work.

Jesse


Back to the top