450783 - flash video in gpu mode flickers while scrolling the webpage

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Supriya Rao]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

Firefox apparently has a bug that calls NsSetWindow twice when scrolling, first call with an invalid clip rectangle and second one with the correct clip rectangle. The first one is causing flickering in gpu mode since we are setting the buffer rectangle using an empty rectangle.

Reproducible: Always

Steps to Reproduce:
1. Go to the following link
http://www.playercore.com/users/supriya/gpu_issue/longMovie.html
2. after the page loads, scroll up and down
Actual Results:  
the video portion flickers

Expected Results:  
no flickering while scrolling

this does not happen on windows. does not happen on mac safari

Comment 1

[Supriya Rao]

Forgot to mention, you need the latest flash player for GPU mode to work. Please get the beta from here:
http://labs.adobe.com/technologies/flashplayer10/

Comment 2

[Steven Michaud [:smichaud] (Retired)]

I'm not yet able to test your report (I need a few days to set
everything I need up in a separate partition).

But I've got a few questions, plus the results of a preliminary test.

I notice you've tested on Windows.  But what happens when you test on
Linux (or is that not currently possible)?

Do you also see this problem (on any platform) in Firefox 2.X?

Do you also see it with current "trunk" nightlies (what will become
Firefox 3.1)?

I got some interesting results running a simple test using my
DebugPluginEvents plugin from bug 441880.  Install the plugin, load
its distro's test.html, and make the browser window smaller
(vertically) than the plugin display (so that a vertical scrollbar
appears).  Click once on the scrollbar's up or down arrow, and notice
that (in Firefox 3.X), four calls are made to NPP_SetWindow() for
every click of the up or down arrow.  But if you do this in Firefox
2.0.0.16, only two calls are made to NPP_SetWindow() for every click
of the up or down arrow.

My plugin doesn't (yet) display the clip rectangle NPP_SetWindow() is
called with.  But I'll be working on a new version that does.

Comment 3

[Alex Chien]

There is no flickering on Ubuntu 8.

We've seen the flickering problem in Firefox 2.x and Firefox 3.0.1 on Mac. Have not tried the latest trunk yet.

This problem will be resolved if Firefox calls NPP_SetWindow with the correct clip rectangle when scrolling.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

OK, I've posted a new version of my DebugPluginEvents plugin (at bug
441880) that logs (to the system console) the "window"'s coordinates
and clipRect every time NPP_SetWindow() is called by the browser.  And
I've installed the Flash 10 RC (dated 2008-08-11).  So let's try to
dig into this a big further.

I've noticed that the movie at
http://www.playercore.com/users/supriya/gpu_issue/longMovie.html
doesn't appear to work properly -- it often spontaneously stops
playing a few seconds after I've clicked on the Flash plugin's Play
button.  But it still serves to illustrate the "flashing" problem
you've reported:  This happens whenever I scroll the page containing
it in Firefox 3.X, even when the movie isn't playing.

I don't see the flashing when I scroll this movie's page in Safari, or
Opera, or Firefox 2.

Now copy the new DebugPluginEvents plugin to /Library/Internet
Plug-Ins/ and perform the following test in various browsers:

1) Load the plugin distro's test.html into the browser.

2) Make the browser window smaller (vertically) than the plugin
   display (so that a vertical scrollbar appears).

3) Click once on the scrollbar's up or down arrow, and observe the
   calls to NPP_SetWindow() logged to the system console.

With Safari, you'll see one call to NPP_SetWindow() for each click (on
the scrollbar's up or down arrow).  You'll notice that the "window"
parameter's coordinates accurately describe the dimensions and
location of the whole (unclipped) plugin after the display is
scrolled, and that it's clipRect accurately describes the part of it
that's actually displayed.

With Firefox 2, you'll see two calls to NPP_SetWindow().  The first
call's "window"'s coordinates accurately describe the dimensions and
location of the whole (unclipped) plugin before the window is
scrolled, but its clipRect is "empty" (it has zero width and height).
The second call's "window"'s coordinates accurately describe the whole
(unclipped) plugin's dimensions and location after the window has been
scrolled, and its clipRect accurately describes the part of it that's
actually displayed (i.e. it's not "empty").

With Firefox 3.0.X (or any of the pre-3.1 nightlies) you'll see four
calls to NPP_SetWindow().  The first two are like Firefox 2's first
call to NPP_SetWindow().  The third and fourth are like Firefox 2's
second call to NPP_SetWindow().

Since we (or at least I) don't see flashes with Firefox 2, I think
your analysis in comment #0 is wrong -- it's not the following that
causes the flashes:

> Firefox apparently has a bug that calls NsSetWindow twice when
> scrolling, first call with an invalid clip rectangle and second one
> with the correct clip rectangle. The first one is causing flickering
> in gpu mode since we are setting the buffer rectangle using an empty
> rectangle.

Rather, I think the cause is that Firefox 3 is (when scrolling) making
two (identical) calls to NPP_SetWindow() for each of Firefox 2's calls
to NPP_SetWindow() (or in other words the cause is that Firefox 2's
two calls have morphed into Firefox 3's four calls).

Comment 5

[Alex Chien]

I can still reproduce the problem in both Firefox 2 and Firefox 3. To see the
problem easily, while movie is playing scroll the page continuously by grabbing
and moving the scroll bar.

Flash player uses the clip rectangle to set the buffer rectangle applied to the
OpenGL rendering context. When the clip rectangle has zero width or height, it
causes flickering. Skipping the call to set the buffer rectangle when clip
rectangle is invalid does not provide a good workaround since clip rectangle
could be of zero dimension when a new tab is being created. Unless we know a
zero clip rectangle is generated by a scroll event or a new tab.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

> I can still reproduce the problem in both Firefox 2 and Firefox
> 3. To see the problem easily,

I tested again with Firefox 2.0.0.16 (on OS X 10.5.4), and now I do
see flashes scrolling this bug's movie
(http://www.playercore.com/users/supriya/gpu_issue/longMovie.html).

But the problem is much worse in FF3 than it is in FF2:  In FF3 the
movie flashes every time it's scrolled by one "increment" (whether
vertically or horizontally).  In FF2 the movie only flashes once in
every 3-5 scrolling "increments".  (By an "increment" I mean what
happens when you click the up, down, left or right arrows in the
vertical or horizontal scrollbars.  The flashes also (of course)
happen when you scroll continuously, but using the scrollbar arrows
gives you a precise way to measure the flashes' frequency.)

> When the clip rectangle has zero width or height, it causes
> flickering.

As I've shown, this isn't always the case (in FF2).  But maybe the
flickering _does_ happen every time NPP_SetWindow() is called twice in
a row with an empty clipRect (as happens in FF3).  And maybe you're
right that the underlying cause of the flashing/flickering problem is
calling NPP_SetWindow() with an empty clipRect (though it certainly
can't help to call NPP_SetWindow() twice in a row with exactly the
same parameters, no matter what those parameters are).

> Skipping the call to set the buffer rectangle when clip rectangle is
> invalid does not provide a good workaround since clip rectangle
> could be of zero dimension when a new tab is being created. Unless
> we know a zero clip rectangle is generated by a scroll event or a
> new tab.

So now we've got to figure out what to do about the problem.  The
easiest solution is to never call NPP_SetWindow() with an empty
clipRect.  But I'm not sure what the consequences of doing this might
be -- it might sometimes be necessary to call NPP_SetWindow() with an
empty clipRect (though I can't, off the top of my head, think of any
examples of this).

What do you think, Josh?

Comment 7

[Samuel Sidler (old account; do not CC)]

Josh?

Comment 8

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #6)

I've found out how to fix the doubled-calls-to-SetWindow problem.  See
bug 459244.  I've posted a patch there, and a tryserver build made
with that patch.

Unfortunately, that still doesn't resolve this bug.  Even using the
tryserver build from bug 459244, you still see a flash (in FF3, with
this bug's URL) every time you click once on a scroll bar's arrow (up,
down, left or right).

> The easiest solution is to never call NPP_SetWindow() with an empty
> clipRect.  But I'm not sure what the consequences of doing this
> might be -- it might sometimes be necessary to call NPP_SetWindow()
> with an empty clipRect.

Josh tells me that it sometimes *is* necessary to call NPP_SetWindow()
with an empty clipRect (as a signal to plugins).

Furthermore, the result of the browser never calling SetWindow() with
an empty clipRect is logically identical with the result of a plugin
always ignoring calls to SetWindow() that specify an empty clipRect.

So I think Adobe should experiment again with ignoring calls to
SetWindow that specify an empty clipRect.  In your tests please use
both my tryserver build from bug 459244 and recent nightlies of
Firefox 3.0.X and Firefox 3.1.

https://build.mozilla.org/tryserver-builds/2008-10-09_09:[e-mail]-bugzilla459244/[e-mail]

I can't explain the difference in behavior between Firefox 3 and
Firefox 2 (as I noted above (comment #6) you only see the flash once
in 3-5 scrolling increments in Firefox 2).  I will keep looking for an
explanation, and along the way I may find (and fix) more bugs.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

Attachment: Patch for bug 459244 and disable CoreGraphics support (*not* a fix)

Another build to test with.

(Following up comment #8)

> I can't explain the difference in behavior between Firefox 3 and
> Firefox 2 (as I noted above (comment #6) you only see the flash once
> in 3-5 scrolling increments in Firefox 2).

The difference (the explanation) isn't that Firefox 3 supports the
CoreGraphics drawing model while Firefox 2 doesn't.  Test with this
build, and you'll see that the Flash movie at this bug's URL still
flashes once for every scrolling increment.

Here's a tryserver build made with this patch:

https://build.mozilla.org/tryserver-builds/2008-10-09_10:[e-mail]-bugzilla450783-disablecoregraphics/[e-mail]

Comment 10

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #8)

I've found and fixed another bug (bug 459319) that might (in
principle) help with fixing this bug.  Here's its tryserver patch:

https://build.mozilla.org/tryserver-builds/2008-10-09_15:[e-mail]-bugzilla459319/[e-mail]

But (unfortunately) it doesn't fix this bug's flashing problem,
either.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

Attachment: Combo patch for bug 459244 and bug 459319 (for testing)

And here's a tryserver build:

https://build.mozilla.org/tryserver-builds/2008-10-09_17:[e-mail]-bug459244-bug459319-combo/[e-mail]

Comment 12

[Benjamin Smedberg]

Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.