QGraphicsScene and scale independent graphics
-
We have a QGraphicsScene that uses the BSP tree to rendering a combination of normal QGraphicsItems and items that dynamically change their rendering based on the viewport and device scale. We do this so that certain objects appear fixed; they always render at a certain size relative to the viewer regardless of the scene transformations. So if you have two different views of the same scene they will render differently in each view assuming the views look at the scene from different scales. They will appear to take the same number of pixels in each view, however.
I am really concerned about this approach because we have had a few crashes where the bsp tree has stale data. The QGraphicsItem getBounds doesn't specify a projection transformation so it cannot take the particular view transform into account.
I am slowly coming to the conclusion that rendering all the scale independent information in a second pass by overloading the QGraphicsView::paint method is the best option. I think putting those objects in the QGraphicsScene is just causing issues and furthermore we are getting rendering artifacts with them and after researching the QGraphicsScene code and the BSP code a small bit I don't think these are avoidable due to the limited information the scene can take into account when it asks for bounds.
What is the best way to go about this?
Chris
-
I remember having similar issues with an editor which we implemented based on QGraphics...
Our conclusion after wasting some weeks/month on crashes and painting artifacts was that we disable the BSP-Tree and switch to FullViewportUpdate (this wastes a lot of performance, but it works) ... thought, that was qt4.6 (or 4.7), but I doubt that someone made the BSP more robust in the last updates ...
btw. we also tried to directly painting in QGraphicsView (as overlay above the scene) for some things, but this is also a really rough solution (as you loose all the comfort that you have by using a scene, so minimal visualizations already require huge chunks of sourcecode)... btw. if someone has a better idea, I'm also interested in finding a new way (as a similar project comes up in the next months)