[OpenLayers-Dev] Renderer

Paul Spencer pspencer at dmsolutions.ca
Mon Nov 13 12:57:45 EST 2006


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/ |
+-----------------------------------------------------------------+







More information about the Dev mailing list