Dear Tulip aficionados,
Tulip Lib (leader P & D):
1- Integrate new Graph data structure from Tulip labs tests. We need to think about naming of that data structure (BasicGraph doesn't seem to be a correct name). That class is used by the new Observable mechanism and thus must be integrated. Furthermore, several new algorithms are based on that data structure thus we will need it to gice access to these plugs-in. We should also re-implement algorithm that have a complexity greater than O(n log (n)), using that data structure instead of the General/Observable/Sub-raphable/metagraphable one of Tulip can increase the performance by a factor 10x (or more). I specially think to the Betweeness centrality.
2- Integrate the new Observable mechanism from tulip labs, that mechanism is more general and robust that the really old one of Tulip. That new mechanism will limit the number of bugs due to observation; furthermore it will enable to display the state of all observer/listeners/observable at a specific time for debugging.
3- Integrate new Iterators from tulip labs, there is several interesting iterators here. All iterators documentation form the tulip trunk should be double check to look like the new documentation used in the tulip labs iterators.
Tulip ogl (leader M & A):
1- The major bottleneck of the rendering engine in the 3.5.x is the label rendering. I have double check the FTGL documentation and it seems that Tulip re-implement a part of the FTGL library. All the formatting stuff done in tulip with the composite design pattern could be removed and we could use the FTGSimpleLayout instead. It seems that most of the needed functionalities are already here. Removing the current Tulip system will reduce a lot the number of lines of code and also should speed up label rendering. The only problem is that we won't have support of html labels anymore (I think that nobody uses that, and it would be re implemented with a specific FTGLLayout if needed in a future project).
2- A nice work has been done in the 3.5.0 version to improve documentation; however more should be done here, because it is critical if one want to implement a new view/glyph/interactor.
3- There is recent work from I and Antoine (not in tulip labs yet) that enable to manage border of polygon with the GPU. Using that technique instead of the lineWidth function of OpenGl could improve a lot the image we are generating. Furthermore, it also enables to texture the border and thus to create awesome rendering effects… We could use that new functionality at least for standard 2D glyphs (circle, square, triangle, pentagon …)
4- Like in all the Tulip versions: improvement of performance should be done here.
5- There is an explicit link to XML libraries in several interfaces that should be removed.
Tulip Qt (leader L & J):
1-There is a major problem with the PropertyWidget of Tulip when we treat graph with more than 300K nodes/edges, we should integrate results from tulip labs (Ludwig & Jonathan) that uses more recent Qt feature.
We are working since a while on the use of QGraphicsItems, it seems that we all agree that this feature will change our lives :-), thus I propose to integrate it in the 3.6.x version.
2-The current views are a little bit difficult to use because each of them has got a specific toolbar a specific set of options etc… We should re integrate these options into the views themselves. That change will simplify a little bit the task of the Perspective Plugin. It will also enable to create state of the art HCI for views (especially more compatible with touch screen).
3-There is a nice work of Charles on TouchScreen management, in standby. These changes (it is not too much) can be merged in the Tulip 3.6.x series.
I think that this road map is realistic since we only merge existing results that we have. Let me know what you think about it and add what you want :). Of course it is just a proposition; we will speak about that on Friday. Any feedback before the Friday meeting are welcome.
Best wishes and thx again for that awesome 3.5.0 release.
It seems that we all agree for that first roadmap :-). During the last dev-meeting we added the following things:
Metric and Clustering Plugin (leader F & D):
- Split all clustering code in order to first compute a Metric on nodes and then (if asked by the user to) create the subgraphs or aggregation/groups.
- Add several clustering algorithm developed by the Tulip Labs (MCL, Louvain, Fast MQ etc…)
- Change the way we store the results of computed Measure, (use the same technique that we use in the Tulip Lite Perspective), it will reduce a lot the number of operation needed by end user when they need to compare diffrent measure.
Thats all for today
I've progressed a lot on the new Observable model, my commit is ready to be sent, I'm just waiting for a go or nogo signal. Almost all the trunk is affected by that change (I've modified all necessary files even thoses included in the Tulip Labs restricted are).
The work is not finished, but that first merge will enable you to begin to work on that new system. (All the GraphObservable XXXObseravble things are still using the old system).
Log in to post a comment.