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

Reply via email to