On Mittwoch, 3. April 2013 15:50:46 Clemens Brunner wrote:
> On 04/03/2013 03:24 PM, Andreas Pakulat wrote:
> > first of all, QTimer gives you no guarantee that it'll fire exactly
> > after the given amount of time. In particular not with such small
> > timeouts and when having non-trivial paint functions like yours. QTimer
> > is bound to the event loop, hence cannot fire if the loop is being
> > blocked by something. If you simplify the paint function the effect will
> > be much less dramatic.
>
> Yes, I know that QTimer is not a high-precision timer. This is also not
> a problem in my example, since I can live with a bit of jitter.
>
> > That being said, here with Qt4.8 even a full-screen window will not
> > cause a significant slowdown, except during the resize phase. Once the
> > resize is done the timer fires every 25 ms again. So I guess the
> > calculation inside the paint function simply take some time and once the
> > widget doesn't resize anymore the paint function is not called anymore.
>
> OK, but (1) I was not referring to the resize phase, and (2) this only
> works well on Windows. On Mac OS X and Linux, the timer depends on the
> size of the window being updated -- for a full screen window, the timer
> fires every 100ms (not during the resize) because QGraphicsView cannot
> handle the computations within a time frame less than 100ms anymore.
>
> > If you need high precision timers then you'll need to write
> > platform-specific code. QTimer is not meant for that.
> >
> > Why this works better on Windows with Py(Qt/Side) can have many reasons,
> > the whole graphicsstack is different there, the QTimer might be
> > implemented differently there. Maybe windows delays the painting during
> > resize somewhat more so that there are less repaint-events given to Qt
> > or maybe the functions used in your paint() are more optimized on Windows.
>
> Well, the fact that it does work equally well on all three platforms
> when I use Qt directly from a C++ program indicates that this is an
> issue with the Python wrapper, and not a different implementation within
> the Qt framework. Furthermore, since PyQt and PySide produce a Python
> wrapper that does work just like its C++ counterpart under Windows makes
> me think that it must be an implementation detail of PyQt/PySide that
> could probably be fixed.
What you see is possibly related to the default Qt graphics engine:
when using:
QT_GRAPHICSSYSTEM=opengl python graphicsviewtest.py
the values are oscillating around 150 here. With "native" and "raster", it's
back to 25: openSUSE 12.2/x86_64, 2560x1600x32, nvidia proprietary graphics,
python: 2.7.3
sip: 4.14.5-snapshot-054f1676c300
qt4: 4.8.4
pyqt4: snapshot-4.10.1-3ade65901e3e
Cheers,
Pete
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
