535295 - [OOPP] Tearing/Repainting issues with flash videos, their controls and other page content during/after scrolling

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[u88484]

Attachment: Screenshot

There are a lot of tearing/repainting issues with flash videos, their controls and other page content during/after scrolling.  See attachment for one instance I captured.  Other times the controls disappear and I have to scroll up or down with the video out of view for the controls to reappear.

Comment 1

[Benjamin Smedberg]

Jim, can you take a look? This is probably similar to bug 518506 (GTK), but I'm not certain of that.

Comment 2

[Jim Mathies [:jimm]]

Some sort of windowed flash invalidation problem. Might be ipc, might just be related to some of the child scrolling problems we've had recently. Will see if I can track it down.

Comment 3

[Benjamin Smedberg]

This may be bug 534561, which roc landed last night. Can somebody retest with today's m-c nightly?

Comment 4

[u88484]

Attachment: Still repainting and tearing issues

Using the 20091217 trunk nightly

Comment 5

[(not currently active) Ted Mielczarek]

I saw this pretty badly on a page today, so I made a testcase:
http://mavra.perilith.com/~luser/flash-redraw.html

That page contains a 1200px high red div followed by a 200px high green flash object. The onload simply scrolls the <embed> into view (in a setTimeout, which seems to be important).

If you scroll back to the top of the page and then scroll down using the keyboard or scrollbar, you can see the correct rendering.

The underlying issue here seems to be that the plugin window is being scrolled to the wrong place. If you load this testcase, then right click on the bottom of the red area (which should be the div), you get the flash context menu.

I didn't test this on Linux yet, only Windows.

Comment 6

[(not currently active) Ted Mielczarek]

I tested on Linux and this doesn't show up. Appears to be Windows-only.

For completeness, I also flipped the plugin IPC pref and verified that this doesn't happen on Windows with in-process plugins.

Also, my conclusion in the previous comment was flawed. The plugin window appears to be in the correct spot, it's just not redrawing the area that it occupies, so it's still red from displaying the div that was previously there.

Comment 7

[(not currently active) Ted Mielczarek]

Seems to be Flash-specific, I can't reproduce with the same testcase with the test plugin swapped in for the Flash object:
http://mavra.perilith.com/~luser/plugin-redraw.html

Comment 8

[(not currently active) Ted Mielczarek]

Also of note, I can't reproduce this on a self-built Win32 build from today (Built with VC9, no PGO)

Comment 9

[Jim Mathies [:jimm]]

Still there in an m-c build from today. Appears it's just windowed, windowless doesn't seem to have a problem.

Comment 10

[Jim Mathies [:jimm]]

Attachment: simple test case

Comment 11

[(not currently active) Ted Mielczarek]

Jim: it's nearly 100% reproducible on nightlies in my testcase in comment 5.

Comment 12

[[not reading bugmail]]

Seems scrolling/tearing is either paint/invalidate issues or it seems to be position of the plugin is incorrect, would bz's info from bug 545514 comment 16 apply at all here?  He mentioned a trick in reference to the new plugin-ui positioned incorrectly also so it should display properly in the plugin area.

Comment 13

[(not currently active) Ted Mielczarek]

I'm pretty sure that the plugin is located correctly, just not drawing correctly. Using my testcase from comment 5, if you right click where the plugin should be, even though it's not drawn in green, you still get the flash context menu.

Comment 14

[[not reading bugmail]]

I noticed the biggest problem with this when the plugin goes in and out (scrolled in and out) of the visible window area and is still partially visible.

Comment 15

[[not reading bugmail]]

Maybe we should have roc take a look at this?

Comment 16

[Jim Mathies [:jimm]]

I'm working on this this week actually.

Comment 17

[Jim Mathies [:jimm]]

Attachment: fix

grab the invalidated area from the parent, and set it on the child before painting.

Comment 18

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

I don't really know the PluginInstanceChild code. Why is this needed? Are we sure that mPluginWindowHWND is at 0,0 in the parent?

BTW I'm a bit sad that this new plugin code is gather platform #ifdefs :-(.

Comment 19

[Jim Mathies [:jimm]]

(In reply to comment #18)
> I don't really know the PluginInstanceChild code. Why is this needed? Are we
> sure that mPluginWindowHWND is at 0,0 in the parent?

We invalidate the parts of the gecko plugin window (parent) in widget during scrolling, which sits underneath the OOPP plugin window created by PluginInstanceChild. The two have the same size, and the same position. To avoid race conditions with paints though, we disconnected the two by removing the WS_CLIPCHILDREN style from the parent, so paints don't cascade down to the child.

http://mxr.mozilla.org/mozilla-central/source/modules/plugin/base/src/nsPluginNativeWindowWin.cpp#549

When the paint on the parent comes to widget, we forward it across to this call in the child.

http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsWindowGfx.cpp#304

I checked the values of the GetUpdateRect and they matched up perfectly to the areas that needed repainting for the scroll. 

> 
> BTW I'm a bit sad that this new plugin code is gather platform #ifdefs :-(.

Yeah, that's the way it came together. Most of the oopp plugin code though is cross but the instances ended up with heavy ifdef'ing. At some point we'll probably need to split them up into separate files.

Comment 20

[Jim Mathies [:jimm]]

http://hg.mozilla.org/mozilla-central/rev/3549ea4a9bd9

Comment 21

[u88484]

Verified fixed using hourly Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100405 Minefield/3.7a4pre

cset: 67f4c546d403

Is there a bug for the video jumping around while scrolling?  I thought this fix would have also fixed that.

Comment 22

[Jim Mathies [:jimm]]

(In reply to comment #21)
> Is there a bug for the video jumping around while scrolling?  I thought this
> fix would have also fixed that.

Uh ohh. Kurt, can you provide more detail on what you're seeing or STR?

Comment 23

[Jim Mathies [:jimm]]

(In reply to comment #22)
> (In reply to comment #21)
> > Is there a bug for the video jumping around while scrolling?  I thought this
> > fix would have also fixed that.
> 
> Uh ohh. Kurt, can you provide more detail on what you're seeing or STR?

bug 557533 was filed.

Comment 24

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

Comment on attachment 435956 [details] [diff] [review]
fix

a=beltzner for 1.9.2.4

Comment 25

[Jim Mathies [:jimm]]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/9a8e26f8fc0e

Comment 26

[Al Billings [:abillings - ex-MoCo]]

Verified fixed for 1.9.2 in the nightly build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4pre) Gecko/20100412 Namoroka/3.6.4pre (.NET CLR 3.5.30729)

Comment 27

[Petras]

It's seems the fix still haven't made its way into production. I'm using Firefox 13.0.1 on Windows 7 x64 and still experiencing this issue. When can we expect the fix to be included into the release?

Comment 28

[Petras]

Attachment: Tearing after scroll

Tearing of flash image after scrolling on page http://www.ixbt.com/cpu/intel-ci5i7-ivy.shtml.
Firefox version: 13.0.1
Flash player plugin version: 11.3.300.262
OS: Windows 7 Professional x64

Comment 29

[Benjamin Smedberg]

The new issue is caused by Flash 11.3 and is covered by bug 762948.