I think you can setup a proper QGLWidget, depending your needs... but it's pretty ok.
Those are the major issues, but there are still more minor improvements:
- Use the proper viewportUpdateMode. It's better if you test, test, test, test and test it again. In my opinion
fullviewportUpdateMode works better in most cases when we are talking about videogames. The device won't
be trying to guess what to paint, what he shouldn't paint and you will surely have some animations on screen (in
the end it was going to paint almost everything, so "stop calculating and draw it all!").
- DON'T USE UPDATES IN YOUR GAME LOOP: actually, if you can, don't use updates. It
schedules a redraw, what means he will think twice what to draw. And he will paint on screen when he's in
the mood. Let Qt paint whenever he wants to.
- Flag "dontsavepainterstate". If we are not using brush-pens... we don't care if the painter is reset each
time Qt paints.
- setframestyle(0): less to paint.
- setAttribute(Qt::WA_TranslucentBackground, false): seems like it was activated by default.
- Choose the best setItemIndexMethod for your scene (test, test, test, test). You don't like to have a BSP
tree if you don't need it.
- itemhasnocontents: if you want an invisble item, this is the best choice. In my case, this means all my
bounding items, which means 95% of the items on the screen won't try to calculate how to be drawn.
- itemcoordinatecache: the item will be store in cache and the paint event won't be called again if you don't
force it (another good reason: don't call an update). In my case, the backgrounds are set as
QGraphicsPixmapItem... it takes 5 msecs to be drawn. Storing it on cache improves the performance.