Closed Bug 392394 Opened 17 years ago Closed 9 days ago

jpeg_fdct_islow thread uses a lot of CPU power when looking at a flash video.

Categories

(Core Graveyard :: GFX, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: agmisc+bugzilla, Unassigned)

References

()

Details

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

When looking at a flash movie (youtube and similar) or a flash game firefox uses a lot of CPU power. Using Process Explorer I've found the thread responsible to be firefox.exe!jpeg_fdct_islow. When I don't have a tab with any flash-content it's still using the most CPU power of all Firefox threads, but only a negligible amount. When I start a flash movie it immediately rises to 30-40% of my total CPU time (3.0 GHz P4). If I pause the movie it lowers to 10-15%. When I close the tab the CPU usage lowers to more normal levels.

Looking at pages with several embedded movies is increasingly difficult as more and more movies are loaded the lower I get on the page.

I've tried both my usual installation of 2.0.0.6 and a portable installation of 2.0.0.5, same result.

I also tried the newest 3.0 alpha, 3.0a8pre. Got almost the same result, the CPU usage is about the same, but the thread using it is firefox.exe+0x157d.

I have looked at the call stack of the jpeg_fdct_islow thread, but it's different almost every time. The only functions that seem relevant and is reoccurring quite frequently are NPSWF32.dll!native_ShockwaveFlash_TCallLabel and NPSWF32.dll.

Reproducible: Always

Steps to Reproduce:
1. Open a page with flash video or similar flash content.
Actual Results:  
CPU usage rises to about 30-40% on a 3.0 GHz P4.

Expected Results:  
Much lower CPU usage.
Sample stack trace:
ntdll.dll!KiFastSystemCallRet
RPCRT4.dll!NdrClientCall2+0x9b1
MMDevAPI.DLL!DllCanUnloadNow+0x18b
MMDevAPI.DLL!DllCanUnloadNow+0x130
MMDevAPI.DLL!CheckAudioRedirection+0x1c
WINMM.dll!timeEndPeriod+0x171a
WINMM.dll!timeEndPeriod+0x1589
WINMM.dll!waveOutUnprepareHeader+0x35
msacm32.drv!wodMessage+0x778
msacm32.drv!wodMessage+0xa6
WINMM.dll!waveOutOpen+0x6c4
WINMM.dll!waveOutUnprepareHeader+0x54
NPSWF32.dll!native_ShockwaveFlash_TCallLabel+0xd5a3
NPSWF32.dll+0x64d3e
NPSWF32.dll+0x51f4c
NPSWF32.dll+0x56fc1
NPSWF32.dll+0x564ce

And one more:
NPSWF32.dll+0x4aa7f
NPSWF32.dll+0x50560
NPSWF32.dll+0x51844
NPSWF32.dll+0x51f12
NPSWF32.dll+0x56fc1
NPSWF32.dll+0x564ce
NPSWF32.dll is the flash plugin itself, what should we do here ?
It seems to me that you have to report that to Adobe and not here and that this bug report is invalid.

Well, as I mentioned, the problem isn't in npswf32.dll, the problem is in firefox.exe!jpeg_fdct_islow. npswf32.dll is in the call stack in some cases, but not always, and even if it always were in there a dll shouldn't wreck havoc with firefox. As can be seen in the screenshot npswf32.dll uses only a couple of percent of the CPU.
try a bug search for the other jpeg_fdct_islow bugs
(In reply to comment #5)
> try a bug search for the other jpeg_fdct_islow bugs
> 

I did that before posting this, and I don't think they're the same as this. The other bugs happens when Firefox is sitting idle, in my case it only happens when playing a Flash-file, most common a youtube-video. The more Flash-videos that are embedded in a page the more CPU-power is needed. If a page has about five embedded youtube-videos I can't watch any of them since the CPU can't cope. But as soon as I close the tab or navigate to another page the CPU usage sinks to normal levels.
It doesn't seem like anyone is interested in this one, but it hasn't been resolved. I've downloaded the latest Flash player, no change at all.

The problem comes as soon I open a page with a Youtube-video, and as soon I close the tab or navigate to another page the problem disappears.
Performance graph of Firefox.exe showing what happens when I navigate away from a page with a couple Youtube-videos. No video was playing.
New screenshot of the threadlist, using Firefox 2.0.0.11 and Flash player 9.0.115.0
Attachment #276846 - Attachment is obsolete: true
what does the main firefox.exe thread show when the tab is hidden?
what do you see if you use a trunk build?

cpu usage may be video card related or it may be an issue with FF2 - if there is I doubt ti would be fixed.  On trunk I don't see a problem - 5% on a 2.4GHz core duo. Flash Player 9.0 r47. 

Unless cpu usage is somehow related to a firefox behavior or function, like cpu doesn't drop when the tab or window is hidden (which it doesnt), then it's not a firefox issue.  as for the module, I'd guess the flash rendering uses jpeg_fdct_islow and flash is just feeding it frames.
I'm not sure what you mean by hidden, but the high CPU usage remains when I minimize Firefox and when I switch tab. I can't switch tab with the mouse though, I need to use Ctrl+Tab.

I downloaded Firefox 3 beta 1 Rev 2 portable from portableapps, and the same problem occurs there. The thread using the resources isn't jpeg_fdct_islow though, it's firefox.exe+0x157d. The included flash is flash 9.0 r115.
hidden as in not visible. 

excellent that you got the latest versions.  but graphs and comments are are not useful unless you cite URLs of pages that are loaded.  

please start FF in safe mode, and give a full list of steps used to reproduce your issue from start to finish :)
Any site with embedded youtube-videos show the same thing. This one for example: http://popsci.typepad.com/popsci/gadgets/index.html

It doesn't start as soon as I load the page, I have to scroll down to the videos so they load as well. The further down I scroll, the worse it gets. As soon as I navigate to another page or close the tab the problem disappears.
Component: General → GFX
Product: Firefox → Core
QA Contact: general → general
Good testpage here: http://www.lanik.us/misc/ff-flash-test.html
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
We always decode on the main thread, so seeing jpeg_fdct_islow show up on another thread generally means that the symbol data is missing for that thread and it's picking up just the closest symbol.  Getting a stack for the thread that's consuming the CPU may be useful.
minusing until we can get some more info here
Flags: wanted1.9.0.x+
Flags: blocking1.9?
Flags: blocking1.9-
FWIW, my FF3b4 gets extremely slow when I load http://www.lanik.us/misc/ff-flash-test.html as well.  CPU usage spikes and browser is unresponsive until I close the tab.  This is an Linux 2.6.23-gentoo-r3 running KDE 3.5.8 on an Opteron 165.
http://www.vestas.com causes FF3b5 to peg the CPU. The problem begins as soon as FF displays the flash video at the top of the page. According to Process Explorer, the thread that's using the CPU is firefox.exe+0x15a0.
(In reply to comment #19)
> http://www.vestas.com causes FF3b5 to peg the CPU. 

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2) Gecko/20081125 Firefox/3.1b2  Shockwave Flash 9.0 r45

do you see the problem with a current version of firefox, and flash 10


  Vladimir comment #18
> FWIW, my FF3b4 gets extremely slow when I load
> http://www.lanik.us/misc/ff-flash-test.html as well.  CPU usage spikes and
> browser is unresponsive until I close the tab.  This is an Linux
> 2.6.23-gentoo-r3 running KDE 3.5.8 on an Opteron 165.

need a smaller, more QAable testcas
Product: Core → Core Graveyard
I've been experiencing this problem, or something very similar at least for several months in Linux with firefox 3.x on both x86 and x86_64 architectures.

I have a reproducable test case that I can make the bug trigger or go away at will, at least for the problem that I am personally experiencing.  It is related to the firefox "zoom" page feature.  If I go to YouTube, reset zoom to 0 by hitting CTRL+0, then watch a video - it plays back more or less perfectly as I expect it to.  However, if I zoom in on the page using the CTRL+SCROLLWHEEL, then reload the page - the entire web browser freezes for about 1 minute with the page blank white with a black box where the video should go.  Sometimes it is only 10-20 seconds, but usually a minute.  When video does start showing, I get a few frames then it freezes again while the video buffers.  After another minute the video finally starts playing normally, however it is a minute or so into video now and I've missed half of it.  Winding it back to the beginning, causes it to freeze again.

Also, switching tabs takes a good 10-30 seconds or more.  While all of this is happening, my X server is pegging the CPU at up to 99% CPU usage whenever the Youtube page is the current tab.  This happens on many other video sites as well, and seems to occur to a lesser extent on any web pages that have any serious amount of flash content on them.

If I reset the zoom feature to 0 though for the given page, and reload the video, it works like a charm.

I am using a 1.6GHz AMD Hammer CPU (first generation) with 512MB of RAM, and firefox is using about 230MB.  I'm using an ATI Radeon 9600Pro AGP, and have played around with my X configuration to see if I could affect performance of firefox in any way but as of yet to no avail.  (Tried XAA/EXA, DRI/noDRI, and various other options.

Currently I'm running CentOS 5.2 with firefox 3.0.7 however the problem occured in Fedora 10 as well on both x86 and x86_64 and was much more severe.  I haven't tested my workaround in Fedora however, but the workaround works in CentOS 5.2.

Oddly enough, I installed firefox 3.0.7 for Windows in wine and it works fairly smoothly, including watching Youtube videos.  Using the zoom feature in Windows firefox under wine does not seem to cause this problem however video playback does turn into a bit of a slideshow.

Someone posted a few links above saying if they play a Youtube video embedded in another web page the problem does not happen.  I tested their links and had the same result - however when I zoomed that page, the problem happens on it too, which is what leads me to beleive this is tied to the "zoom" feature.

I'm guessing that whatever extra work has to be done due to the zoom feature, it is causing firefox to bang **** the X server at least for a while.

I tried to strace firefox, but it caused my machine to become completely unresponsive and I had to reboot.  I'd like to also trace the X server but don't have another system accessible that I could use for debugging/troubleshooting currently.

Please try my workaround everyone and respond back whether it changes the problems you are experiencing (whether on Linux/Windows/Mac/whatever).  I'm thinking it might be some combination of an older/slower CPU, plus higher demands on the X server from firefox when zoom is enabled, although that doesn't really explain the issue occuring in Windows for some people.

Could be different issues at play.
Status: NEW → RESOLVED
Closed: 9 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: