There are really only two kinds of renderers I think: vector geometry and raster.
Mostly we are talking about geometry, right? If you have geometry, then you can style it anyway you want. In your example of the face of GW, I assume it would be located in the window by a geometry of point or perhaps a polygon. If you didn't want to reinvent all of the code that finds the intersection of the GW features, it would make sense to simply implement a style whose paint routine drew the face. regards, Larry On 8/23/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > Larry wrote: "If you want a more participatory response, you'll need > to explain why > you think it is necessary to have a pluggable rendering system in the > first place. The last discussion we had on the subject, I couldn''t > see why a Style wouldn't be better suited for most applications." > > Fair enough. I figured this question would be coming. I'm thankful I > got you to engage me as much on the topic as you did before you asked. > :] > > I haven't investigated Styles extensively, so I think this is mostly a > conceptual issue for me. After reading through the Developer's Guide > and the Javadoc I got the impression that a style modified the way a > "standard" renderer painted a "standard" object. > > For example, you could create a new style that changed the way the > LayerRenderer painted a Layer object. > > I thought what I wanted to do was fundamentally different. I wanted to > paint an entirely new type of object with an entirely new time of > Renderer. But maybe my thinking is faulty in this regard. Maybe I need > to be using something like SimpleRenderer or ImageChachingRenderer > with a custom Style object. Can you comment on this? > > Let me ask you if it is possible to do the following items with Styles > and the current rendering system, and if using Styles makes sense > conceptually. Please be patient with me if I have asked you these > things or something very simlilar before. :] > > [1] Could I change the default rendering of a Layer object using a custom > Style? > > [2] Could I render a completely new object, like, for instance the > face of George Washington, on the LayerViewPanel with a custom Style? > > Thank you very much for your efforts to guide and teach. I know that I > can be a little slow on the uptake. > > The Sunburned Surveyor > > On 8/23/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > Landon, > > > > See my comments below: > > > > On 8/23/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > > Larry, > > > > > > This is all very helpful. I'm glad you confirmed #1, #2, and #3 for me. :] > > > > > > You wrote: "Don't try to save memory by sharing renderers. We are only > > > talking about a few words of memory and whatever data structure you > > > use instead will need to store the same data." > > > > > > Here is the problem I'm trying to solve. Right now a Renderer for each > > > Layer is created by the RenderingManager. In my current pluggable > > > rendering system I modified this logic to use a Factory that creates > > > and returns a renderer based on the class type of the object being > > > rendered. > > > > > > Then I got to thinking, all that Factory stuff is unnecessary. Why not > > > just use plug-in mechanism to set the Renderer for each class in each > > > RenderingManager directly? Then the RenderingManager.render method can > > > call RenderingManager.getRenderer and an existing Renderer object for > > > the appropriate class will be returned. Because it already exists, we > > > don't need to spend the time creating a new one. This will make the > > > design of my pluggable rendering system simpler, and it will make the > > > overall rendering process more efficient. > > > > > > > It does already exist. The getRenderer() method looks up and returns > > a renderer from the contentIDToRendererMap. > > > > > The only major change needed to accomodate this is to set the > > > LayerViewPanel in each Renderer instance through a method when it is > > > installed in the RenderingManager, instead of in the Renderer's > > > constructor, as is done currently. > > > > > If you aren't using a Factory, why not use a constructor? It has to > > come from somewhere. > > > > > The basic premise is that we can create a single Renderer for all > > > instances of a single class ahead of time, instead of creating many > > > Renderers for each instance of a class during the rendering process. > > > This makes installation of pluggable renderers easier, and it should > > > speed up the rendering process. > > > > > The only data that a renderer is storing is the Layer and the Panel > > which is about the minimum needed to do the job. > > > > If you want a more participatory response, you'll need to explain why > > you think it is necessary to have a pluggable rendering system in the > > first place. The last discussion we had on the subject, I couldn''t > > see why a Style wouldn't be better suited for most applications. > > > > regards, > > Larry > > > > > > > I appreciate any thoughts that you have on this. > > > > > > Landon > > > > > > > > > On 8/23/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > > > Hi SS, > > > > > > > > I'll just state some things that I believe are true: > > > > > > > > 1. contendID is just a Layer cast to Object. > > > > 2. If you have 50 layers then it would follow that you have 50 > > > > contentID objects. > > > > 3. Every layer gets its own instantiation of a LayerRenderer or > > > > WMSLayerRenderer or whatever. > > > > 4. Almost all of these layers will be rendered sequentially on the > > > > defaultRendererThreadQueue (except for WMSLayerRenderer and such). > > > > 5. Don't try to save memory by sharing renderers. We are only > > > > talking about a few words of memory and whatever data structure you > > > > use instead will need to store the same data. > > > > > > > > Hope this helps. > > > > Larry Becker > > > > > > > > On 8/23/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > > > > That question probably reflects my ignorance of OpenJUMP's rendering > > > > > system and Java threading. But I'm hoping some of the more experienced > > > > > programmers can help me out. > > > > > > > > > > It seems that OpenJUMP currently stores a separate instance of the > > > > > Renderer interface for each object (contentID) that needs to be > > > > > rendered. That means if you have 50 layers, OpenJUMP stores at least > > > > > 50 Renderers. At first I thought this had to do with threading. I > > > > > suspected you needed separate Renderers for each object so that if you > > > > > had a computer with 50 CPUs each of the 50 renderers in the above > > > > > example could execute simultaneously. > > > > > > > > > > But then I noted that the Renderer interface defines a > > > > > createRunnable() method that returns a separate "thread" object. Does > > > > > this mean that you don't really need a separate rendering instance for > > > > > each object to be rendered? Could you instead have a single Renderer > > > > > that returned 50 Runnable objects? > > > > > > > > > > I appreciate any help in answering this question. I'm trying to make > > > > > some final modifications to my pluggable rendering system, and this > > > > > has some important implications for my design. > > > > > > > > > > I really do intend on documenting some of what I've learned about the > > > > > rendering system for others. :] > > > > > > > > > > The Sunburned Surveyor > > > > > > > > > > ------------------------------------------------------------------------- > > > > > This SF.net email is sponsored by: Splunk Inc. > > > > > Still grepping through log files to find problems? Stop. > > > > > Now Search log events and configuration files using AJAX and a > > > > > browser. > > > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > > > _______________________________________________ > > > > > Jump-pilot-devel mailing list > > > > > Jump-pilot-devel@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > > > > > > > > > > -- > > > > http://amusingprogrammer.blogspot.com/ > > > > > > > > ------------------------------------------------------------------------- > > > > This SF.net email is sponsored by: Splunk Inc. > > > > Still grepping through log files to find problems? Stop. > > > > Now Search log events and configuration files using AJAX and a browser. > > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > > _______________________________________________ > > > > 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: Splunk Inc. > > > Still grepping through log files to find problems? Stop. > > > Now Search log events and configuration files using AJAX and a browser. > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > _______________________________________________ > > > Jump-pilot-devel mailing list > > > Jump-pilot-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > > -- > > http://amusingprogrammer.blogspot.com/ > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > 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: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > -- http://amusingprogrammer.blogspot.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
