Skip to content
This repository has been archived by the owner on Mar 29, 2024. It is now read-only.

Dikjstra's shortest path ? #39

Closed
renoust opened this issue May 15, 2018 · 3 comments
Closed

Dikjstra's shortest path ? #39

renoust opened this issue May 15, 2018 · 3 comments

Comments

@renoust
Copy link

renoust commented May 15, 2018

Hi everyone,

I'm posting this to keep it as a reminder (it should be easy to adapt from the existing code).

Although Dikjstra is implemented in the path highlighter interaction plugin (https://github.com/Tulip-Dev/tulip/tree/master/plugins/interactor/PathFinder/PathFinding/Dikjstra), path finding between two nodes is one most-useful basic graph manipulation lacking in Tulip core.
DFS and BFS are now directly ported to the python api, so maybe the PathFinding component could become a similar component? (path finding itself does not depend on GUI elements).

Cheers,

@renoust
Copy link
Author

renoust commented Nov 2, 2018

A quick follow up to this comment: is there an efficient alternative to know if a pair of nodes are connected in a graph?
So far, we can use tlp.ConnectedTest.computeConnectedComponents(graph), then test whether both nodes belong to the same list, but it feels a bit of an overkill to this issue.

@p-mary
Copy link
Contributor

p-mary commented Dec 3, 2018

Thanks for your report.
The function
tlp::bool selectShortestPaths(const Graph *const graph, node src, node tgt, ...)
has been recently added to the Tulip C++ api (commit 54691cf) and is also accessible througth the Python binding (commit 35e8942).

@p-mary p-mary closed this as completed Dec 3, 2018
@renoust
Copy link
Author

renoust commented Jan 4, 2019

For reference, here are the details:

tlp.selectShortestPaths(graph, src, tgt, pathType, weights, selection)

:param graph: The graph to compute on. :type graph: :class:tlp.Graph
:param src: The source node of the paths :type node: :class:tlp.node
:param tgt: The target node of the paths :type node: :class:tlp.node
:param pathType: The type of path to consider :type pathType: tlp.OnePath, tlp.OneDirectedPath, tlp.OneReversedPath, tlp.AllPaths, tlp.AllDirectedPaths, tlp.AllReversedPaths (Reversed means directed with reversed direction)
:param weights: A graph property giving the edges weight if weighted paths have to be considered. Can be set to null to select unweighted paths. :type weights:class:tlp.DoubleProperty
:param selection: The graph property to consider as selection. :type selection:class:tlp.BooleanProperty
:rtype: boolean (True if a path is found)
:throws: an exception if one of the source or target nodes does not belong to the graph.

One usage would be:
tlp.selectShortestPaths(graph, tlp.node(1), tlp.node(2), tlp.AllPaths, graph['viewMetric'], graph['viewSelection'])
the paths are stored in the edges (and connected nodes) of graph with graph['viewSelection'] value equal to True.

p-mary referenced this issue in anlambert/talipot Jan 3, 2020
QOpenGL module is marked as deprecated since a while now so it is time
to remove its use from the Talipot codebase and promote the use of
QOpenGL* classes directly integrated in the QtGui module.

The big difference between QOpenGL and QtOpenGL from Qt5 is that all
rendering is performed in framebuffer objects, there is no more direct
rendering in the underlying os windows with its own OpenGL context.

Talipot OpenGL rendering also follows that idiom, all renderings are performed
offscreen using a shared OpenGL context. This also means that there is no
more QGLWidget as viewport for QGraphicsView. Talipot OpenGL scene are
now converted to QImage in order to display them using the default Qt raster
rendering engine. This should fixes the numerous rendering glitches observed
on MacOS.

First thing observed after the migration is a consequent performance boost
in OpenGL rendering when using an Intel GPU on a Linux host machine (especially
when selecting elements, it is now 10 times faster on debian stable).
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants