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

RESOLVED FIXED

Status

()

RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: mozbugz, Assigned: jimm)

Tracking

(Blocks: 1 bug, {perf, regression})

Trunk
x86
Windows 7
perf, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

9 years ago
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.
(Reporter)

Comment 1

9 years ago
turning off OOPP didn't make a difference.
Summary: flash videos causes CPU usage to spike in Maximized mode; browser barely responds to commands → flash videos causes CPU usage to spike in Maximized mode; browser barely responds to commands, works ok in Normal mode
(Reporter)

Updated

9 years ago
Summary: flash videos causes CPU usage to spike in Maximized mode; browser barely responds to commands, works ok in Normal mode → interactive flash causes CPU usage to spike in Maximized mode; browser barely responds to commands, works ok in Normal mode
(Reporter)

Comment 2

9 years ago
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.
Summary: interactive flash causes CPU usage to spike in Maximized mode; browser barely responds to commands, works ok in Normal mode → interactive flash causes browser to barely responds to commands in Maximized Mode, works ok in Normal mode
(Reporter)

Comment 3

9 years ago
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.
Blocks: 564991
blocking2.0: --- → ?
Keywords: perf, regression
(Reporter)

Comment 4

9 years ago
 (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.
FWIW, i checked Roc's Tryserver Builds:
Up to firefox-4.0b2pre.en-US.win32-rocallahan@mozilla.com-d5784e62bb98-tryserver-win32 (http://hg.mozilla.org/try/rev/d5784e62bb98) it's okay/WFM.

With firefox-4.0b2pre.en-US.win32-rocallahan@mozilla.com-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

9 years ago
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?
(Reporter)

Comment 7

9 years ago
(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.
(Reporter)

Comment 8

9 years ago
(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

9 years ago
Created attachment 461871 [details]
Screen artifacts

Comment 10

9 years ago
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

9 years ago
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.
Retained layers -> Layout
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout

Comment 13

9 years ago
(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
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...
Assignee: nobody → jmathies
Status: UNCONFIRMED → NEW
blocking2.0: ? → final+
Ever confirmed: true
(Reporter)

Comment 15

9 years ago
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.
(Reporter)

Updated

9 years ago
Summary: interactive flash causes browser to barely responds to commands in Maximized Mode, works ok in Normal mode → interactive flash causes browser to barely responds to commands in Maximized Browser Window Mode, works ok in Normal Window mode

Comment 16

9 years ago
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
(Assignee)

Comment 17

9 years ago
Are people still seeing this? I'm seeing about 11% normal, 12% maximized / full screen.
(Reporter)

Comment 18

9 years ago
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.
(Assignee)

Comment 19

9 years ago
(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?
(Reporter)

Comment 20

9 years ago
(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

9 years ago
(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

9 years ago
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.
(Assignee)

Comment 23

9 years ago
(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.
(Reporter)

Comment 24

9 years ago
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
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?
(Reporter)

Updated

9 years ago
Keywords: regressionwindow-wanted
Whiteboard: [see comment 24, 25]
(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.
(Assignee)

Updated

9 years ago
Summary: interactive flash causes browser to barely responds to commands in Maximized Browser Window Mode, works ok in Normal Window mode → interactive flash causes browser to barely responds to commands
(Assignee)

Updated

9 years ago
Duplicate of this bug: 594959
(Assignee)

Updated

9 years ago
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 561288
(Assignee)

Updated

9 years ago
blocking2.0: final+ → ---
(Assignee)

Comment 29

9 years ago
Hmm, that was the wrong dupe. This is a retained layers bug. Fixing up dupes..
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Updated

9 years ago
Duplicate of this bug: 583475
(Assignee)

Comment 31

9 years ago
re-requesting blocking final.
blocking2.0: --- → ?
(Assignee)

Updated

9 years ago
Attachment #461871 - Attachment is obsolete: true
(Assignee)

Updated

9 years ago
Summary: interactive flash causes browser to barely responds to commands → interactive flash causes browser to barely responds to commands (after landing of retained layers)
(Reporter)

Updated

9 years ago
Depends on: 599546
(Reporter)

Updated

9 years ago
Blocks: 599546
No longer depends on: 599546
(Assignee)

Comment 32

9 years ago
(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
--
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.
(Assignee)

Comment 34

9 years ago
(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?
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
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
I suggest waiting and seeing how bug 596451 affects things before we dive into this bug.
Depends on: 596451
(Reporter)

Comment 38

9 years ago
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.
I think that we'll want to resolve this in a beta, not just in an RC.
blocking2.0: final+ → betaN+
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.
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.
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.
(Assignee)

Comment 44

8 years ago
(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.
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
(Assignee)

Comment 46

8 years ago
(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.
It should be tested if the non-SSE path is faster, although it sounds really unlikely. It's probably much worse.
(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).
Status: REOPENED → NEW
Keywords: regressionwindow-wanted
Whiteboard: [see comment 24, 25]
(Assignee)

Comment 49

8 years ago
Latest async painting patches didn't help much with this.
(Assignee)

Comment 50

8 years ago
(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

8 years ago
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?
(Assignee)

Updated

8 years ago
Duplicate of this bug: 607636

Comment 54

8 years ago
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

8 years ago
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.
(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.
(Reporter)

Comment 57

8 years ago
(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.
(Assignee)

Comment 58

8 years ago
(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.
(Reporter)

Comment 59

8 years ago
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.
(Assignee)

Comment 60

8 years ago
(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?
(Assignee)

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 9 years ago8 years ago
Resolution: --- → FIXED
Depends on: 613725
No longer depends on: 613725
(Reporter)

Comment 61

8 years ago
Roc, Looks like the landing for bug 612256 also made a difference here.
(Reporter)

Comment 62

8 years ago
(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.
(Reporter)

Updated

8 years ago
Depends on: 612256
(Reporter)

Comment 63

8 years ago
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.
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

8 years ago
(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

8 years ago
I filed new bug Bug 621495.
You need to log in before you can comment on or make changes to this bug.