579597 - interactive flash causes browser to barely responds to commands (after landing of retained layers)

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[[not reading bugmail]]

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100715 Minefield/4.0b2pre Glue/4.5 Firefox/3.6.6
Build Identifier: 

Maybe related to retained layers, or just plugins in general, but the video is also large, scrolling and clicking on widgets works fine in Normal mode, but Maximized mode it seems to cause CPU spike and scrolling is very rough, widgets/toolbars are slow to respond.

Reproducible: Always

Steps to Reproduce:
Load page in Normal window mode, see it sort of ok, click on various browser toolbar controls
make window maximized
Actual Results:  
Browser CPU usage spikes and barely responds to mouse clicks or mouse wheel scrolling

Expected Results:  
browser behavior should be similar in both window modes.

Didn't see this being the exact same as D2D bug 558339 as this is with D2D/DW off after retain layers landing.

Comment 1

[[not reading bugmail]]

turning off OOPP didn't make a difference.

Comment 2

[[not reading bugmail]]

Looks like CPU spike is there with both Normal and Maximize mode, so updating summary, but one window mode works fine and the other not.  I also hope to check nightlies before retain layers landing, maybe tomorrow.

Comment 3

[[not reading bugmail]]

This is a regression from retain layers.

Works: Thu Jul 15 14:01:18 2010 -0700
http://hg.mozilla.org/mozilla-central/rev/92339b84d089

Broken: Thu Jul 15 14:12:02 2010 -0700
http://hg.mozilla.org/mozilla-central/rev/e1d7fd5255fd

regression pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=7%2F15%2F2010+14%3A01&enddate=7%2F15%2F2010+14%3A13

It was fine before in both window modes, but now it drops off in maximized mode.

Comment 4

[[not reading bugmail]]

 (In reply to comment #3)
> This is a regression from retain layers.

This should say, from the retain layers push, as I suppose it could also be another bug in that entire push.

Comment 5

[(mostly gone) XtC4UaLL [:xtc4uall]]

FWIW, i checked Roc's Tryserver Builds:
Up to [e-mail]-d5784e62bb98-tryserver-win32 (http://hg.mozilla.org/try/rev/d5784e62bb98) it's okay/WFM.

With [e-mail]-f40a0d62b601-tryserver-win32 (http://hg.mozilla.org/try/rev/f40a0d62b601) it is not.

Delta would be (at least) Checkin Parts 42, 43 & 44 by looking at the Pushlogs.

Comment 6

[alex_mayorga]

I believe I see this or a very similar problem when opening http://www.paseosantacatarina.com/tiendas.html
Using Mozilla/5.0 (Windows; Windows NT 6.0; rv:2.0b3pre) Gecko/20100729 Minefield/4.0b3pre ID:20100729073046

Another symptom I see is that if you right click on the biggest Flash in there the pointer flashes rather quickly or completely disappears and is nearly impossible to click any of the options on the right click menu.

Is this problem the same as described on this bug or a different one?

Comment 7

[[not reading bugmail]]

(In reply to comment #6)
> I believe I see this or a very similar problem when opening
> http://www.paseosantacatarina.com/tiendas.html

It looks like bug 558339 because it was high CPU before retain layers.  

> Another symptom I see is that if you right click on the biggest Flash in there
> the pointer flashes rather quickly or completely disappears and is nearly
> impossible to click any of the options on the right click menu.

That can be a symptom of the UI not responding properly.

Comment 8

[[not reading bugmail]]

(In reply to comment #7)
> (In reply to comment #6)
> > I believe I see this or a very similar problem when opening
> > http://www.paseosantacatarina.com/tiendas.html
> 
> It looks like bug 558339 because it was high CPU before retain layers.  

The only problem is that bug is about the D2D side and this bug is about it during window mode specific, while your bug seems to be a third issue, can you file a new bug for that?

Comment 9

[Bill Lancashire]

Attachment: Screen artifacts

Comment 10

[Bill Lancashire]

See my comment 9 above.

I observed practically all the same issues on my Linux setup.

Build: Mozilla/5.0 (X11; Linux i686; rv:2.0b3pre) Gecko/20100731 Minefield/4.0b3pre

System:
CPU: Athlon XP-M 1870MHz
Graphics Card: Nvidia GeForce 3 Ti200
Linux: Slackware 12.1, kernel 2.6.24.5
Nvidia Legacy Graphics Driver: 96.43.05
Xorg Version: 1.4.2
Cairo Version: 1.8.8

The effects seem quite extreme on my 'low-end' hardware.

In addition I see the black triangular artifacts which constantly change in the 'bubble' video.panel.

Comment 11

[Bill Lancashire]

When I visit the URL cited in Comment 6, I get a total lock-up or freeze of my computer.  Only way to recover was poweroff shut-down.

Comment 12

[Johnathan Nightingale [:johnath]]

Retained layers -> Layout

Comment 13

[alex_mayorga]

(In reply to comment #8)
> The only problem is that bug is about the D2D side and this bug is about it
> during window mode specific, while your bug seems to be a third issue, can you
> file a new bug for that?
Using Flashblock I've managed to pin this down to http://www.paseosantacatarina.com/mapa.swf
Odd thing is navigating directly to http://www.paseosantacatarina.com/mapa.swf the slowdown it's much less evident, but in http://www.paseosantacatarina.com/tiendas.html the slowdown is very noticeable even if just mapa.swf it's allowed with Flashblock

Hope this helps to pin the problem down a bit.

Mozilla/5.0 (Windows NT 6.0; rv:2.0b4pre) Gecko/20100817 Minefield/4.0b4pre ID:20100817040615
Flash 10,1,82,76 installed
Flashblock 1.5.14a

Is another bug still needed or can we change the URL on this one and mark it NEW?

Maybe related: bug 560727, bug 558555

Comment 14

[Benjamin Smedberg]

What do you mean by "maximized mode"? Fullscreen flash, or just making the Firefox window bigger?

I definitely see responsiveness issues on http://www.paseosantacatarina.com/tiendas.html which has wmode="opaque", but I'd like to know whether that's just because the plugin is doing something silly.

Blocking for investigation...

Comment 15

[[not reading bugmail]]

Maximized window mode is clicking on the window's caption button to maximize the browser.  Full screen would be using F11 or the full screen toggler widget which is really slow too.  These pages are also JS heavy.

Comment 16

[alex_mayorga]

FWIW even if less evident I still see slowness when the window is not maximized. I also discovered that reducing the Flash "Quality" to "Low" makes Minefield a bit more responsive.
Mozilla/5.0 (Windows NT 6.0; rv:2.0b5pre) Gecko/20100820 Minefield/4.0b5pre ID:20100820074529

Comment 17

[Jim Mathies [:jimm]]

Are people still seeing this? I'm seeing about 11% normal, 12% maximized / full screen.

Comment 18

[[not reading bugmail]]

yeah, on my hardware of Nvidia 7050, flash is really slow to load, scrolling is little better, and the browser is almost unresponsive, tab switching takes a long time to respond, mousewheel doesn't react and awesomebar doesn't drop down hardly at all.

Comment 19

[Jim Mathies [:jimm]]

(In reply to comment #18)
> yeah, on my hardware of Nvidia 7050, flash is really slow to load, scrolling is
> little better, and the browser is almost unresponsive, tab switching takes a
> long time to respond, mousewheel doesn't react and awesomebar doesn't drop down
> hardly at all.

do you see this regardless of the window state? d2d or gdi enabled?

Comment 20

[[not reading bugmail]]

(In reply to comment #19)
> (In reply to comment #18)
> > yeah, on my hardware of Nvidia 7050, flash is really slow to load, scrolling is
> > little better, and the browser is almost unresponsive, tab switching takes a
> > long time to respond, mousewheel doesn't react and awesomebar doesn't drop down
> > hardly at all.
> 
> do you see this regardless of the window state? d2d or gdi enabled?

yes, but with d2d off, cpu is about 60%+ and with d2d on cpu is about 70%+  I hope JM will also help here.

Comment 21

[Bill Lancashire]

(In reply to comment #17)
> Are people still seeing this? I'm seeing about 11% normal, 12% maximized / full
> screen.

Using: Mozilla/5.0 (X11; Linux i686; rv:2.0b5pre) Gecko/20100828 Firefox/4.0b5pre

I'm still seeing exactly as stated in my Comments 9, 10 and 11 above.

complete lockup of browser controls when http://thebubble.msn.com/ visited with same 'black artefacts' as I gave in my attachment.

Comment 22

[Alex]

Pardon me, but the performance issues you describe have plagued me as well. 

That is,
- Increased CPU use w. D2D & Flash Content (sometimes significantly)*
- Lack of GUI responsiveness w. flash content. (even w/o D2D)**
- Firefox.exe idling @ 20%-50% showing simple flash content. (even w/o D2D)

Are they somehow different from
https://bugzilla.mozilla.org/show_bug.cgi?id=558339
?

* Same behavior with text boxes.
** When navigating away from a page w. CPU hogging flash: FF seems to load the new page first, then kill the flash content from previous page. That is, the CPU intensive content seems to get unloaded last and thus slows down the loading of another page.

Comment 23

[Jim Mathies [:jimm]]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; en-US; rv:2.0b2pre)
> Gecko/20100715 Minefield/4.0b2pre Glue/4.5 Firefox/3.6.6
> Build Identifier: 
> 
> Maybe related to retained layers, or just plugins in general, but the video is
> also large, scrolling and clicking on widgets works fine in Normal mode, but
> Maximized mode it seems to cause CPU spike and scrolling is very rough,
> widgets/toolbars are slow to respond.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> Load page in Normal window mode, see it sort of ok, click on various browser
> toolbar controls
> make window maximized
> Actual Results:  
> Browser CPU usage spikes and barely responds to mouse clicks or mouse wheel
> scrolling
> 
> Expected Results:  
> browser behavior should be similar in both window modes.
> 
> Didn't see this being the exact same as D2D bug 558339 as this is with D2D/DW
> off after retain layers landing.

Please don't mix this bug up with bug 579597, which is a general slow responsiveness w/flash bug.

Comment 24

[[not reading bugmail]]

True, they are different bugs, its faster in Normal mode, but actually much slower than before when I first reported it after the Retain layers build, when changing window modes as listed here:

Recent build:
Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100828 Firefox/4.0b5pre ID:20100828110247
CPU: 40% Normal window/60% maximized window for me


Retain layers build: 
Mozilla/5.0 (Windows; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100715 Minefield/4.0b2pre ID:20100715152722
CPU: 12% Normal window/80% maximized window for me

Comment 25

[(mostly gone) XtC4UaLL [:xtc4uall]]

I can confirm that the Chrome UI now is responding almost equally bad in non-maximized Mode as it has been always in maximized Mode since landing of Bug 564991.

Tested against Mozilla/5.0 (Windows NT 5.1; rv:2.0b5pre) Gecko/20100828 Firefox/4.0b5pre ID:20100828040640 - thus Hardware Accel. is not/can't be related.

Anyone care to find a Regresssion Range of the Worsening for non-maximized Mode?

Comment 26

[Karl Tomlinson (:karlt)]

(In reply to comment #10)
> I observed practically all the same issues on my Linux setup.

Best to track the Linux issues in a separate bug, as much is different across platforms.  The responsiveness issues sound like bug 586162.

Comment 29

[Jim Mathies [:jimm]]

Hmm, that was the wrong dupe. This is a retained layers bug. Fixing up dupes..

Comment 31

[Jim Mathies [:jimm]]

re-requesting blocking final.

Comment 32

[Jim Mathies [:jimm]]

(In reply to comment #24)
> True, they are different bugs, its faster in Normal mode, but actually much
> slower than before when I first reported it after the Retain layers build, when
> changing window modes as listed here:
> 
> Recent build:
> Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100828 Firefox/4.0b5pre
> ID:20100828110247
> CPU: 40% Normal window/60% maximized window for me
> 
> 
> Retain layers build: 
> Mozilla/5.0 (Windows; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100715
> Minefield/4.0b2pre ID:20100715152722
> CPU: 12% Normal window/80% maximized window for me

Dale, are you still seeing this? Wondering if we might have addressed it in subsequent landings.

On the bubble's site, both normalized and maximized window have cpu use at around 7%. I don't see a different between the two window states.

--

Adapter Description
NVIDIA Quadro NVS 295

Vendor ID
10de

Device ID
06fd

Adapter RAM
256

Adapter Drivers
nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um

Driver Version
8.17.12.5912

Driver Date
7-26-2010

Direct2D Enabled
true

DirectWrite Enabled
true

GPU Accelerated Windows
0/1
--

Comment 33

[Csaba Kozák [:WonderCsabo]]

Well, I'm not Dale, but i see this.

firefox.exe: 35%
plugin-container.exe 20%

Opera uses only 18% for everything. :S

I see no difference between window states.

Comment 34

[Jim Mathies [:jimm]]

(In reply to comment #33)
> Well, I'm not Dale, but i see this.
> 
> firefox.exe: 35%
> plugin-container.exe 20%
> 
> Opera uses only 18% for everything. :S
> 
> I see no difference between window states.

Thanks. Does flipping layers.accelerate-all have any effect? How about dom.ipc.plugins.enabled?

Comment 35

[Csaba Kozák [:WonderCsabo]]

layers has no effect

IPC has. With turning OFF that, the CPU usage is "only" 35%.

Anyway, I'm on:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100924 Firefox/4.0b7pre

Comment 36

[Csaba Kozák [:WonderCsabo]]

Okay, i tested a little bit further:

IPC OFF:
layers ON 35%
layers OFF 22%

IPC ON:
layers OFF firefox.exe: 35% plugin-c: 20%
layers ON  firefox.exe: 35% plugin-c: 20%

Interesting. :S

Comment 37

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I suggest waiting and seeing how bug 596451 affects things before we dive into this bug.

Comment 38

[[not reading bugmail]]

Jim, I noticed its still pretty high CPU over 60%/50% split.  If I open another tab, like a new tab and focus that, it drops to single digits.

Comment 39

[Mike Beltzner [:beltzner, not reading bugmail]]

I think that we'll want to resolve this in a beta, not just in an RC.

Comment 40

[Oskar Ivanić (:icecold)]

Seem that Bug 596451 fixes Bug 594959 and all Flash slowness.
But there is still Bug 597416 left to be fixed because testcase website in Bug 594959 with D2D enabled is taking 25% higher CPU using than without it.

I was using latest try server build of asynchronous layer-based plugin painting.

Comment 41

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I do not see such a build on tryserver... But I'll take your word for it :-).

There will inevitably be some extra CPU usage because we simply have to do more work to get the output of Flash copied into D3D buffers. But we definitely need to do some analysis to make sure we're minimizing it.

Comment 42

[Oskar Ivanić (:icecold)]

Actually it doesn't fix it. :(
I tried this build: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/maple-win32/1287085105/

For example try this website with flash: http://www.infinitystamp.net/m-black/
Notice that CPU usage is much higher with or without HW acceleration than on Chrome (8) .
Also when you are on that website, try accessing Firefox button and going into options, you will see how sluggish is.

Anyway it feels that it's more responsive than before, but still slow and sluggish.

Comment 43

[[not reading bugmail]]

Another testcase:
https://genographic.nationalgeographic.com/genographic/lan/en/globe.html

Comment 44

[Jim Mathies [:jimm]]

(In reply to comment #43)
> Another testcase:
> https://genographic.nationalgeographic.com/genographic/lan/en/globe.html

3.6: 29%-36%
4.0: 39%-45%

So we did regress pretty bad. I'll try this with benjamin's latest async painting to see if it helps.

Comment 45

[Leman Bennett [Omega]]

I don't know if this will help, but I did a quick profile of that link:
https://genographic.nationalgeographic.com/genographic/lan/en/globe.html

From AMD CodeAnalyst:

CS:EIP     	Symbol + Offset                                                     	64-bit 	Timer samples 	
0x6cdd2e00 	gfxAlphaRecovery::RecoverAlphaSSE2                                  	       	17.81         	
0x6cee1570 	mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems 	       	4.57          	
0x6cee4520 	nsIFrame::BuildDisplayListForChild                                  	       	3.49          	
0x6cee5df0 	nsBoxFrame::BuildDisplayList                                        	       	2.76          	
0x6cee73e0 	SelectorMatches                                                     	       	2.15          	
0x6cee43f0 	SearchTable                                                         	       	2.08          	
0x6cee3ed0 	PL_DHashTableOperate                                                	       	1.61          	
0x6cee6880 	SelectorMatchesTree                                                 	       	1.55          	
0x6cee58f0 	nsRuleNode::GetStyleDisplay                                         	       	1.34          	
0x6ced92e0 	mozilla::FrameLayerBuilder::DrawThebesLayer                         	       	1.14          	
0x6cee58c0 	nsStyleContext::DoGetStyleDisplay                                   	       	1.14          	
0x6ced1660 	nsIFrame::GetOffsetToCrossDoc                                       	       	1.08          	
0x6cedc3c0 	nsRect::UnionRect                                                   	       	1.08          	
0x6ceee2a0 	nsBlockFrame::BuildDisplayList                                      	       	1.01          	

14 functions, 286 instructions, Total: 637 samples, 42.81% of samples in the module, 0.80% of total session samples

Comment 46

[Jim Mathies [:jimm]]

(In reply to comment #45)
> I don't know if this will help, but I did a quick profile of that link:
> https://genographic.nationalgeographic.com/genographic/lan/en/globe.html
> 
> From AMD CodeAnalyst:
> 
> CS:EIP         Symbol + Offset                                                 
>        64-bit     Timer samples     
> 0x6cdd2e00     gfxAlphaRecovery::RecoverAlphaSSE2                              
>                   17.81             
> 0x6cee1570     mozilla::`anonymous
> namespace'::ContainerState::ProcessDisplayItems                4.57             
> 0x6cee4520     nsIFrame::BuildDisplayListForChild                              
>                   3.49              
> 0x6cee5df0     nsBoxFrame::BuildDisplayList                                    
>                   2.76              
> 0x6cee73e0     SelectorMatches                                                 
>                   2.15              
> 0x6cee43f0     SearchTable                                                     
>                   2.08              
> 0x6cee3ed0     PL_DHashTableOperate                                            
>                   1.61              
> 0x6cee6880     SelectorMatchesTree                                             
>                   1.55              
> 0x6cee58f0     nsRuleNode::GetStyleDisplay                                     
>                   1.34              
> 0x6ced92e0     mozilla::FrameLayerBuilder::DrawThebesLayer                     
>                   1.14              
> 0x6cee58c0     nsStyleContext::DoGetStyleDisplay                               
>                   1.14              
> 0x6ced1660     nsIFrame::GetOffsetToCrossDoc                                   
>                   1.08              
> 0x6cedc3c0     nsRect::UnionRect                                               
>                   1.08              
> 0x6ceee2a0     nsBlockFrame::BuildDisplayList                                  
>                   1.01              
> 
> 14 functions, 286 instructions, Total: 637 samples, 42.81% of samples in the
> module, 0.80% of total session samples

I see the same thing. plugin-container is spending 90% of it's time in the flash module.

Comment 47

[Bas Schouten (:bas.schouten)]

It should be tested if the non-SSE path is faster, although it sounds really unlikely. It's probably much worse.

Comment 48

[(mostly gone) XtC4UaLL [:xtc4uall]]

(In reply to comment #25)
> Anyone care to find a Regresssion Range of the Worsening for non-maximized
> Mode?
Range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=070d9d46d88b&tochange=a4d86c3a3494 (several Checkins by Roc concerning Layers.)

Using a Built from http://hg.mozilla.org/mozilla-central/rev/d253c44465ae (HW Accel. off) the non-maximized Case is mitigated a bit. The maximized Case is unchanged (bad).

Comment 49

[Jim Mathies [:jimm]]

Latest async painting patches didn't help much with this.

Comment 50

[Jim Mathies [:jimm]]

(In reply to comment #49)
> Latest async painting patches didn't help much with this.

The profile did change a bit though:


sse2_composite_over_8888_8888                                                                   	       	20.12         	
pixman_fill_sse2                                                                                	       	4.9           	
fetch_scanline_x8r8g8b8                                                                         	       	2.57          	
nsIFrame::BuildDisplayListForChild                                                              	       	2.2           	
SearchTable                                                                                     	       	2.11          	
nsIFrame::GetOffsetToCrossDoc                                                                   	       	1.65          	
sse2_combine_over_u                                                                             	       	1.47          	
nsStyleContext::DoGetStyleDisplay                                                               	       	1.42          	
mozilla::FrameLayerBuilder::UpdateDisplayItemDataForFrame                                       	       	1.19          	
nsTArray<nsNameSpaceEntry>::IndexOf<nsIAtom *,nsDefaultComparator<nsNameSpaceEntry,nsIAtom *> > 	       	1.05          	
nsLayoutUtils::GetActiveScrolledRootFor                                                         	       	1.01          	
nsRuleNode::GetStyleDisplay                                                                     	       	0.87          	
PL_DHashTableOperate                                                                            	       	0.69          	
mozilla::FrameLayerBuilder::GetOldLayerFor                                                      	       	0.69          	
nsStyleContext::GetStyleVisibility                                                              	       	0.64          	
nsRegion::nsRectFast::IntersectRect                                                             	       	0.6           	
nsRect::ToNearestPixels                                                                         	       	0.6           	
mozilla::layers::CairoImageD3D9::SetData                                                        	       	0.6           	
floorf                                                                                          	       	0.55          	
nsRect::UnionRectIncludeEmpty                                                                   	       	0.55          	
nsIFrame::GetOverflowRect                                                                       	       	0.55          	
nsRuleNode::GetParentBorder                                                                     	       	0.55          	
nsRect::IntersectRect                                                                           	       	0.5           	
nsRegion::SetToElements                                                                         	       	0.5

Comment 51

[thewolf86]

I question whether mouse responsiveness really has to do with high CPU usage. With the test case at https://genographic.nationalgeographic.com/genographic/lan/en/globe.html I've noticed tab switching is slow with the mouse, but if you use ctrl-tab to switch it's much faster. If unresponsiveness was caused by high CPU usage wouldn't it be slow with both input devices?

Comment 53

[Jim Mathies [:jimm]]

http://apps.facebook.com/fishville/index.php?appRef=bookmark&ref=bookmarks&count=3

Fishville is another interesting example.

Comment 54

[Raul Nicolae Malea]

Last example (> https://genographic.nationalgeographic.com/genographic/lan/en/globe.html) is similary with my example: Fishville. Also, more facebook games freezing on my browser: Farmville for example.
Minefield CPU usage is 27% 
Plugin container CPU is 48%

Comment 55

[Raul Nicolae Malea]

Another example: http://superpokepets.com/spp/profile?uid=Dy6cfwb_q7VXEJxc4tDX3Q 
Browser is freezing. Games run very very slow. CPU is high usage. Games blocking more seconds.

Comment 56

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #50)

Was that profile with acceleration enabled? If so, I'm surprised to see pixman at the top of the profile.

I still want bsmedberg to land before we work on this, even if he doesn't fix it, because whatever we do will need to be on top of that.

Comment 57

[[not reading bugmail]]

(In reply to comment #51)
> I question whether mouse responsiveness really has to do with high CPU usage.
> With the test case at
> https://genographic.nationalgeographic.com/genographic/lan/en/globe.html I've
> noticed tab switching is slow with the mouse, but if you use ctrl-tab to switch
> it's much faster. If unresponsiveness was caused by high CPU usage wouldn't it
> be slow with both input devices?

I've noticed this too, as mouse problems doesn't quite = high CPU, yet we have an OOPP bug on slow responsive mouse interaction with flash, but it was fast as heck before, now its slow again.  I didn't even notice the keyboard can be fast at tab switching, not to mention we know resizing or dragging the window will cause it do a full repaint causing the whole UI to respond, but click on UI from the mouse seems to take about the same amount of time every time I try to repeat using the mouse to switch to a tab.  The other part of this seems to be JS scripting interfering with the UI which uses JS too, or that the UI doesn't always update until after the network activity stops or switches.

Comment 58

[Jim Mathies [:jimm]]

(In reply to comment #44)
> (In reply to comment #43)
> > Another testcase:
> > https://genographic.nationalgeographic.com/genographic/lan/en/globe.html
> 
> 3.6: 29%-36%
> 4.0: 39%-45%
> 
> So we did regress pretty bad. I'll try this with benjamin's latest async
> painting to see if it helps.

Final landings from maple today seem to have improved things for me locally. I'm seeing plugin-container at around 30%, firefox proper at around 8%. That puts 4.0 (a local release build) on par with 3.6.

Comment 59

[[not reading bugmail]]

It appears that its better, but given the nature of acceleration, I get slower results if I do not acceleration (d2d or D3d9) but if I use D3D10, its a bit smoother and less CPU for both:

https://genographic.nationalgeographic.com/genographic/lan/en/globe.html
and
http://thebubble.msn.com

The UI lag is better with D3D10 and less CPU (makes sense if its accelerated).  I saw similar results as I was getting around 50% on plugin-container and 13% with just firefox.exe but D3D9 was higher. 

It seems the UI was still choppy without D3D10 acceleration when it still loading everything for the plugin and I noticed all the same issues like the scrollwheel fails to respond right away as does the firefox menu or the awesomebar or tab switching.  If I wait a bit till everything from the network loads, its more responsive.

Comment 60

[Jim Mathies [:jimm]]

(In reply to comment #58)
> (In reply to comment #44)
> > (In reply to comment #43)
> > > Another testcase:
> > > https://genographic.nationalgeographic.com/genographic/lan/en/globe.html
> > 
> > 3.6: 29%-36%
> > 4.0: 39%-45%
> > 
> > So we did regress pretty bad. I'll try this with benjamin's latest async
> > painting to see if it helps.
> 
> Final landings from maple today seem to have improved things for me locally.
> I'm seeing plugin-container at around 30%, firefox proper at around 8%. That
> puts 4.0 (a local release build) on par with 3.6.

Optimized builds from today have fx @ 5%, pc @ 29%.

I'm tempted to mark this as resolved fixed. bsmedberg?

Comment 61

[[not reading bugmail]]

Roc, Looks like the landing for bug 612256 also made a difference here.

Comment 62

[[not reading bugmail]]

(In reply to comment #6)
> I believe I see this or a very similar problem when opening
> http://www.paseosantacatarina.com/tiendas.html
> Using Mozilla/5.0 (Windows; Windows NT 6.0; rv:2.0b3pre) Gecko/20100729
> Minefield/4.0b3pre ID:20100729073046
> 
> Another symptom I see is that if you right click on the biggest Flash in there
> the pointer flashes rather quickly or completely disappears and is nearly
> impossible to click any of the options on the right click menu.
> 
> Is this problem the same as described on this bug or a different one?

alex_mayorga, was there ever a bug filed for this?  I might be seeing it now after the latest landing.

Comment 63

[[not reading bugmail]]

FYI. Looks like some of the scrolling frames/content and shadowlayers updates today also gave these three main sites a shot in arm, which is good news.   I'm seeing better response times from the browser with the scroll wheel, awesomebar, tab switching and menu clicking.

Comment 64

[Oskar Ivanić (:icecold)]

This page eats around 80% of CPU on latest trunk.
Same page uses max 20% of CPU on 3.6 or other browser.
Setting HW acceleration on or off doesn't change a thing.

http://pl.playstation.com/ps3/games/detail/item241009/Gran-Turismo®-5/

Comment 65

[Alice0775 White]

(In reply to comment #64)
> This page eats around 80% of CPU on latest trunk.
> Same page uses max 20% of CPU on 3.6 or other browser.
> Setting HW acceleration on or off doesn't change a thing.
> 
> http://pl.playstation.com/ps3/games/detail/item241009/Gran-Turismo®-5/

Please open a new bug.

Comment 66

[Alice0775 White]

I filed new bug Bug 621495.