Bug 61928 - QMovie: Certain Animated GIFs cause 100% CPU usage
Summary: QMovie: Certain Animated GIFs cause 100% CPU usage
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: qt (Show other bugs)
(Show other bugs)
Version: skipjack-beta1
Hardware: All Linux
Target Milestone: ---
Assignee: wdovlrrw
QA Contact: Ben Levenson
URL: http://www.mplug.org/archive/2002/kon...
: 64167 (view as bug list)
Depends On:
Blocks: 61901
TreeView+ depends on / blocked
Reported: 2002-03-26 00:20 UTC by Warren Togami
Modified: 2007-04-18 16:41 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-03 09:59:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Warren Togami 2002-03-26 00:20:57 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020314

Description of problem:
Certain animated GIF images cause Konqueror to eat 100% CPU.  top shows X using
most of that CPU usage, probably in simply updating the screen.  System becomes
unresonsive until I can close the window.

I think this has something to do with Konqueror not having a minimum delay
period for looping animated GIF.  Mozilla and Internet Explorer enforces a
minimum loop delay so they don't have this problem.  This sample URL image loops
too quickly like this.


How reproducible:

Steps to Reproduce:
1. Visit that URL in Konqueror.

Expected Results:  Konqueror should enforce a minimum animated GIF loop delay.

Comment 1 Warren Togami 2002-03-26 00:39:23 UTC
More information, this is a QT problem.  Please read this URL for details.


Comment 2 Warren Togami 2002-04-03 09:59:17 UTC
lars@trolltech.com said this about that particular GIF image:

> That GIF is really evil. I get (on a dual processor machine) about 
> 70% for X and 50% for the Qt movies example. Even moving the minimum 
> delay up to 50ms didn't make it a lot better. I think we will need 
> some bigger fixes in QMovie to make this work fast.

Comment 3 Bernhard Rosenkraenzer 2002-04-03 11:09:48 UTC
The original problem is fixed, and since the fix for this particular image would need a 
near-rewrite of the QMovie class, it's not doable for this release.

Comment 4 James Manning 2002-04-28 06:23:16 UTC
*** Bug 64167 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.