Larry, One more annoying question. :]
If you can implement just about any custom rendering behavior with a Style, why are there several types of Renderer implementations in JUMP and OpenJUMP? Could these Renderers have been implemented with a Style as well? (I'm not trying to be argumentative, I'm just asking questions in an effort to understand.) The Sunburned Surveyor On 8/23/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > O.K. Larry. > > I can use a Style and an existing renderer like SimpleRenderer to > paint custom vector geometry. > > What about raster geometry? Is this different? > > Thanks again. > > The Sunburned Surveyor > > On 8/23/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > 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 > > > ------------------------------------------------------------------------- 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
