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

List:       kfm-devel
Subject:    Re: Turbo gif
From:       Koos Vriezen <koos.vriezen () xs4all ! nl>
Date:       2002-04-02 20:40:46
[Download RAW message or body]

On Tue, 2 Apr 2002, Dirk Mueller wrote:
> On Die, 02 Apr 2002, Koos Vriezen wrote:
>
> > Interesting objection, maybe replacing repaintRectangle to updateContents
> > in RenderImage::setPixmap line 171 then.

Replacing repaintRectangle with updateContents would mean emulating the
repaintRectangle call tree, which is bad maintainable, thus a bad idea.
(don't come with ideas after breakfast when being already late for work ;)

> > Do you have any other ideas for timer events not delivered in this case?
>
> Well, I still don't understand the problem I'm afraid.. which gif is causing
> these problems ?

Well, its described below, meaning a page with a lot of the (turbo) gif
movies is flooding khtml with setPixmaps calls. On mine AMD 300, only one
of the tiles (from the mentioned page) get rendered, the others doesn't
show up at all. I've added some kdDebug lines and noticed that
KHTMView::scheduleRepaint, called from RenderRoot::repaintRectangle,
creates a timer with time is 0, but the timer events never occur. So no
updateContents is called.
Strangly this page is rendered correct with mozilla with a CPU usage of
50%. Tried it on a P75 with netscape 4.74, renders correctly. But
konqueror, and also the movie example from the qt sources with one (turbo)
gif, uses 100% CPU load.
So I see two problems:
- QMovie calls setPixmaps to often
- If KHTML is flooded with a lot of setPixmaps calls, the scheduleRepaint
  framework drops timer events (on slow machines).

Koos

 ---------- Forwarded message ----------
Date: Mon, 1 Apr 2002 15:42:45 +0200 (CEST)
From: Koos Vriezen <koos.vriezen@xs4all.nl>
Reply-To: kfm-devel@kde.org
To: kfm-devel@kde.org
Subject: Re: Turbo gif
Resent-Date: 1 Apr 2002 13:45:03 -0000
Resent-From: kfm-devel@mail.kde.org
Resent-cc: recipient list not shown: ;

On Sun, 31 Mar 2002, Koos Vriezen wrote:
> On Tue, 19 Mar 2002, Koos Vriezen wrote:
>
> > Can you watch http://www.cometpeetarno.demon.nl/ then?
> >
> Turns out that this ImageReady generated page never gets to the
> KHTMLView::timerEvent (for an AMD K6-300). The timer is already destroyed
> by KHTMLView::scheduleRepaint or discarded by Qt. If I do
>
> --- khtmlview.cpp       2002/03/25 13:30:27     1.463
> +++ khtmlview.cpp       2002/03/31 14:06:09
> @@ -1486,9 +1486,10 @@ void KHTMLView::scheduleRepaint(int x, i
>          d->updateRect = d->updateRect.unite(QRect(x,y,w,h));
>      } else
>          d->updateRect = QRect(x,y,w,h);
> -
> -    d->repaintTimerId = startTimer( time );
> -
> +    if (time)
> +      d->repaintTimerId = startTimer( time );
> +    else
> +      updateContents( d->updateRect );
>  //     kdDebug() << "starting timer " << time << endl;
>  }
>
> page is rendered correctly. Don't know what horror might happen by
> bypassing this scheduler, but so far no troubles. (btw, this is not a
> proposed patch ;)
>
> Comparing the the CPU usage (100%) with mozilla (50%), means its still not
> optimal. Maybe bypassing the repaintRectangle for non-transparent movies?
> Any ideas?

On second thoughts, this will never work because you never know what's on
top of the image.
It would be nice if QMovie wouldn't flood KHTML if the interval
is calculated to zero. QMovie.setSpeed(percentage) isn't much helpfull
either.
So I stick with my first patch. Any objections against calling
updateContents directly in case a document is completed?

Koos





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