Closed Bug 579736 Opened 9 years ago Closed 9 years ago

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

Categories

(Core :: Graphics, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0b3
Tracking Status
blocking2.0 --- beta3+

People

(Reporter: mez.pahlan, Assigned: karlt)

References

Details

Attachments

(5 files, 1 obsolete file)

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
Version: 3.5 Branch → unspecified
Attached image smearing example
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
OS: Windows XP → Linux
Hardware: x86 → x86_64
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 579215
Bug 579215 is D2D-specific.
Blocks: 564991
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
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.
Assignee: nobody → karlt
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes
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
Duplicate of this bug: 580473
Summary: [QAC generated] Flash video scrolling causes page to smear → [QAC generated] scrolling causes some pages to smear/repeat
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)
blocking2.0: --- → ?
status2.0: --- → ?
Blocks: 580497
We should aim this bugfix for beta 3, but slipping it to some other beta isn't the end of the world.
blocking2.0: ? → beta3+
status2.0: ? → ---
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.
Attachment #458927 - Flags: review?(jmuizelaar)
(Just the gfxXlibSurface changes.)
Attachment #458927 - Attachment is obsolete: true
Attachment #458928 - Flags: review?(jmuizelaar)
Attachment #458927 - Flags: review?(jmuizelaar)
(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.
Attachment #458928 - Flags: review?(jmuizelaar) → review+
Blocks: 582147
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.
Duplicate of this bug: 582147
Can we get this landed so we have a few days of nightly coverage before the code freeze on Monday, Aug 2?
Blocks: 583115
Duplicate of this bug: 583058
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?
Duplicate of this bug: 583207
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.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b3
Blocks: 583621
Blocks: 580343
No longer blocks: 583621
No longer blocks: 580343
Duplicate of this bug: 580343
Duplicate of this bug: 580497
Blocks: 583621
Duplicate of this bug: 581450
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.
You need to log in before you can comment on or make changes to this bug.