Speed, transparency, and drop issues with QGraphicsView

[jefferai]

• Firstly it'd be better to maintain just a single QGraphicsScene whereby you can control the updating of the whole scene in an effective way(updating items is obviously faster than whole scene).

Part of the problem was that I was updating the items, but it was redrawing the entire view (even with the background a solid color). If I set QT_FLUSH_PAINT I could see that even though the boundingRect was sane on my items, as they scaled it'd redraw the entire thing.

• Now to get the transparancy with single you can use a QGraphicsPixmapItem and set its Z value higher.

Which is actually harder, because it means we have to set the transparency of everything *else* higher, redraw those, and then draw these items on top with no transparency. I don't really see why this would be faster.

Also, you mention a QGraphicsPixmapItem, but I'd like to use a QGraphicsSvgItem, because I'd like for the items to scale depending on the size of the view. No point in having a huge view with tiny icons, just because they'll look crappy if they scale up. Is QGraphicsSvgItem really that slow to scale?

• Instead of hiding and showing the entire QGV you hide and show the items (pixmap and icons) which should result in enormous performance gain.

Showing and hiding the QGV was never a problem, performance-wise. Scaling the items was. And since the other QGV had a solid background, I expect that doing it with a single QGV and having it blend different items with different Z-values while trying to scale others will result in an enormous performance decrease, not gain.

The "flashing" when doing the show and hide has nothing to do with performance...it doesn't matter if the QGV is tiny or large, it behaves the same. It has something to do with the implementation.

• About Drag & drop, I currently have no problems with my app. FYI i implement the scene's drag and drop methods(not view).
  Probably this is your problem.

This is non-obvious then. Why have view drag and drop methods if they don't do anything?

[Gopala Krishna]

Part of the problem was that I was updating the items, but it was redrawing the entire view (even with the background a solid color). If I set QT_FLUSH_PAINT I could see that even though the boundingRect was sane on my items, as they scaled it'd redraw the entire thing.

Well there should be some problem with your code since it never happens for me(i depend heavily on gv for ele-cad s/w). Have you verified this by printing a message in Item:: paint method ?

Which is actually harder, because it means we have to set the transparency of everything *else* higher, redraw those, and then draw these items on top with no transparency. I don't really see why this would be faster.

Its hard to imagine without a screenshots(i request you some). But what i meant was to use a transparent pixmap(or svg) that covers the view. This pixmap stays in an intermediate layer and the icons are animated in topmost layer. So why should you set transparency for everything ?

Also, you mention a QGraphicsPixmapItem, but I'd like to use a QGraphicsSvgItem, because I'd like for the items to scale depending on the size of the view. No point in having a huge view with tiny icons, just because they'll look crappy if they scale up. Is QGraphicsSvgItem really that slow to scale?

Matrix transformations generally slow up things but gv should be able to handle this(chip demo). I leave this question for someone else to answer since i've less experience with svg.

Showing and hiding the QGV was never a problem, performance-wise. Scaling the items was. And since the other QGV had a solid background, I expect that doing it with a single QGV and having it blend different items with different Z-values while trying to scale others will result in an enormous performance decrease, not gain.

The "flashing" when doing the show and hide has nothing to do with performance...it doesn't matter if the QGV is tiny or large, it behaves the same. It has something to do with the implementation.

Have you tested both the ideas ? It usually won't decrease performance. The chip demo for example works pretty well at different scales(not extremes though). Though this demo doesn't demonstrate layering it proves its management capabilities for large number of items as well as scaling them. You can use QGraphicsItem::ItemIgnoresTransformation flag to avoid scaling the icon items.
IMHO its better to blend items into a single scene(still i feel same)
And for flashing, i don't have a clue.
BTW, i still dont get the "basic idea" about what you are trying to achieve ? Screenshots will surely help me realize your idea.

[Gopala Krishna]

This is non-obvious then. Why have view drag and drop methods if they don't do anything?

Because you can have multiple views for a single scene. So the result of drag and drop done on one view should be reflected in anothers. Hence it provides us "convienient" way to do things.

[fullmetalcoder]

This is non-obvious then. Why have view drag and drop methods if they don't do anything?

They actually do something : they call the method of the scene... And as already pointed out they ensure D'n'D does not mess up shared scenes...