Steps to Reproduce --------------------------------------- 1. Load a flash video 2. Scroll to bottom of page 3. Scroll to the top What should have happened: --------------------------------------- The rest of the page should be rendered the same as it was before the flash video started. What actually happened: ---------------------------------------- The page smeared whilst scrolling up

* What is the exact Firefox Version ("Help"/"About")? * Name an Example Url? * Did you check against Firefox' Safe-Mode? * What is the Flash Version ("about:plugins") the Issue is reported with?

(In reply to comment #1) > * What is the exact Firefox Version ("Help"/"About")? > * Name an Example Url? > * Did you check against Firefox' Safe-Mode? > * What is the Flash Version ("about:plugins") the Issue is reported with? Firefox 4.0b2pre nightly build It was on Daily Motion (although i can't recreate this now) Didn't check against safe mode. (I can't recreate it now either so this isn't an option) Flash version 10.0 r45 64 bit Running Ubuntu 10.04 64bit Firefox is 64 bit build from Mozilla

The URL for that video is http://www.dailymotion.com/video/xdm5he_richard-dawkins-demonstrates-laryng_tech Could also be a combination of trying to view a HQ/ HD video when my system is pretty old. But didn't notice this on FF 3.x.x ever

This is an issue with retained layers, which just landed on nightly. bug 579215 is one, or bug 579262. reporter, do either of these describe your issue?

Hi there, bug 579215 is most similar to the issue I am seeing. Although I'm running this in Linux (Ubuntu 10.04) and on a 64 bit build. I've updated the drop downs to reflect this although it does say in my comments. Thanks

Bug 579215 is D2D-specific.

This also occurs occasionally with Windows 7.

Linux users seeing this, out of curiousity, which driver are you using? (See /var/log/Xorg.0.log or "glxinfo | grep renderer".) I see something similar with radeon.

Hi there! I'm using a Radeon chipset for sure, but not the ATI drivers. The open source ones that come with Ubuntu 10.04. The out put from glxinfo | grep vendor is server glx vendor string: SGI client glx vendor string: Mesa Project and SGI OpenGL vendor string: DRI R300 Project

I see this on Linux (x86) with the nvidia driver. I seem to be able to reproduce it more often by scrolling with selection (selecting past the edge of the viewport) or by autoscrolling, than by mousewheel scrolling. I can reproduce this 100% of the time by finding a large image, viewing it on it's own, zooming in (by clicking on it, image has to be big enough to be scaled down on load), and then autoscrolling around. Can create some really funky-looking artifacts this way :-) Attaching a load of system graphics details in case they help.

This is with: Mozilla/5.0 (X11; Linux i686; rv:2.0b2pre) Gecko/20100720 Minefield/4.0b2pre (the respin, navigator.buildID = 20100720102432)

We should aim this bugfix for beta 3, but slipping it to some other beta isn't the end of the world.

The most appealing solution here would be to use XCopyArea instead of XRenderComposite when appropriate for the self-copy, and it is appropriate in this situation. XCopyArea does what we want for the self-copy. XRenderComposite apparently doesn't. XCopyArea has a bit of a history in cairo. XCopyArea was first added as a fast path here: http://cgit.freedesktop.org/cairo/commit/?id=23026d5ab65201793ac19b459e3e7e05a090e435 Then removed here (apparently to make things slower): http://cgit.freedesktop.org/cairo/commit/?id=019d381b4076a5716cae3708f0109d0815d7d6ef Readded here: http://cgit.freedesktop.org/cairo/commit/?id=8ad8aa63605610eaec78cdbfea321148c02be331 Then (probably accidentally for operator SOURCE) only used for CONTENT_COLOR dest surfaces: http://cgit.freedesktop.org/cairo/commit/?id=c25992479aca481d326f72665ebdcf0904273eac And then reduced to only a subset of Pixmap src surfaces here: http://cgit.freedesktop.org/cairo/commit/?id=40aefac5d714bf7536632ed38c7a8ee05049f30b The last change is the one I'll discuss here. In most situations cairo xlib surfaces are created by passing a Drawable to cairo. Cairo doesn't know whether the drawable is a Pixmap or Window, but it can't use XCopyArea if both the source and destination may be Windows. There is only one time when cairo knows that it has a Pixmap: when the surface is created with cairo_surface_create_similar. I wondered for a moment whether cairo could assume that surfaces created with an xrender_format were Pixmap surfaces because usually a surface for a Window would be created with a Visual. Including subwindows when surfaces are used as sources started here: http://cgit.freedesktop.org/cairo/commit/?id=0c5d28a4e5ce5e4dd72c0f416ce5e960e92b808b and the subwindow behavior was only mentioned in docs for cairo_xlib_surface_create (not the xrender_format variant). However the docs for cairo_xlib_surface_create_with_xrender_format have always mentioned that the drawable might be a window. http://cgit.freedesktop.org/cairo/commit/?id=0c05b23b3165ec6908c28f56b3446cf43dff44a2 If the drawable might be a window, then getting the behavior we want from cairo would need to use a scratch surface to copy to and from. A single XCopyArea self-copy should be more efficient, so I think the best way to get the behavior that we want is to use cairo_surface_create_similar.

This means that cairo does an unnecessary clear of opaque surfaces and the force24bpp path needs to temporarily create a 1 pixel Pixmap, but at least they only happen once, better than creating a scratch surface on every self-copy. This is enough to fix CONTENT_COLOR surfaces. Reverting to also using XCopyArea in cairo for OPERATOR_SOURCE CONTENT_COLOR_ALPHA is a simple change that I'll submit to cairo.

(Just the gfxXlibSurface changes.)

(In reply to comment #17) > This means that cairo does an unnecessary clear of opaque surfaces and the > force24bpp path needs to temporarily create a 1 pixel Pixmap, but at least > they only happen once, better than creating a scratch surface on every > self-copy. Couldn't we just add new cairo API to let us create an xlib surface for a Pixmap with an XRenderPictFormat? cairo_xlib_surface_create_with_xrender_format_and_pixmap?

(In reply to comment #16) > And then reduced to only a subset of Pixmap src surfaces here: > http://cgit.freedesktop.org/cairo/commit/?id=40aefac5d714bf7536632ed38c7a8ee05049f30b > > The last change is the one I'll discuss here. Just for the record, we patch this change out.

Screenshot (photo taken with my n900) of duplicate content from http://penilla.nu/ caused by scrolling upwards. There is a discussion in comment 237-241 in bug 564991 that this affects Linux users (at least). This is on Mozilla/5.0 (X11; Linux i686; rv:2.0b2pre) Gecko/20100720 Minefield/4.0b2pre running Fedora 12 on a Thinkpad z61p. Other system info: Output from glxinfo |grep renderer OpenGL renderer string: Mesa DRI R300 (RV530 71C4) 20090101 TCL Output from lspci -v 01:00.0 VGA compatible controller: ATI Technologies Inc M56GL [Mobility FireGL V5200] (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 202b Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at d0000000 (32-bit, prefetchable) [size=256M] I/O ports at 2000 [size=256] Memory at ee000000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at ee020000 [disabled] [size=128K] Capabilities: <access denied> Kernel modules: radeon Note on the image that the scrolling ticker (JavaScript) works...

(In reply to comment #20) > (In reply to comment #16) > > And then reduced to only a subset of Pixmap src surfaces here: > > http://cgit.freedesktop.org/cairo/commit/?id=40aefac5d714bf7536632ed38c7a8ee05049f30b > > > > The last change is the one I'll discuss here. > > Just for the record, we patch this change out. Looks like this patch actually never made it in. So nevermind.

I'm starting to wonder whether this desired behavior for source windows is a bit a sham anyway. The render protocol says that the source subwindow_mode added here is ignored: http://cgit.freedesktop.org/cairo/commit/?id=0c5d28a4e5ce5e4dd72c0f416ce5e960e92b808b "When a window is used as source or mask, the subwindow_mode is ignored. Pixels that are obscured by other windows, whether siblings or inferiors, have undefined contents." http://cgit.freedesktop.org/xorg/proto/renderproto/tree/renderproto.txt#n642

That's behavior is actually undefined since a change in the spec: http://cgit.freedesktop.org/xorg/proto/renderproto/commit/?id=2c5e931d5e5b5af88bcf8aaed8b10d799fd47b1e The changes started happening here: http://cgit.freedesktop.org/xorg/proto/renderproto/commit/?id=c4315b2a4704c88924e7a6bc444b5331caa64022 <ssp> karlt: If cairo is going to support IncludeInferiors, it should probably make a copy with XCopyArea() first

Posted suggesting not including inferiors for source surfaces from cairo_xlib_surface_create_with_render_format: http://lists.cairographics.org/archives/cairo/2010-July/020352.html

(In reply to comment #17) > Created attachment 458927 [details] [diff] [review] > use cairo_surface_create_similar in CreateSimilarSurface to create surfaces > that support integer self-copies > > This means that cairo does an unnecessary clear of opaque surfaces and the > force24bpp path needs to temporarily create a 1 pixel Pixmap, but at least > they only happen once, better than creating a scratch surface on every > self-copy. > > This is enough to fix CONTENT_COLOR surfaces. Reverting to also using > XCopyArea in cairo for OPERATOR_SOURCE CONTENT_COLOR_ALPHA is a simple change > that I'll submit to cairo. I patched the Firefox 4.0b2 (build 1) tarball with this patch and compiled a build for Linux. This cured the scrolling and lock-up problem that I observed and commented on under bug 564991 ( https://bugzilla.mozilla.org/show_bug.cgi?id=564991 ).

After investigating further with Linux x86 Nightly Build: Mozilla/5.0 (X11; Linux i686; rv:2.0b3pre) Gecko/20100722 Minefield/4.0b3pre, I find another site which seems to cause a greater problem for me and maybe the same bug as this one: Navigate to: http://www.newquayweather.com/ Click on 'Live Weather' in side menu. Result: Progress bar sometimes halts at about 14%. occasionally it proceeds to 100% and loads the graphic. If it does so then scrolling is very, slow and give the impression that the browser has locked. (The same thing occurs with my patched build as discussed in Comment 26 Expected Result (e.g. Firefox 3.6.*): Progress bar reaches 100% in approximately 1 second. Then progresses to the 'live results' graphic. Is this a Flash problem covered by another bug or same as this bug??.

(In reply to comment #27) > http://www.newquayweather.com/ > > Click on 'Live Weather' in side menu. > > Result: Progress bar sometimes halts at about 14%. occasionally it proceeds to > 100% and loads the graphic. If it does so then scrolling is very, slow and > give the impression that the browser has locked. (The same thing occurs with > my patched build as discussed in Comment 26 Looks like bug 576143 helped there. I can't reproduce now. If you still see that behavior then please file a new bug.

(In reply to comment #17) > Reverting to also using > XCopyArea in cairo for OPERATOR_SOURCE CONTENT_COLOR_ALPHA is a simple change > that I'll submit to cairo. https://bugs.freedesktop.org/show_bug.cgi?id=29250

(In reply to comment #25) > Posted suggesting not including inferiors for source surfaces from > cairo_xlib_surface_create_with_render_format: > http://lists.cairographics.org/archives/cairo/2010-July/020352.html Patch here: http://marc.info/?l=cairo&m=128010915214899&w=2

Comment on attachment 458928 [details] [diff] [review] use cairo_surface_create_similar in CreateSimilarSurface to create surfaces that support integer self-copies Seems ok.

I tested today if there was any change. On this page (penilla.nu) I had to scroll up and down quite a few times before the problem appeared. Then, when I hovered the mouse on the page, elements started to appear when hovered. The smeared header remained beneath them though. Still, the very second I click outside of the browser the page is instantly OK.

Can we get this landed so we have a few days of nightly coverage before the code freeze on Monday, Aug 2?

It's still in Mozilla/5.0 (X11; Linux x86_64; rv:2.0b3pre) Gecko/20100729 Minefield/4.0b3pre and it happens often in regular browsing. How can I test the fix? Can I just apply attachment 458928 [details] [diff] [review] and build, or Cairo should be patched too?

http://hg.mozilla.org/mozilla-central/rev/d02490c3c218 (In reply to comment #17) > This is enough to fix CONTENT_COLOR surfaces. Reverting to also using > XCopyArea in cairo for OPERATOR_SOURCE CONTENT_COLOR_ALPHA is a simple change > that I'll submit to cairo. Bug 583115 tracks CONTENT_COLOR_ALPHA surfaces.

I don't know if this should be posted here, but I get smearing with .gif images. I'm using Fx 9.0.1 on Apple Snow Leopard 10.6.8 For example showing this image: http://ic.tweakimg.net/ext/i/thumbs_fpa_small/1326888421.gif gives a 'screenshot' instead of the gif. Also the site: www.simplon.nl smears upon scrolling.

Please file a new bug for that.