Rqt Py Trees Laggy

[stonier]

Whenever it gets a new message, the gui 'hang's for a second or two...sometimes more if there is a flurry of new messages.

[stonier]

• generate_dotcode takes about 0.2 seconds at worst.
• qt_dotgraph.dot_to_qt.dotcode_to_qt_items() is the real culprit, takes about 1-2 seconds.
  • digging deeper, in here it is pydot.graph_from_dot_data and subsequently dot_parser.parse_dot_data() consuming 95%.

Started an issue at pydotplus.

[stonier]

Put Scene Generation into a Background Thread

• Relevant methods: _generate_dotcode(), _update_graph_view, _redraw_graph_view.
• Put new messages into a queue, then signal the scene generator
• Let a scene generator be responsible for creating the 'scene' object by popping off the latest in the queue and discarding the rest
• The scene generator returns the scene via a queued connection, and the gui thread just pops this on as the current scene
• The scene generator should also be responsible for the scene cache

Optimise the Dot to Qt Code

It really really ought not to be that long. Must be some bad looping occuring.

[stonier]

Optimising...right now there are a couple of options:

• fix pydot/pydotplus, something really wrong in their graph from dot string parsing (pydotplus#5)
• use xdot's python api, patch it into structures for rqt (perhaps check out willow's original patching of xdot for qt)
• bugger all the rqt qt_dotgraph code, just rebuild that ourselves around the xdot graph structures
• switch to a c++ version of the rqt code and use kgraphviewer's code (it is not as comprehensive as the xdot code) or loqt

[stonier]

Preferring to go with pygraphviz. It has better documentation (also alot of other code for python graphs by networkx) so it's likely to be maintained for longer. Pydot hasn't had anything for ages and its not likely that bug will get fixed. It's also better than xdot, that would require an extensive rework and isn't as extensive an implementation as pygraphviz.

[stonier]

First steps in lagginess resolved as described above. Note that its also moved in the entire qt_dotgraph package as a subpackage. That whole thing is relatively fubar, even though it has an abstraction for pydot and pygraphviz, it's unmaintained and doesn't work.

Python abstractions for multiple interfaces are nice, but so quickly get broken unless you have unit tests galore....I'm disliking python_qt_binding for the same reason these days too.