That sounds like an interesting solution. If you have any code snippets I'd love to see them.

My scene consists of ~100,000 to ~500,000 items which are small, relatively simple, and all slightly different. I've done two things that have improved speed quite a bit since posting the message. The first is that I found that setting QGraphicsItem::setCacheMode(QGraphicsItem::NoCache ) on each item sped up performance quite a bit. I guess the act of caching takes longer and/or too much video memory and slows things down. The second is that following the chips example I've implemented a level-of-detail algorithm in the paint call that simplifies the rendering a bit.

But still, drawing the rubberband is slower than I'd like, and I think drawing it in the manner you've mentioned would be best.

Also, since my scene is essentially static elements, I'm thinking of rendering it to a cropped QPixmap and displaying that anyway. If you can post any code that would great. In particular I'm not sure how to display a widget directly over the existing view and have it line up.

Cheers,

Bob


Quote Originally Posted by d_stranz View Post
I have had the same issue, and I think it is because somehow mouse movement in the rubber band widget is causing redraws in the underlying graphics view. Why, I don't know, since the rubber band widget *should* hide the view from this.

My solution was to take a snapshot of the graphics view into a QImage and put this into a widget that exactly overlays the view below it. Rubber banding takes place in this widget, and when it ends, the overlay widget is hidden and the view below zoomed to the appropriate new rectangle.