802028 - Rendering glitches during incremental loading of image

Status: NEW

(Core :: Graphics, defect)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Steps to reproduce:

1. Go to http://www.adapteva.com/
2. Look at image of chip and coin loading in the upper right part of the content of the page

The images loads pretty slowly since it's very big but getting scaled down, and the server appears to not be super fast.

Actual results:

As the image is incrementally rendered as the data is being downloaded, on occasion white lines are being left unrendered. It appears to be an invalidation issue since switching tabs back and forth fixes the problem.

Expected results:

The image should incrementally render without rendering glitches.


I don't know if this is a DLBI regression or not since I only saw the page after DLBI had landed.

Comment 1

[Markus Stange [:mstange]]

This could be bug 703231, which apparently wasn't fixed completely. That's what it says at the bottom, at least.

Comment 2

[u279076]

I'll make an attempt at this after the Release Management meeting today.

Comment 3

[u279076]

(In reply to Jonas Sicking (:sicking) from comment #0)
> Steps to reproduce:
> 
> 1. Go to http://www.adapteva.com/
> 2. Look at image of chip and coin loading in the upper right part of the
> content of the page

I don't see a "chip and coin" anywhere on this page. Please advise.

Comment 4

[Mats Palmgren (inactive)]

It used to be where the "Parallella Introduction" video element is now.
Here's the URL for the image that used to be there:
http://www.adapteva.com/wp-content/uploads/2012/08/E641.jpg
As you can see it's quite large so it took a while to load (it was scaled
to the size of what the video is now).  Hovering the navigation menu on
the page while the image was loading produced white lines in the image
that wasn't repainted, not even after the image was fully loaded.

Comment 5

[u279076]

Can you try to come up with a minimized testcase which reproduces this for you? I'm not seeing it here with that image. I tried replacing the src for the video with the URL to the image but that did not reproduce this issue for me.

Comment 6

[Mats Palmgren (inactive)]

Attachment: Test

I can still reproduce the problem in Nightly 20.0a1 (2012-11-25) on Linux64
with this test.  You need to clear the cache after each load to reproduce.

Comment 7

[Mats Palmgren (inactive)]

Attachment: Testcase

I can still reproduce the problem in Nightly 20.0a1 (2012-11-25) on Linux64
with this test.  You need to clear the cache after each load to reproduce.

Comment 8

[Mats Palmgren (inactive)]

Comment on attachment 685873 [details]
Test

Sorry for the double post, Bugzilla issues...

Comment 9

[u279076]

Sorry, Mats, I'm still not seeing this. I'm using Firefox 20.0a1 2012-11-27 on Mac OSX 10.7. Does this require particular platform/hardware/prefs?

Comment 10

[u279076]

Mats, can you provide further details to reproduce or provide a regression range if not?

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

Flagging Mats for more info on comment 10 so we can track down this regression range.

Comment 12

[Mats Palmgren (inactive)]

Attachment: video showing the problem

I can still reproduce it in Nightly 20.0a1 (2012-12-06) on Linux64.
No h/w acceleration.

Comment 13

[Alex Keybl [:akeybl]]

We're still looking for a regression window here. Marking as qawanted.

Comment 14

[u279076]

I'm still not able to reproduce this. Mats, what is your distribution, desktop manager, and kernel version, and graphics driver? Alternatively, can you use the mozregression tool to find the regression range? It would save us a lot of time since you already have a reproducible environment.

http://mozilla.github.com/mozregression/

Comment 15

[Mats Palmgren (inactive)]

It appears this non-default preference setting is required:
gfx.xrender.enabled = false

I'm using Kubuntu 12.10, KDE, "fglrx" driver.

Comment 16

[u279076]

It will take me considerable time to get the same environment set up natively as described in comment 15. Mats, can you please try to find a regression range using the mozregression tool (comment 14) before I put in all that effort?

Comment 17

[Alice0775 White]

gfx.xrender.enabled = false

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/b13bfc70bc44
Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/15 Firefox/15.0a1 ID:20120502030505
Bad:
http://hg.mozilla.org/mozilla-central/rev/807403a04a6a
Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/15 Firefox/15.0a1 ID:20120503030512
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b13bfc70bc44&tochange=807403a04a6a


Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/330f6adec1ec
Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120430 Firefox/15.0a1 ID:20120430040217
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/32e001c1351b
Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/15 Firefox/15.0a1 ID:20120501010628
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=330f6adec1ec&tochange=32e001c1351b

Suspected: Bug 743830

Comment 18

[Mats Palmgren (inactive)]

Thanks Alice.  So the problem is likely older than that, it's just that prior
to bug 743830 the pref has no effect and the value is effectively "true".

Comment 19

[Lukas Blakk [:lsblakk] use ?needinfo]

Since this is a linux platform parity bug, not widespread, and seems hard to reproduce I'm removing tracking.