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
