ROView puts its elements in an OrderedCollection, doesn't it? Might using a QuadTree help?
Stephan
ROView puts its elements in an OrderedCollection, doesn't it?
Yes. But actually there are two collections. One for the existing elements, and another for the elements that are currently visible.
Might using a QuadTree help?
It would slightly help. This is a feedback I've heard from expert in the field.
We will keep the list informed about our progresses
Cheers, Alexandre
Le 28.06.2013 15:50, Alexandre Bergel a écrit :
ROView puts its elements in an OrderedCollection, doesn't it?
Yes. But actually there are two collections. One for the existing elements, and another for the elements that are currently visible.
Might using a QuadTree help?
It would slightly help. This is a feedback I've heard from expert in the field.
Well, there is an OrderedCollection with all the elements and kinda set of association of int (zOrdering) and orderedCollection for the elements to be rendered.
For now the problem is that all the elements are to be rendered.
The idea is then to choose the good elements to be drawn.
Here are proposals, tell me what you prefer:
1) Quadtree
+ you compute it one time, you only update it when dragging an element ;
- you have to deal with element overlapping several quadrants.
2) set of association
+ just like now, but with a lot less elements in the collections (fast to handle events, fast to draw) ;
- have to take more than just the visible elements so that we can translate the visualisation ; have to update when translating, zooming ;
3) fixed picture ( with the set of associations for events)
+ very fast to draw, very light, translation and zoom really easy,
- have to be deeply implemented, update when dragging an element
Please tell me what you prefer and I will do it.
Maybe quadtree is not the best solution here, and we can begin by solution 2 and then see if we need more speed.
Regards
Mathieu
Hi!
Using a quadtree, I do not think we will gain much. Authors of http://zvtm.sourceforge.net told us that quadtree brings more complexity than real gain.
For fixed picture, this is something that should be done, but not right now I think. It will definitely speed up a visualization, but only under particular condition. I do not think it is much faster to display an image than painting a box, however it consumes much more memory, and this is a problem.
Have you tried to improve #isRendered? Maybe adding an instance variable in ROElement or something? I am pretty sure we will gain at least 50% of execution time by having a fast isRendered.
Cheers, Alexandre
On Jun 29, 2013, at 5:17 AM, mathieubmddehouck@mailoo.org wrote:
Le 28.06.2013 15:50, Alexandre Bergel a écrit :
ROView puts its elements in an OrderedCollection, doesn't it?
Yes. But actually there are two collections. One for the existing elements, and another for the elements that are currently visible.
Might using a QuadTree help?
It would slightly help. This is a feedback I've heard from expert in the field.
Well, there is an OrderedCollection with all the elements and kinda set of association of int (zOrdering) and orderedCollection for the elements to be rendered.
For now the problem is that all the elements are to be rendered.
The idea is then to choose the good elements to be drawn.
Here are proposals, tell me what you prefer:
- Quadtree
- you compute it one time, you only update it when dragging an element ;
- you have to deal with element overlapping several quadrants.
- set of association
- just like now, but with a lot less elements in the collections (fast to handle events, fast to draw) ;
- have to take more than just the visible elements so that we can translate the visualisation ; have to update when translating, zooming ;
- fixed picture ( with the set of associations for events)
- very fast to draw, very light, translation and zoom really easy,
- have to be deeply implemented, update when dragging an element
Please tell me what you prefer and I will do it.
Maybe quadtree is not the best solution here, and we can begin by solution 2 and then see if we need more speed.
Regards
Mathieu
-
Alexandre Bergel -
mathieubmddehouck＠mailoo.org -
Stephan Eggermont