On 01/24/2013 08:35 AM, Samuel Rødal wrote: > 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.
I didn't notice that this was the development@ list. Please use the interest@ list for questions that are about using Qt and not about developing Qt. -- Samuel _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
