610737 - [D2D] video is very delayed to not playing at all - times out after approx 20 secs, Menu-menupopup highlight and wheel scroll page also lagged on www.msnbc.msn.com

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Alice0775 White]

Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101109 Firefox/4.0b8pre ID:20101109072504

See Forum( Post )
When page zoomed-in,
*video is very delayed to not playing at all - times out after approx 20 secs(buffer underflow)
*Menupopup highlight and wheel scroll page also lagged

Reproducible: Always

Steps to Reproduce1(see the forum):
1. I have Win7 x64 set to 'medium' to set the dpi to 125% (old eyes)
2. I also zoom most pages 2 or 3 steps with Ctrl+
3. Go to www.msnbc.com - zoom 2 steps
4. Pick a video to play , when you click it should open in a popup window
5. Note that the video is very delayed to not playing at all - times out after approx 20 secs
6. Setting zoom to default in Minefield the videos start right up. 

Steps to Reproduce2:
1. Start Minefield with new profile
2. Go http://www.msnbc.msn.com
3. Zoom-In more than 2-3 times.
4. Pick a video to play ( shortcut: Go http://www.msnbc.msn.com/id/39977091/ns/business-forbescom/ maybe not a permanent link)
5. Scroll down and Play back Video (skip completion ad if any)
6. pop-out the Video
7. Attempt Menu-menupopup highlight and wheel scroll page



Actual Results:
 *Menu-menupopup highlight and wheel scroll page also lagged
 *Popout video is very delayed to not playing at all - times out after approx 20 secs,

Expected Results:
 Notlagged and delayed.

Comment 1

[Jim Jeffery not reading bug-mail 1/2/11]

Slow scrolling is bug https://bugzilla.mozilla.org/show_bug.cgi?id=605189

Not sure if these two are related however or separate issues:

Comment 2

[Jim Jeffery not reading bug-mail 1/2/11]

Going into Tools->Options->Advanced and turning off Hardware Acceleration allows the video's to play normally without delay, even zoomed in a couple of steps.

Comment 3

[Bas Schouten (:bas.schouten)]

I can reproduce a slowdown in UI interaction. At first I thought it was alpha recovery but that only seems to be a fairly small percent of CPU usage (less than 8% of our CPU time), we seem to be doing a lot of large area fills with EXTEND_NONE, we should be able to avoid this. I'm looking into this a bit more.

Comment 4

[Bas Schouten (:bas.schouten)]

Attachment: Use EXTEND_PAD for drawing native theme

This makes performance behave much better for me! It avoids an internal memcpy we're currently doing for -each- native theme element we're drawing to support EXTEND_NONE. On smaller elements this memcpy is pretty negligible, on larger elements not so much.

Note that this does not fix the entire issue. It looks like UI events are still laggy when zooming in enough, though scrolling is smooth and the CPU is -not- saturated. (obviously it's higher than with GDI). Never-the-less, I think this patch is a Good Idea(tm).

Comment 5

[Bas Schouten (:bas.schouten)]

Presumably this is some interaction with the dual pass drawing and the alpha recovery? Any ideas Jimm? I'm especially baffled since the CPU isn't saturated at all when the UI starts behaving badly.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 489496 [details] [diff] [review]
Use EXTEND_PAD for drawing native theme

EXTEND_PAD is always saner than EXTEND_NONE.

Comment 7

[Jim Jeffery not reading bug-mail 1/2/11]

Today's landing of async-layers seems to have improved this issue greatly.  There is still some CPU being consumed even when the embedded video is NOT playing, but the scrolling is much better than before.  So, maybe with this fix along with async-layers we will start to some improvement in Flash...

Comment 8

[Bas Schouten (:bas.schouten)]

Joe, can I get blocking or approval on this so we can land this patch?

Comment 9

[Jim Mathies [:jimm]]

(In reply to comment #5)
> Presumably this is some interaction with the dual pass drawing and the alpha
> recovery? Any ideas Jimm? I'm especially baffled since the CPU isn't saturated
> at all when the UI starts behaving badly.

Hmm, can't really test at the moment due to our broken mouse events on windowless, but I wonder if async drawing has helped this.

Comment 10

[Bas Schouten (:bas.schouten)]

Pushed http://hg.mozilla.org/mozilla-central/rev/8714ad3e0704.

Comment 11

[Jim Mathies [:jimm]]

Alice, how is this working for you? I'm seeing about 15% fx/20% pc on these now.

Comment 12

[Jim Mathies [:jimm]]

(In reply to comment #11)
> Alice, how is this working for you? I'm seeing about 15% fx/20% pc on these
> now.

(And, I should add, no video timeouts, since that was the original bug.)

Comment 13

[Jim Jeffery not reading bug-mail 1/2/11]

Seems to be ok per my comment #7.  Perhaps another bug, but if OOPP is turned off, then scrolling when the video comes into page view lags horribly.  There is no delay in starting/playing the video - scrolling is just bad with OOPP off. 

Also, even not playing video there is CPU being consumed, but I've seen that happen on other sites with flash videos.  NO idea why...

Comment 14

[Alice0775 White]

(In reply to comment #11)
> Alice, how is this working for you? I'm seeing about 15% fx/20% pc on these
> now.

 *Menu-menupopup highlight and wheel scroll page seems to OK
 *Popout video play without times out

It seems to be fixed the problem.
However, CPU usage is total around 55% of Core2Quad.(20% in Google Chrome9.0593.0)