27 Jun
2013
27 Jun
'13
7:06 p.m.
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(a)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(a)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(a)mailoo.org wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev