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
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, mathieubmddehouck@mailoo.org 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 (bitmapor 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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, Fabrizio
2013/6/26 Vanessa Peña Araya van.c.pena@gmail.com
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, mathieubmddehouck@mailoo.org 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 orsvg ) 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 listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch 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 van.c.pena@gmail.com 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, mathieubmddehouck@mailoo.org 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
Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 alexandre.bergel@me.com 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 van.c.pena@gmail.com 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, mathieubmddehouck@mailoo.org 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
Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Fabrizio Perin -
mathieubmddehouck＠mailoo.org -
Stéphane Ducasse -
Vanessa Peña Araya