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