[PyQt] QGraphicsView very slow under Linux and Mac OS X
Clemens Brunner
clemens.brunner at tugraz.at
Wed Apr 3 14:50:46 BST 2013
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.
Clemens
More information about the PyQt
mailing list