[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Animation with QPainter
From:       Matt Newell <newellm () blur ! com>
Date:       2006-11-30 20:16:05
Message-ID: 200611301216.05562.newellm () blur ! com
[Download RAW message or body]

On Thursday 30 November 2006 11:35, Uwe Thiem wrote:
>
> No, it is not. He calls update() and does the painting in paintEvent(). My
> suggestions was to do the painting in move() on a QPixmap and bitBlt() his
> QPixmap to his QWidget. That does not cause any flickering because it
> avoids update() and paintEvent().
But there's no difference between painting outside the paintevent or inside 
the paint event, except that the paint event will cause the widget background 
to be cleared, unless Qt::WNoAutoErase is used.  

And if you paint outside the event, you still have to handle the paintevent 
for resizes etc, so i fail to see how painting outside the event is any 
advantage.

>
> If you don't believe me have a look at
> http://www.SysEx.com.na/iwy-1.0.tar.bz2
> Caution, that's about 1MB. Have a look at colour cycling.
>
> > > On the other hand, there seems to be a better way to do it. You are
> > > wasting a lot of CPU cycles for redrawing the pixmap over and over. If
> > > your metronome isn't too big so that memory isn't an issue, you could
> > > pre-draw a couple of pixmaps and simply bitBlt() the next one in
> > > move().
> >
> > He's not regenerating the pixmap each time, just clearing the background
> > and blitting it.  The only cpu cycles to be saved is the wasted
> > background painting where the rect is going to be painted.
>
> True. He could as well have a couple of pre-generated QPixmaps of the size
> of his QWidget and bitBlt() them - *not* using update()/paintEvent().

I'm curious what you have against using update/paintevent?  Once an app gets 
more complicated, using paintevent and taking into account the updated region 
is usually the best way to achieve good performance.


Matt
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]