579736 - [QAC generated] scrolling causes some pages to smear/repeat

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[mez.pahlan]

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

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

* 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?

Comment 2

[mez.pahlan]

(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

Comment 3

[mez.pahlan]

Attachment: smearing example

Comment 4

[mez.pahlan]

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

Comment 5

[Tyler Downer [He/Him]]

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?

Comment 6

[mez.pahlan]

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

Comment 8

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

Bug 579215 is D2D-specific.

Comment 9

[imradyurrad]

This also occurs occasionally with Windows 7.

Comment 10

[Karl Tomlinson (:karlt)]

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.

Comment 11

[mez.pahlan]

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

Comment 13

[Daniel C]

Attachment: Various graphics information

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.

Comment 14

[Daniel C]

This is with:

Mozilla/5.0 (X11; Linux i686; rv:2.0b2pre) Gecko/20100720 Minefield/4.0b2pre

(the respin, navigator.buildID = 20100720102432)

Comment 15

[Joe Drew (not getting mail)]

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

Comment 16

[Karl Tomlinson (:karlt)]

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.

Comment 17

[Karl Tomlinson (:karlt)]

Attachment: 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.

Comment 18

[Karl Tomlinson (:karlt)]

Attachment: use cairo_surface_create_similar in CreateSimilarSurface to create surfaces that support integer self-copies

(Just the gfxXlibSurface changes.)

Comment 19

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

(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?

Comment 20

[Jeff Muizelaar [:jrmuizel]]

(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.

Comment 21

[Lars Gunther]

Attachment: Problem also on non-flash site

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...

Comment 22

[Jeff Muizelaar [:jrmuizel]]

(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.

Comment 23

[Karl Tomlinson (:karlt)]

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

Comment 24

[Karl Tomlinson (:karlt)]

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

Comment 25

[Karl Tomlinson (:karlt)]

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

Comment 26

[Bill Lancashire]

(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 ).

Comment 27

[Bill Lancashire]

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??.

Comment 28

[Karl Tomlinson (:karlt)]

(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.

Comment 29

[Karl Tomlinson (:karlt)]

(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

Comment 30

[Karl Tomlinson (:karlt)]

(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 31

[Jeff Muizelaar [:jrmuizel]]

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

Seems ok.

Comment 32

[Lars Gunther]

Attachment: Another screenshot of the issue

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.

Comment 35

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

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

Comment 37

[Ognyan Kulev]

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?

Comment 39

[Karl Tomlinson (:karlt)]

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.

Comment 43

[Jens]

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.

Comment 44

[Timothy Nikkel (:tnikkel)]

Please file a new bug for that.