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
