Hi!
I investigated the problem a bit more, and it seems like it occurs only when
I'm running KDE -- in Gnome, everything works as expected (the difference is
1). Since it is now working on both Windows, Mac OS X, and non-KDE systems, it
is probably related to KDE (maybe the window manager). Fun
Hi!
I think I found the problem:
https://bugreports.qt-project.org/browse/QTBUG-13573
The exposedRect returns the whole window width on Linux and Mac OS X, whereas
it correctly returns only the area that needs to be updated on Windows.
To illustrate this, just add the following line to my exam
On 04/03/2013 06:46 PM, Hans-Peter Jansen wrote:
Which graphic driver do you use? (that doesn't tell us much, since the C++
version behave with the same driver, just for the record..)
xf86-video-intel 2.21.5-1
intel-dri 9.1.1-1
Might be worth to compare the C++ version (that you should publi
On 04/03/2013 05:09 PM, Andreas Pakulat wrote:
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 wi
On Mittwoch, 3. April 2013 17:28:28 Clemens Brunner wrote:
> On 04/03/2013 04:23 PM, Hans-Peter Jansen wrote:
> > What you see is possibly related to the default Qt graphics engine:
> >
> > when using:
> > QT_GRAPHICSSYSTEM=opengl python graphicsviewtest.py
> >
> > the values are oscillating
Le 03/04/13 17:28, Clemens Brunner a écrit :
> On 04/03/2013 04:23 PM, Hans-Peter Jansen wrote:
>
>> 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. Wit
On 04/03/2013 04:23 PM, Hans-Peter Jansen wrote:
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/x8
Hi
On Wed, Apr 3, 2013 at 3:50 PM, Clemens Brunner
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
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 fu
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 fi
Hi,
On Wed, Apr 3, 2013 at 2:15 PM, Clemens Brunner
wrote:
> Hi,
>
> I've also posted this question as a bug report at qt-project.org (
> https://bugreports.qt-project.org/browse/PYSIDE-151), but this is also a
> PyQt issue.
>
> QGraphicsView is apparently very slow under Linux and Mac OS X. I've
11 matches
Mail list logo
