92.67 KB, image/png
58.94 KB, image/png
838 bytes, text/html
862 bytes, patch
|Details | Diff | Splinter Review|
40.54 KB, image/png
Created attachment 417941 [details] 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.
Jim, can you take a look? This is probably similar to bug 518506 (GTK), but I'm not certain of that.
Assignee: nobody → jmathies
Component: IPC → Plug-ins
QA Contact: ipc → plugins
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.
This may be bug 534561, which roc landed last night. Can somebody retest with today's m-c nightly?
Created attachment 418178 [details] Still repainting and tearing issues Using the 20091217 trunk nightly
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.
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.
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
Also of note, I can't reproduce this on a self-built Win32 build from today (Built with VC9, no PGO)
Still there in an m-c build from today. Appears it's just windowed, windowless doesn't seem to have a problem.
Jim: it's nearly 100% reproducible on nightlies in my testcase in comment 5.
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.
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.
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.
Maybe we should have roc take a look at this?
I'm working on this this week actually.
Created attachment 435956 [details] [diff] [review] fix grab the invalidated area from the parent, and set it on the child before painting.
Attachment #435956 - Flags: review?(roc)
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 :-(.
(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.
Attachment #435956 - Flags: review?(roc) → review+
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
(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?
(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 on attachment 435956 [details] [diff] [review] fix a=beltzner for 220.127.116.11
Attachment #435956 - Flags: approval18.104.22.168? → approval22.214.171.124+
status1.9.2: --- → .4-fixed
Verified fixed for 1.9.2 in the nightly build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199pre) Gecko/20100412 Namoroka/3.6.4pre (.NET CLR 3.5.30729)
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?
Created attachment 640535 [details] 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
The new issue is caused by Flash 11.3 and is covered by bug 762948.
You need to log in before you can comment on or make changes to this bug.