[PyQt] QGraphicsView very slow under Linux and Mac OS X

Andreas Pakulat apaku at gmx.de
Wed Apr 3 16:09:54 BST 2013


Hi


On Wed, Apr 3, 2013 at 3:50 PM, Clemens Brunner
<clemens.brunner at tugraz.at>wrote:

> On 04/03/2013 03:24 PM, Andreas Pakulat wrote:
>
 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.


As I said, with Qt4.8 I don't see this here on Linux at all, once the
window is at a certain size the timer fires every 25 ms again. This is on a
somewhat new system with Debians standard Qt/PyQt packages. So its not
necessarily a general problem with Linux/PyQt, but might be limited to the
systems you've used so far to reproduce this or a configuration thing etc.


>  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


It could also be the fact that the various helpers inside your paint are
slower in Python on *nix for whatever reason. Did you try further
simplifying the paint function, for example simply painting 1 line across
the whole rect in multiple steps? Or try out a single step? That way you'd
be able to get rid of all the math which could affect the result too.


> , 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.


I doubt there's much difference in the PyQt/PySide code between Windows and
*nix, after all the C API of CPython is the same on both platforms. One
difference though is the compiler being used for both - at least usually it
is a different one - and of course the platform itself. Does a fixed-length
sleep instead of the paint() function produce a different result on Linux?
Meaning, does it matter what exactly happens in paint or that its just not
a noop?

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20130403/666890a2/attachment.html>


More information about the PyQt mailing list