Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] Tiled Rendering and MapGraphics

You could also fold MapGraphic into project - I do want to collapse the plugins together and mapgraphic does not add too much value on its own - there may be the danger of breaking the extension point however (cannot remember if the plugin id is involved in the extension point name or not?).

However ...

Emily I am not sure anybody needs to know - the MapGraphic renderer implementation can do whatever it wants right. You can do what you need to without violating information hiding; nobody needs to know you are rendering to a screen sized image outside of the MapGraphicRenderer... remember the only thing that renderer needs to do is correctly play the game with the renderer composition correctly (if a big image is stored behind the sceen nobody needs to find out...).

Jody

Jesse Eichar wrote:
You can detect by seeing if the IGeoResource resolves to MapGraphic. You should almost never do instanceof checks in uDig.

But I think I understand the issue. Project does not depend on MapGraphic so how can you do the detection right? Honestly not sure. What options do we have?

1.  Make a marker interface ?
2.  Add something to the render metrics ?
3. Have a extension point where one can declare ways to handle renderers?

Any other options?

Jesse

On 5-Nov-08, at 8:53 PM, Emily Gouge wrote:

Hmm I think I get what you are trying to say here.

I would need a single list of mapgraphics layers that are rendered to a "screen tile". Then when I go to compose my tiles I can extract the section of the mapgraphic image that corresponds to the section of the tile I am composing. Hmm sounds like fun to implement!

One question - If I want to start treating MapGraphics as "special" renderers (so I can do different things based on the type of renderer) I need a way to distinguish between regular renderers and mapgraphic renderers. All the mapgraphic classes are in a different package so I can't simply to an "instanceof MapGraphic" test and I know it's not the correct thing to add the MapGraphic package as a dependency; so how do I go about determining if a renderer is a "special" renderer (in this case a mapgraphic renderer).

Thanks
Emily

Jody Garnett wrote:
Jesse the "tiling" system would still need to suck out a small tile worth of the main mapgraphic image when composing a "tile" for display ... unless the one specific case where the mapgraphic is "ontop" of the data layers that are all being tiled up. Emily I would suggest having the mapgraphic write into an image the size of the screen; and giving the "tiled renderer" the ability to select out a rectangle from this large image for use when "composing" the BufferedImage for an individual Tile...
Not sure if I explained that very well...
Jody
Jesse Eichar wrote:
IMHO I think that MapGraphics should not be part of the tiling. The reasoning is that they are supposed to be light-weight and fast. They should normally be fast enough without tiling. And often are independent of zoom so how would you know when to cache and when not to.

Jesse

On 4-Nov-08, at 11:49 PM, Emily Gouge wrote:

All,

I'm trying to clean up the the tiled rendering system I worked. One of the things I'm currently looking at is trying to get mapgraphics to work nicely with it.

My understanding is that currently mapgraphics pay attention to the bounds of the screen. So in my tiled rendering system they are paying attention to the bounds of the screen and using that information to draw onto the tiles. These tiles don't match up with the screen so as a result you get some fun results:
* legends, north arrows, etc on every tile.
* grids only partially filled in (if then render tiles are bigger than the screen only what would fit on the screen is filled in on the render tile).

So how to fix this?
not think that this is a problem we need to get worried about; MapGraphic renderer can handle it. We may need to look at it carefully and make sure it can fire the correct setState events as the viewport model changes; but we really should be in good shape.

Jody


Back to the top