28 Jun
2013
28 Jun
'13
11:57 a.m.
ROView puts its elements in an OrderedCollection, doesn't it?
Might using a QuadTree help?
Stephan
28 Jun
28 Jun
3:50 p.m.
New subject: Improving Roassal Scalability
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
29 Jun
29 Jun
11:17 a.m.
New subject: Improving Roassal Scalability
Le 28.06.2013 15:50, Alexandre Bergel a écrit :
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
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.
1 Jul
1 Jul
8:55 p.m.
New subject: Improving Roassal Scalability
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(a)mailoo.org wrote:
Le 28.06.2013 15:50, Alexandre Bergel a écrit :
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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.
4192
days inactive
4195
days old
3 comments
3 participants
participants (3)
-
Alexandre Bergel -
mathieubmddehouck＠mailoo.org -
Stephan Eggermont