Open Bug 487137 Opened 15 years ago Updated 2 years ago

layout/reftests/svg/opacity-and-gradient-01.svg fails on my Linux box

Categories

(Core :: Graphics, defect)

x86
Linux
defect

Tracking

()

People

(Reporter: dbaron, Assigned: jrmuizel)

References

(Blocks 1 open bug)

Details

layout/reftests/svg/opacity-and-gradient-01.svg fails on my Linux box, as of recently.  In a correct build, it's supposed to be green, but for me it displays a few green and yellow vertical stripes.

This regressed between Linux x86_64 nightlies 2009-03-20-04-mozilla-central (591d956f2f0a) and 2009-03-21-05-mozilla-central (8d17fb3a6197) and between Linux i386 nightlies 2009-03-20-03-mozilla-central (659355060532) and 2009-03-21-03-mozilla-central (d14de45019a0).  That gives a regression range of:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=591d956f2f0a&tochange=d14de45019a0 , which I think is almost certainly bug 484076.

I have no idea why it's showing up only on my machine and not on the tinderboxes.  I'm running Ubuntu 8.10 on amd64.
Flags: blocking1.9.2?
(In reply to comment #0)
> amd64.

.. would be my guess!

We don't have any 64-bit unit test machines, just builders (and, as I found out recently, nightlies.. despite having no testing).
except, as I noted above, I see this in the x86 builds too.
The cairo update is suspected of causing bug 485846 too which may be related as that's also about gradients.
David, do you see the effect described in bug 485846 on your Linux box too?
Nope... the test seems to match the reference perfectly, no matter what I do as far as resizing/scrolling the window.
I suspect (fear) it may be relevant that I have an Intel video card (Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller) and thus the intel X driver.
I decided to try a different X serve by using VNC.  It's also a little broken there, although differently: I see a single red stripe (at only some widths).  However, that brokenness is *not* a recent regression.

Not sure if that makes things more or less confusing...
I wonder if that driver claims to support gradients or something in XRender and we trust that... my patch to optionally force image surfaces isn't in yet, so it's not that easy to test that for SVG.  If you can reproduce it using canvas... well, crap, that env var isn't in there either.  Well, if you can reproduce using canvas you can edit nsCanvasRenderingContext2D::SetDimensions to call 'new gfxImageSurface' instead of CreateOffscreenSurface, and see if the bug remains.

I've got an intel linux box upstairs; will try this test there, not sure what driver I'm using.
I can confirm the same behaviour as dbaron reported, both on vnc and not. Using ubuntu 8.10 x86, it has Intel integrated graphics, lspci reports it as Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01).
The VNC part of this failure first regressed between the 2008-07-22-10 3.1a1pre and 2008-07-23-02 3.1a1pre nightly builds. It regressed by drawing the second of the three bars (fill-opacity) as black. That regression range includes a Cairo update (bug 446323, http://hg.mozilla.org/mozilla-central/rev/5305b356a7b1). And then the most recent Cairo upgrade (bug 484076) caused the black bar to turn red.

As for non-VNC, the second and third bars are drawn yellow (fill-opacity and stroke-opacity respectively).
Data point: I see this on my laptop which is (I think) the exact same model as dbaron's, but I *don't* see it when I run the reftests under Xvfb.

The magic command for anyone who wants to try that is

$ xvfb-run -a -s "-screen 0 1024x1024x24" make reftest
Blocks: 514067
Flags: blocking1.9.2? → blocking1.9.2-
Assignee: nobody → jmuizelaar
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.