Hi, Sorry, I have worked with some parts of some renderers, but I have not a sufficient knowledge of the whole rendering system to have an opinion about the way to improve it or even the necessity to do it. I just can tell that making things modular and plugguble seems good to me but don't know how it should be done. Hope someone else can give better advice as I'm sure it is a very important part of the application.
Michaël Sunburned Surveyor a écrit : >Larry Becker helped me figure out why Strings were getting passed as >ContentIDs in OpenJUMP's rendering code. It turns out there are >special renderers that need to be given a chance to paint on the >LayerViewPanel everytime the LayerViewPanel.paintComponent() or >LayerViewPanel.repaint() methods are called. For example, you have the >FeatureSelectionRenderer, the BackgroundRenderer and a couple of >others. > >These renderers operate a little differently that the "standard" Layer >renderer. This is because they always need to be given the change to >paint. (The Layer renderer only needs to paint if the active task >contains Layer objects.) The JUMP developers used an interesting >"trick" to accomplish this. They added Strings to the list of >ContentIDs stored in each RenderingManager. (These Strings are added >in the RenderingManager's constructor.) A special renderer is then >associated with each of these Strings. (For example, the >FeatureSelectionRenderer is associated with the String "SELECTION".) >Since the Strings are permanent residents of the ContentIDs list, the >special renderers are always given a chance to paint. > >I want to change this system slightly to work with my pluggable >rendering system. I will still add Strings to the ContentIDs list, but >I will delegate the creation and return of the special renderers to >implementations of my IRendererFactoryTool interface. This will >preserve consistency and will also allow us to custimize things like >background, grid, or selection rendering without recompiling >OpenJUMP's source code? > >Does anyone see any problems with this idea? > >The Sunburned Surveyor > >(I won't be commiting any of these changes to the OpenJUMP CVS.) :] > >------------------------------------------------------------------------- >This SF.net email is sponsored by DB2 Express >Download DB2 Express C - the FREE version of DB2 express and take >control of your XML. No limits. Just data. Click to get it now. >http://sourceforge.net/powerbar/db2/ >_______________________________________________ >Jump-pilot-devel mailing list >Jump-pilot-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
