Improving Roassal Scalability
Locked
 
|
Hi I just begin looking after point of optimisation into Roassal and I there are different points : - firstly, it is not easy to profile - it seems that when we move the mouse on the visualisation then it draws everything each time we move the mouse. And of course the biggest the visualisation is, the hottest the computer is to be. So maybe we should either, only draw the visible things (we must know what is visible easily), or we should draw the whole visualisation as a picture (bitmap or svg ) in a buffer and then just navigate in it, and keeping a list of visible things (not to be drawn but to be checked for interactions).
I think the picture is a good solution (maybe not a perfect one) since refreshing a picture is fine easier than redrawing the whole visualisation. And we should only draw changing elements with another color when dragging them.
What do you think about that ??
Regards Mathieu _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Mathieu,
To profile, which kind of visualization are you using? A ROMondrianViewBuilder or a ROView? I'm saying this because a ROView rendering a set of ROElements without any interaction will maybe help you to isolate problems related with rendering and problems related with events. I believe that yes, first of all it would be useful to use a good method to select which elements are visible and which of them are not. However, refreshing only the reached elements might be a bit complicated in the case you have other elements behind. Ie, when having overlapping elements maybe you should first find them and then refresh them too, which maybe can be expensive as you maybe need to do run through the view's elements. Because of this, I liked the idea of a tile system in which you refreshed a tile with a set of elements inside. But I understand the reasons of not liking it because it will add more complexity to Roassal :) I also like the idea of using an image to render instead of drawing all the shape. Cheers, Vanessa. On 06/26/2013 08:50 AM, [hidden email] wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Improving Roassal Scalability
|
|
Hi, It might be stupid but what about to have a nice way to trigger only the events that are needed and disable the others? I mean, if the interactions I need are achived with a mouse click I don't need to track the position of the mouse all the time it moves. As soon as you are sure that you can have a fine grain management of your events (thing that might be already in place), than you can start improving the event related problems.Cheers, 2013/6/26 Vanessa Peña Araya <[hidden email]>
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> It might be stupid but what about to have a nice way to trigger only the events that are needed and disable the others? I mean, if the interactions I need are achived with a mouse click I don't need to track the position of the mouse all the time it moves. As soon as you are sure that you can have a fine grain management of your events (thing that might be already in place), than you can start improving the event related problems.
Yes, but this is not trivial to do. ROMorph is the guy that emit the event ROMouseMove. Maybe in the middle of your visualization, you will have an element that wants to have a popup (i.e. adequately respond to ROMouseMove). Here is a caricatural fact about visualization engines: - engine that do not offer interaction are fast - engine that offer fancy interactions are slow (e.g., Roassal) Finding the right spot in the middle and giving tools to move from one extremity to other is the real challenge. We are slowly getting there... Alexandre > > > > > 2013/6/26 Vanessa Peña Araya <[hidden email]> > Hi Mathieu, > > To profile, which kind of visualization are you using? A ROMondrianViewBuilder or a ROView? I'm saying this because a ROView rendering a set of ROElements without any interaction will maybe help you to isolate problems related with rendering and problems related with events. > > I believe that yes, first of all it would be useful to use a good method to select which elements are visible and which of them are not. However, refreshing only the reached elements might be a bit complicated in the case you have other elements behind. Ie, when having overlapping elements maybe you should first find them and then refresh them too, which maybe can be expensive as you maybe need to do run through the view's elements. Because of this, I liked the idea of a tile system in which you refreshed a tile with a set of elements inside. But I understand the reasons of not liking it because it will add more complexity to Roassal :) > > I also like the idea of using an image to render instead of drawing all the shape. > > Cheers, > Vanessa. > > > On 06/26/2013 08:50 AM, [hidden email] wrote: >> Hi >> >> I just begin looking after point of optimisation into Roassal and I there are different points : >> >> - firstly, it is not easy to profile >> >> - it seems that when we move the mouse on the visualisation then it draws everything each time we move the mouse. >> >> And of course the biggest the visualisation is, the hottest the computer is to be. >> >> So maybe we should either, only draw the visible things (we must know what is visible easily), >> >> or we should draw the whole visualisation as a picture (bitmap or svg ) in a buffer and then just navigate in it, and keeping a list of visible things (not to be drawn but to be checked for interactions). >> >> >> I think the picture is a good solution (maybe not a perfect one) since refreshing a picture is fine easier than redrawing the whole visualisation. >> >> And we should only draw changing elements with another color when dragging them. >> >> >> What do you think about that ?? >> >> >> Regards >> >> Mathieu >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Improving Roassal Scalability
|
|
Alex may be we should use a bit of magic to compile install methods based on a configuration (aka aspects).
Stef On Jun 26, 2013, at 10:43 PM, Alexandre Bergel <[hidden email]> wrote: >> It might be stupid but what about to have a nice way to trigger only the events that are needed and disable the others? I mean, if the interactions I need are achived with a mouse click I don't need to track the position of the mouse all the time it moves. As soon as you are sure that you can have a fine grain management of your events (thing that might be already in place), than you can start improving the event related problems. > > Yes, but this is not trivial to do. ROMorph is the guy that emit the event ROMouseMove. Maybe in the middle of your visualization, you will have an element that wants to have a popup (i.e. adequately respond to ROMouseMove). > > Here is a caricatural fact about visualization engines: > - engine that do not offer interaction are fast > - engine that offer fancy interactions are slow (e.g., Roassal) > > Finding the right spot in the middle and giving tools to move from one extremity to other is the real challenge. We are slowly getting there... > > Alexandre > > > >> >> >> >> >> 2013/6/26 Vanessa Peña Araya <[hidden email]> >> Hi Mathieu, >> >> To profile, which kind of visualization are you using? A ROMondrianViewBuilder or a ROView? I'm saying this because a ROView rendering a set of ROElements without any interaction will maybe help you to isolate problems related with rendering and problems related with events. >> >> I believe that yes, first of all it would be useful to use a good method to select which elements are visible and which of them are not. However, refreshing only the reached elements might be a bit complicated in the case you have other elements behind. Ie, when having overlapping elements maybe you should first find them and then refresh them too, which maybe can be expensive as you maybe need to do run through the view's elements. Because of this, I liked the idea of a tile system in which you refreshed a tile with a set of elements inside. But I understand the reasons of not liking it because it will add more complexity to Roassal :) >> >> I also like the idea of using an image to render instead of drawing all the shape. >> >> Cheers, >> Vanessa. >> >> >> On 06/26/2013 08:50 AM, [hidden email] wrote: >>> Hi >>> >>> I just begin looking after point of optimisation into Roassal and I there are different points : >>> >>> - firstly, it is not easy to profile >>> >>> - it seems that when we move the mouse on the visualisation then it draws everything each time we move the mouse. >>> >>> And of course the biggest the visualisation is, the hottest the computer is to be. >>> >>> So maybe we should either, only draw the visible things (we must know what is visible easily), >>> >>> or we should draw the whole visualisation as a picture (bitmap or svg ) in a buffer and then just navigate in it, and keeping a list of visible things (not to be drawn but to be checked for interactions). >>> >>> >>> I think the picture is a good solution (maybe not a perfect one) since refreshing a picture is fine easier than redrawing the whole visualisation. >>> >>> And we should only draw changing elements with another color when dragging them. >>> >>> >>> What do you think about that ?? >>> >>> >>> Regards >>> >>> Mathieu >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Improving Roassal Scalability
|
|
In reply to this post by MathieuDehouck
ROView puts its elements in an OrderedCollection, doesn't it?
Might using a QuadTree help? Stephan _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Improving Roassal Scalability
|
|
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
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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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, [hidden email] 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: > > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
| Free forum by Nabble | Edit this page |