[OOPP] IPC severely degrades mouse responsiveness with windowless Flash video

RESOLVED INCOMPLETE

Status

()

Core
Plug-ins
RESOLVED INCOMPLETE
7 years ago
3 months ago

People

(Reporter: IU, Unassigned)

Tracking

(Blocks: 1 bug, {perf})

Trunk
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -, blocking1.9.2 needed, status1.9.2 wanted)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100426 Minefield/3.7a5pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100426 Minefield/3.7a5pre

With IPC plugins enabled, responsiveness to mouse input degrades severely for windowless Flash video.  The patch for bug 558629 fixed the windowed case but left the windowless case unresolved.

With Flash Player 10.1 installed, this degradation in responsiveness can also
be observed when trying to pause a video and having it take several seconds
before the video is paused.  My STR focuses on the scroll wheel, but the issues
should have the same origin.

To demonstrate the issue, my STR requires installation of a program called
Volumouse.  It allows for audio volume control using shortcut key(s) + the
mouse wheel.  This is for illustration purposes only, as I know of no other
easy way to show the performance issue. Note: I'm on a 933 MHz P3; thus, the
relative impact of the degradation is really bad.


Reproducible: Always

Steps to Reproduce:
1. Download and install Volumouse (use the self-install executable):
http://www.nirsoft.net/utils/volumouse.html
2. Start Volumouse and configure it as follows:
a) Use the wheel when: Ctrl+Shift are down
d) Component: Play Control; Channels: All Channels; Steps: 2000
c) Set all the other "Use the wheel when:" options to "Disabled"
d) Run Volumouse application in high priority
e) OK
3. Create a new profile and launch Minefield with it
4. Disable IPC plugins and restart
5. Visit the linked URL
6. Once the advertisement finishes playing and the "View" video is playing, use
the hotkey from Step 2a and your mouse wheel to scroll volume up and down. 
Take note of the responsiveness
7. Close the tab with the video loaded or click the home button
8. Reenable IPC plugins and restart
9. Visit the linked URL
10. Again, once the advertisement finishes playing and the video is playing,
use the hotkey from Step 2a and your mouse wheel to change volume up and down. 
Note the relative degradation in responsiveness.
(Reporter)

Updated

7 years ago
Blocks: 478976
Keywords: perf
Version: unspecified → Trunk
What build did you test with? The second set of patches in the original bug should have fixed windowless.
(Reporter)

Comment 2

7 years ago
I tested with this build: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1272300941/

...which has the patch.  It doesn't solve the problem for that ABC News video link.
(Reporter)

Comment 3

7 years ago
What are some other windowless video links I can test with (I'm not sure how to tell the difference)?  Maybe there's a quirk unique to ABC News video?
(Reporter)

Comment 4

7 years ago
Also, msnbc videos have responsiveness issues when I click trying to pause a video.
Hulu is windowless.
blocking1.9.2: --- → ?
(Reporter)

Comment 6

7 years ago
Unfortunately, since I'm in Canada, Hulu is blocked for me.
Blocks: 558629
IU, do you see this problem when the video is paused also, or only when it is playing? And do you see it only when using volumouse hotkeys, or also when clicking on video controls?

Comment 8

7 years ago
Created attachment 441607 [details]
windowless youtube test case
(Reporter)

Comment 9

7 years ago
(In reply to comment #7)
> IU, do you see this problem when the video is paused also, or only when it is
> playing? And do you see it only when using volumouse hotkeys, or also when
> clicking on video controls?

Not a problem is video is paused, because CPU is is not being choked to death.

I see it not just with Volumouse.  As mentioned in comment 4, I also experience it when trying to pause videos on msnbc.
(Reporter)

Comment 10

7 years ago
(In reply to comment #8)
> Created an attachment (id=441607) [details]
> windowless youtube test case

Issue is reproducible with the the attached test case.

Comment 11

7 years ago
(In reply to comment #10)
> (In reply to comment #8)
> > Created an attachment (id=441607) [details] [details]
> > windowless youtube test case
> 
> Issue is reproducible with the the attached test case.

UI, would you mind taking this try build for a spin and see if it improves the issue? 

https://build.mozilla.org/tryserver-builds/jmathies@mozilla.com-testing/

You shouldn't keep this installed, it's setup to severely limit Flash's frame rate.
(Reporter)

Comment 12

7 years ago
No. It doesn't improve the issue.

This hidden window that windowless flash uses, is it a hidden Firefox window or a hidden Adobe flash window?

Comment 13

7 years ago
(In reply to comment #12)
> No. It doesn't improve the issue.
> 
> This hidden window that windowless flash uses, is it a hidden Firefox window or
> a hidden Adobe flash window?

It's a hidden flash window with a class name of 'SWFlash_PlaceholderX'. But that's not the problem here, that last try build brought the frequency of wm-user heart beat events down to around 20/sec.. Whatever you're running into it doesn't appear to have anything to do with that.
(Reporter)

Comment 14

7 years ago
I just noticed something when comparing playback, of the video you attached, between when it's played windowless (per your attachment) and windowed (when I click the video to take me to the Youtube page to play it there)

In the windowless case, the video playback is quite jerky, as opposed to the windowed case where it is smoother.

Comment 15

7 years ago
(In reply to comment #14)
> I just noticed something when comparing playback, of the video you attached,
> between when it's played windowless (per your attachment) and windowed (when I
> click the video to take me to the Youtube page to play it there)
> 
> In the windowless case, the video playback is quite jerky, as opposed to the
> windowed case where it is smoother.

Are you using that build I posted a couple hours ago? If so, that's expected. Uninstall that if you're using it and re-install a regular nightly.

Comment 16

7 years ago
Created attachment 441897 [details]
windowed youtube test case
(Reporter)

Comment 17

7 years ago
(In reply to comment #15)
> Are you using that build I posted a couple hours ago? If so, that's expected.
> Uninstall that if you're using it and re-install a regular nightly.

No.  I was using today's nightly build when I did that particular test.

Comment 18

7 years ago
(In reply to comment #17)
> (In reply to comment #15)
> > Are you using that build I posted a couple hours ago? If so, that's expected.
> > Uninstall that if you're using it and re-install a regular nightly.
> 
> No.  I was using today's nightly build when I did that particular test.

So that sounds like bottlenecks in messaging between the two processes, or the overhead of shared surface rendering, or both.
(Reporter)

Comment 19

7 years ago
The interesting thing is: the difference in video performance between the two test cases is not huge.  It is perceptible on my system, being slow enough, but one could be forgiven for not noticing without a back-to-back comparison.  In contrast, the mouse wheel with Volumouse STR difference is huge.  The slow-down is practically like night and day.
This blocks bug 558629, which is a blocker, so this blocks. However, bsmedberg feels like it's not a common enough case to hard block 3.6.4, and I'm inclined to agree. So needed.

Please renominate if we get more data that changes our understanding of the severity.
blocking1.9.2: ? → needed
(Reporter)

Comment 21

7 years ago
This also severely affects interaction with the msnbc video player.  Videos take a while to start playing and, after you've scrolled the list of videos to the end and try clicking on the player controls, change video categories and continue scrolling, clicking, responsiveness gets worse and worse -- the player taking tens of seconds to respond to any mouse input.
IU: is that using the latest beta build from http://www.mozilla.com/firefox/all-beta.html? (release May 4 2010)
blocking1.9.2: needed → ?
(Reporter)

Comment 23

7 years ago
The nightly trunk builds.
(Reporter)

Comment 24

7 years ago
The beta you linked to is, however, also affected.  I have verified this.

Comment 25

7 years ago
How common is windowless Flash vs windowed Flash?
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 26

7 years ago
(In reply to comment #25)
> How common is windowless Flash vs windowed Flash?

50/50 split between major video sites. (example: youtube: windowed, hulu: windowless)

Updated

7 years ago
blocking1.9.2: ? → .4+
status1.9.2: --- → wanted
UI, step 2d says "Component: Play Control" but "Play Control" is not an option I see in the Volumouse configuration window, so I tried "Component: Volume Control."

I haven't been able to reproduce this yet using the test cases mentioned here, on a VM. I'll try on hardware next.
(Reporter)

Comment 28

7 years ago
(In reply to comment #27)
> UI, step 2d says "Component: Play Control" but "Play Control" is not an option
> I see in the Volumouse configuration window, so I tried "Component: Volume
> Control."

It's probably operating system or sound card driver dependent, so doesn't matter.

> 
> I haven't been able to reproduce this yet using the test cases mentioned here,
> on a VM. I'll try on hardware next.

Real hardware is better -- preferably single core.  If you have multiple cores and you can disable the other cores, that would be good.  Benjamin Smedberg also had trouble reproducing on a VM.
I've now tried on a couple of older, single core, machines (Pentium 1.6ghz), and I can see a response delay in the volume control scrollbar which, depending on how many times I scroll up and down rapidly - especially in full screen mode, will stay up scrolling up and down. During this time you cannot pause the video. You really have to go crazy on the scroll up/down in those machines, though. We don't have older machines off-hand to check if this is more pronounced in older hardware.
(Reporter)

Comment 30

7 years ago
Try the MSNBC video player too, if you haven't tried (but not with the STR I provided above).  It's hard to come up with an STR for it, but when it goes unresponsive, there's usually nothing that can be done until the immediate video stops playing.
I got a hold of a Pentium 2 500mhz machine with less thatn 400mb of memory, and I compared 3.6.3 and 3.6.4 with Flash 10.1 (rc4) and it is hard to tell the difference, because in both instances the browser becomes unresponsive to mouse clicks, very shortly after starting to play the video. I did not install Volumouse.

I can't scroll the page or switch tabs. It's possible that in 3.6.4 the browser became sluggish sooner into the video playback, but it's hard to tell the difference. Maybe I now need to get a hold of a slightly faster machine similar to the reporter's.

Updated

7 years ago
Assignee: nobody → jmathies

Comment 32

7 years ago
I don't think we can hard block on this based on the STR. Removing blocking flag.
blocking1.9.2: .4+ → needed
(Reporter)

Comment 33

7 years ago
(In reply to comment #32)
> I don't think we can hard block on this based on the STR. Removing blocking
> flag.

The STR is meant to provide an easy way of observing the impact of this bug.  It is not meant to convey a general use case.  It demonstrates the impact of this bug on mouse input and browser responsiveness.  There are many other scenarios for observing this bug (e.g. my comment 21 and 30), but they are not as easy to illustrate by STR as with comment 0.

Comment 34

7 years ago
At some point we need to decide if this is a blocker or not as it isn't getting traction. There are other issues that are more easily reproduced and need attention. I'm not saying this bug is unimportant, just that it wouldn't block a release based on the information we have.
(In reply to comment #9)
> (In reply to comment #7)
> > IU, do you see this problem when the video is paused also, or only when it is
> > playing? And do you see it only when using volumouse hotkeys, or also when
> > clicking on video controls?
> 
> Not a problem is video is paused, because CPU is is not being choked to death.
> 

I noticed if I changed the quality level of the flash object I was seeing better response by firefox.  I wonder if this has anything to do with high bandwidth usage and per tab network prioritization bug 514490 code.

Comment 36

7 years ago
My wife plays the "Happy Pets" game on Facebook all the time.  When 3.6.4 came along, she noticed a serious drop in mouse responsiveness when there is a lot of activity on screen.  Once I disabled OOPP for Flash, it returned to normal.  May be related to this bug (someone left a note here: http://etherpad.mozilla.com:9000/ep/pad/export/video-sites/latest?format=html).  Just wanted to bring it up, it may affect other Flash games or applications.
I was amused to see in the release notes it now says "Some slower machines may see degraded mouse responsiveness when viewing certain Flash videos". I'm not sure I'd consider my 2x2.4GHz machine to be slow :)
...having said that, it appears fine in the latest version of Firefox for me (evidently the issue I had has been fixed).

Comment 39

7 years ago
Hi, I've got a comment on the relelase note's item for this bug. There is a typo in Russian text for it . Where should I report it? Thanks

Comment 40

7 years ago
I believe the proper component is Websites/www.mozilla-europe.org

Comment 41

7 years ago
Thanks

Comment 42

7 years ago
Linux affected too
I run Flash music player in background tab, and FF responds slowly to mouse movement in menus (sort of "delayed repaint")
Mozilla/5.0 (X11; Linux i686; rv:2.0b6pre) Gecko/20100902 Firefox/4.0b6pre
Flash based games or videos or anything that is on flash got worse with beta 5.
If you visit this website http://www.infinitystamp.net/m-light/ , and scroll a little bit and then try to switch to another tab, you can see a delay. With latest trunk, I get worse delay than on beta 5. I saw on Firefox Test Drivers group (Facebook), how people started to complain about how beta 5 got slower for them and when they play games it's horrible. On latest trunk I disabled OOPP because it fixes temporary my problem, but CPU usage is still higher than 3.6.9 or other browsers.
See this bug https://bugzilla.mozilla.org/show_bug.cgi?id=594959 and comment #3 for more info.

Comment 44

7 years ago
Local ISP has a good test page: http://www.elisa.fi/viihde/
(firefox.exe and plugin-container.exe have high CPU)
It takes Minefield seconds to notice if you wont go somewhere..

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100922 Firefox/4.0b7pre ID:20100922041040

Comment 45

7 years ago
(In reply to comment #44)
> Local ISP has a good test page: http://www.elisa.fi/viihde/
> (firefox.exe and plugin-container.exe have high CPU)
> It takes Minefield seconds to notice if you wont go somewhere..
> 
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100922
> Firefox/4.0b7pre ID:20100922041040

What type of system are you using?

On my system, with ipc off, fx varies between 2% and 32%. With ipc enabled, fx sits at around 0% - 2%, with pc varying between 2% - 32%.

Comment 46

7 years ago
For reference, IE9 does a little better, with a single process running between 2% - 15%.

Comment 47

7 years ago
My system: AMD Phenom II X4 940 3,2 MHz, 8G, Radeon 5870, Win7 Ultimate 64bit.
Minefield in default configs so all Direct2/3 etc are on...

IPC makes a difference, though all those layer things do most load...
(Reporter)

Comment 48

7 years ago
(In reply to comment #46)
> For reference, IE9 does a little better, with a single process running between
> 2% - 15%.

Jim, is it possible what you're actually seeing is this regression?: bug 595671 comment 13

Comment 49

7 years ago
(In reply to comment #48)
> (In reply to comment #46)
> > For reference, IE9 does a little better, with a single process running between
> > 2% - 15%.
> 
> Jim, is it possible what you're actually seeing is this regression?: bug 595671
> comment 13

Might be although that site looks to be mostly flash based.

Updated

7 years ago
Blocks: 599546

Updated

7 years ago
blocking2.0: --- → ?
blocking2.0: ? → -

Comment 50

6 years ago
I have problems with the whole browser tab freezing up and mouse movement very jerky/delayed when playing a YouTube video or any flash video on another site for that matter. It just stops responding until the video is buffered and makes the mouse unresponsive. Then you get another 2-3 second delay if you try and hit the pause button. The problem occurs with Chrome 9 as well, but not as bad - there's perhaps a 1sec delay and minor jerky mouse movement for a second. So that makes me think the problem is partly to do with Flash itself but it's definitely a lot worse on Firefox.

I would say my computer was up to the task of playing videos perfectly a few versions of Firefox/Flash ago, but something changed recently has made it worse. Using an Intel dual core 1.7Ghz with 3GB RAM, Radeon X1600 128MB, Firefox 3.6.14, Flash Player 10.2 and Win XP Pro SP3.

Updated

6 years ago
Assignee: jmathies → nobody
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.