On 01/23/2013 08:02 PM, Jose wrote: > Hello, > > I am developing a Qt-based application. The main part of the application > if a QGraphicView widget > whose scene is populated with thousands (sometimes hundreds of > thousands) of QGraphicItems, more > precisely a subclass because to overload the "paint" function in order > to draw a circle for each item.
Each call to paint() involves a bit of set up / tear down of the QPainter state as well as the overhead of a virtual function call. You can get rid of some of the set up / tear down cost by setting the DontSavePainterState optimization flag on the QGraphicsView, but then you have to make sure that your items don't rely on a clean painter state (and that they don't change the painter state). Also, make sure you don't have QGraphicsItem::ItemClipsToShape set on any item in the parent chain. Still, it's always going to be faster to draw all the circles as a single QGraphicsItem. > The problem is that the application basically freezes when I load a lot > of items. > > Is this normal? Is there a limit on the number of QGraphicItems that > you can visualize? > > Also, if you want QGraphicItems to respond to a certain signal, do you > need to connect > the signal to an slot for each of the items? Doesn't sound like you want to do this for a hundred thousand items. Why not have a controller item? > As an alternative, I can draw all the dots as a one single QGraphicItems > which will solve > the problem, I guees, but I would lose the interaction with the dots > individually. Unless you allow interaction with the dots via that controller item. -- Samuel _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
