[OpenLayers-Dev] Renderer

[bchapuis]

I think it's better if you make a new branch from vector to refactor the
renderer classes. We can merge the branches later. As much as possible,
I will help you to debug the SVG, VML part of the code.

regard,

Bertil

On Mon, 2006-11-13 at 12:57 -0500, Paul Spencer wrote:
> Hi Bertil,
> 
> Thanks for the update.  I think we are getting close here.  I have  
> some specific comments inline
> 
> On 13-Nov-06, at 11:35 AM, bchapuis wrote:
> 
> > Paul, Cameron,
> >
> > thanks for the svn updates. It's very exciting to see the code
> > modifications. We also think that's important to unify and refactor  
> > the
> > base of code.
> >
> > Now the first priority is to quickly find a common solution for the
> > Canvas, SVG and VML Renderers (Paul, thanks a lot for your initiative
> > with the Renderer Class).
> >
> > Here, we are a little bit afraid about the javascript performances. We
> > need a very reactive solution for editing functionalities and we drew
> > our design with this goal. So to answer some questions here are
> > more explanations about our architecture.
> >
> > The rendered vectors are directly drawn in vector coordinates. You can
> > see that if you browse the DOM attributes.
> 
> To make performance decent in Canvas, I needed to pre-compute the  
> pixel location from the geographic location and cache it until the  
> geographic position changed or the canvas was moved.  If we remove  
> the Sheet object from the architecture, then this becomes an  
> implementation detail of Canvas and lets Svg/Vml work in geographic  
> coordinates (as appropriate).
> 
> It may be possible with Canvas to do the same thing by scaling all  
> rendering ... just thought of that!
> 
> >
> > The Renderer.setExtent() function, is used to change the view box  
> > of the
> > SVG/VML document. So the vector layer is completely drawn when the  
> > page
> > is loaded. When pan or zoom actions appends we just reset the visible
> > part of the document. It's probably not possible to do the same with
> > canvas. But we can try to simulate it.
> 
> In Canvas, I created a canvas twice as big as the map and only move  
> the canvas when necessary.  This is essentially the same technique I  
> think, but managed slightly differently.
> 
> >
> > Each instance of Renderer class have is own root property. Root is a
> > reference to a DOM node. So if you want to draw in a second layer, you
> > must create a new instance of a renderer.
> 
> Right.  Canvas creates a DOM element as well, <canvas>.  What I did  
> was to attach this as an attribute of the layer object in the attach 
> () code.  This means that all the state for the rendering of a  
> particular layer is stored with the layer rather than the renderer.   
> Then you can have one instance of renderer work with multiple layers  
> by passing the layer as an argument to each call.  I think this is  
> better (but I am willing to be convinced otherwise).
> 
> >
> > Each Renderer have the ability to trig specific edition events. These
> > contain a reference to the pointed geometry. The goal was to
> > make an abstraction layer and allow renderer wich don't manage DOM
> > events to send the same events as the others. In Canvas, the only
> > possibility is probably to loop on features and find the geometry
> > reference.
> 
> That is correct.  With the changes I am proposing, each Renderer  
> would have a findGeometryForEvent (or whatever I called it) and in  
> the Vml and Svg cases, they can just get the element by id.  In the  
> canvas case, I can then search the nodes/lines/polygons etc.
> 
> >
> > (Note that in SVG/VML renderer we directly put a geometry reference in
> > the DOM node. So we don't have to loop on the features.)
> >
> > Paul, it will be a great thing to copy the last version of your canvas
> > Renderer in the vector/lib/OpenLayers/Renderer folder.
> 
> Ok :)
> 
> >
> > We want discuss this architecture and pay attention to the others
> > arguments. So it will be nice to have more explanations for the global
> > Renderer Class and suggestions to merge the two architectures of  
> > canvas
> > and vector XML syntax. Due to time zone difference, it's probably
> > difficult for all of us to be at the same time on IRC, it's probably
> > better if we use the mailing-list to answer.
> 
> 
> I'd like to commit some changes for my modification to the  
> architecture, but it will for sure break the code (i.e. it won't be  
> runnable) until I have time to debug (and there are some changes that  
> would need to be made in Svg and Vml).  How do you want to do this?   
> Should I work in (yet another) sandbox or should I just commit and  
> then try to get it working again?
> 
> If we are ready to move on the changes I am proposing, I'd like to  
> work on them tonight I think.
> 
> Cheers
> 
> Paul
> 
> >
> > Regard's,
> >
> > Bertil
> >
> >
> 
> +-----------------------------------------------------------------+
> |Paul Spencer                          pspencer at dmsolutions.ca    |
> +-----------------------------------------------------------------+
> |Chief Technology Officer                                         |
> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
> +-----------------------------------------------------------------+
> 
> 
> 
>