User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12) Gecko/20100101 Firefox/4.0b12 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12) Gecko/20100101 Firefox/4.0b12 If I display o2online.de the CPU load increases to MAX. If the tab is in background everything is fine. Reproducible: Always Steps to Reproduce: 1. open o2online.de with Firefox 4.0b12 Actual Results: CPU load is at 100% for one core Expected Results: CPU load should decrease immediately after load (like it does using Firefox 4.0b11)
This bug is also reproducible on WinXp Mozilla/5.0 (Windows NT 5.1; rv:2.0b13pre) Gecko/20110227 Firefox/4.0b13pre
Regression range on WinXp: Last Working: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110216 Firefox/4.0b12pre http://hg.mozilla.org/mozilla-central/rev/8812253737ce First Broken: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110217 Firefox/4.0b12pre http://hg.mozilla.org/mozilla-central/rev/b4aa47ca42c1 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b4aa47ca42c1&tochange=8812253737ce
wfm with SM trunk and FF4.0b12 on win7 Does it work in the Firefox safemode: http://support.mozilla.com/en-US/kb/Safe+Mode ?
CPU load also increases in safe mode as well as with a completely new profile and also with new profile and safe mode. No differences for me.
Is your graphic acceleration activated ? Please post the graphic section from about:support.
Matthias is your window Maximized because on XP is reproducible only if the ff window is maximized Graphics Adapter DescriptionIntel(R) 82865G Graphics Controller Vendor ID8086 Device ID2572 Adapter RAM Unknown Adapter Drivers ialmrnt5 Driver Version126.96.36.19910 Driver Date4-15-2003 Direct2D Enabled false DirectWrite Enabled false (0.0.0.0, font cache n/a) WebGL Renderer(WebGL unavailable)G PU Accelerated Windows0/1
Looks like Direct2D has been activated but blocked and DirectWrite is disabled. Here the information: Karten-Beschreibung NVIDIA Quadro FX 770M Vendor-ID 10de Geräte-ID 065c Karten-Ram 512 Karten-Treiber nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Treiber-Version 188.8.131.5221 Treiber-Datum 6-16-2009 Direct2D aktiviert Wurde auf Grund Ihres Grafiktreibers blockiert. Versuchen Sie, Ihren Grafiktreiber auf mindestens Version 257.21 zu aktualisieren. DirectWrite aktiviert false (6.1.7601.17514, font cache n/a) WebGL-Renderer Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541) GPU-beschleunigte Fenster 0/1
I suggested the safemode because I wanted to test Graphic acceleration, JIT and the addons (they are all disabled in the safemode). No difference in the safemode= can't be addons, jit is unlikely because I can't reproduce it -> your hardware acceleration must be disabled (or you have a different flash version). I can confirm 25% CPU on my 4 Core system with Firefox 4.0b12, maximized window and hardware acceleration disabled.
blocking2.0: --- → ?
Component: General → Graphics
QA Contact: general → thebes
Summary: Full CPU load as long as o2online.de is displayed → Full CPU load as long as o2online.de is displayed with hardware acceleration disabled
This error also occurs on my private system (WinXP). On this machine Graphic acceleration is also not active. Direct2D aktiviert false DirectWrite aktiviert false (0.0.0.0, font cache n/a) In difference to the other reports for me it also occurs when the window is not maximized, but only "large enough". So for a small window everything is fine, but as it gets large enough the high CPU load occurs (50% on a dual core system) although the window is not maximized.
Speculatively hard blocking as the regression range and description implies that this might be due to the recent changes to plugin compositing.
Assignee: nobody → jones.chris.g
blocking2.0: ? → final+
I can also reproduce on win7 with GPU rendering off, on the latest nightly. Also happens on my linux 64-bit desktop.
Confirmed that this is a regression from bug 626602. To reproduce, the window doesn't need to be full-screen; just the header starting from the O2 image at the top-left of the page extending over to the "Suche" bar needs to be visible. The CPU is spiking because we're constantly updating the background behind the plugin instance that implements the menu. I'm not sure why we're doing that yet.
(Oops, lost this in the mid-air.)
We need to be able to test for NO_UPDATE_LAYER_TREE distinct from INVALIDATE_NO_THEBES, and there's only one unique user of NO_UPDATE_LAYER_TREE, so I went with the smaller patch to just fix that user. The mac-specific plugin/layers code here had essentially duplicated nsIFrame::InvalidateLayer() for reasons I don't understand. I went ahead and fixed that.
This whitespace fix obscured the previous patch, so I split it out.
Attachment #515837 - Flags: review?(roc)
Attachment #515836 - Flags: superreview?(roc) → superreview+
Attachment #515836 - Flags: review?(tnikkel) → review+
Attachment #515837 - Flags: review?(roc) → review+
Comment on attachment 515836 [details] [diff] [review] INVALIDATE_NO_UPDATE_LAYER_TREE should subsume INVALIDATE_NO_THEBES_LAYERS This is a no-brainer.
Attachment #515836 - Flags: approval2.0+
Whiteboard: [hardblocker][has patch] → [hardblocker][has patch][needs landing]
On Ubuntu 10.10 it also happens.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [hardblocker][has patch][needs landing] → [hardblocker][has patch]
You need to log in before you can comment on or make changes to this bug.