Renderer

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Renderer

bchapuis
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.

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.

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.

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.

(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.

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.

Regard's,

Bertil


_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Renderer

Paul Spencer-2
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                          [hidden email]    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+




_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Renderer

Cameron Shorter
Paul, in answer to your last question.
Please don't break the vector code. I'm writing a Layer/Gml at the
moment and need working code to test against.

If you do break the code, please let us know so that I can put of
syncronising with the head version until it works again.

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                          [hidden email]    |
> +-----------------------------------------------------------------+
> |Chief Technology Officer                                         |
> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
> +-----------------------------------------------------------------+
>
>
>
>
>


--
Cameron Shorter
http://cameron.shorter.net
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Renderer

bchapuis
In reply to this post by Paul Spencer-2
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                          [hidden email]    |
> +-----------------------------------------------------------------+
> |Chief Technology Officer                                         |
> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
> +-----------------------------------------------------------------+
>
>
>
>

_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Renderer

bchapuis
In reply to this post by 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                          [hidden email]    |
> +-----------------------------------------------------------------+
> |Chief Technology Officer                                         |
> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
> +-----------------------------------------------------------------+
>
>
>
>
_______________________________________________
Dev mailing list
[hidden email]
http://openlayers.org/mailman/listinfo/dev