134708 - SVG fragments should be composited with their background (transparent SVG gets white bg)

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Robert Clark]

At the moment, SVG is always rendered with a white background. Instead it should
be blended with its surroundings (like a PNG with an alpha channel).

Comment 1

[Robert Clark]

Attachment: Simple inline SVG against a green background

Added test-case of inline SVG in an XML document. This is displayed as a black
rectangle in a white box against a green background, but should be displayed as
a  black rectangle against a green background.

Comment 2

[Kai Lahmann (is there, where MNG is)]

what's the status of this?

Comment 3

[Robert Clark]

Still awaiting confirmation, apparently. The test case is still broken in my
workaday browser (Moz1.0 +Xft +SVG).

I suspect this is probably dependent on the infamous #111152, but someone with a
better understanding of Mozilla's internals should verify this before adding a
dependency.

Comment 4

[Brad Neuberg]

I've encountered this bug myself using the 28.11.2002 SVG build at
http://www.croczilla.com/svg/, though using a different test case.  The SVG
element did indeed have a white background even though it should have been
composited with the background that was there (the SVG fragment was within a XUL
box).  This was on Windows XP.

Comment 5

[Alexander Opitz]

After around 1/2 year ...

... what's the status of this bug?

Comment 6

[Alex Fritze]

*** Bug 231174 has been marked as a duplicate of this bug. ***

Comment 7

[Erik Arvidsson]

Did the backend rewrite done in bug #182533 fix this?

Comment 8

[Marco Perez [:mpk]]

No, I'm afraid it didn't. This bug is still there (at least in the GDI build
2004022616). Changing OS from Linux to All.

Comment 9

[Robert Clark]

Confirming it's still there in the libart backend as well (mozilla 1.7b).

Comment 10

[Hixie (not reading bugmail)]

*** Bug 244061 has been marked as a duplicate of this bug. ***

Comment 11

[Jonathan Watt [:jwatt]]

Mass reassign of SVG bugs that aren't currently being worked on by Alex to
[e-mail]. If you think someone should be assigned to your bug you can
join the #svg channel on mozilla.org's IRC server ( irc://irc.mozilla.org/svg )
where you can try to convince one of the SVG hackers to work on it. We aren't
always there, so if you don't get a response straight away please try again later. 

Comment 12

[Brian Birtles (:birtles, Feb 26~ parental leave)]

I've had a look at this bug. For GDI+ it's trivial, just removing the call to
paint the canvas white in nsSVGOuterSVGFrame::Paint does the trick but of course
this causes problems for the other backends (in libart it causes the background
to become grey).

For Libart the problem seems to be that it is drawing to an nsIImage which uses
a separate RGB buffer and alpha buffer but libart doesn't seem to support
writing a separate alpha buffer.

Three options I can think of are:

1. Change libart. This doesn't seem to be good option as described in bug
111152, comment 28.

2. Get libart to write an RGBA image to a temporary buffer and then when Flush()
is called on the LibartBitmap object, copy the RGB and Alpha data to the
appropriate buffers of the nsIImage.

3. Mirror all libart drawing commands using appropriate graymap equivalents
(e.g.  art_svp_gray_aa) to the alpha buffer. I tried this and these commands
overwrite the buffer meaning that we would have to composite each result manually.

I've written a patch for option 2. It's not ideal as it means twice the amount
of buffer space is required (one for the nsIImage and one for the temporary
buffer although this is freed when the nsSVGLibartBitmapAlpha object is destroyed).

Of course, I could be all wrong about this. I'm new to all this.

I haven't looked at Cairo yet.

Comment 13

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Attachment: Draft patch to support compositing with libart

Here is my patch for option 2. I've tested it on GDI+, Libart under WinXP and
Libart under SuSE 9.1.

No idea what would happen under Mac.

It's not complete in any sense as I don't know what Cairo will do when you
remove the call to paint the canvas white in nsSVGOuterSVGFrame::Paint.

You might have to apply the changes from Makefile.in to Makefile in
/layout/svg/renderer/src/libart/Makefile manually.

Beware, it could be all wrong as it's my first ever patch.

Comment 14

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Attachment: Background to complex test case

Comment 15

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Attachment: More complex test case

Here is a test case I used which shows more clearly the results of
anti-aliasing and translucency.

Should have an animated background but if you don't have PSM installed it won't
be able to find the GIF.

Comment 16

[tor]

Cairo also just works if the nsISVGRendererCanvas::Clear call in
nsSVGOuterSVGFrame::Paint is removed.

Comment 17

[tor]

Attachment: Brain's patch with modifications for MacOS

Thanks for taking a look into this.  Here's a version of your
patch extended to support MacOS - pretty much just extending
nsSVGLibartBitmapAlpha::Flush and changing the Makefile.  If
you're happy with these changes we can check it in.  About the
only extra thing we might want to do is entirely remove
nsISVGRendererCanvas::Clear, as it isn't used anymore, but
that can be done separately.

Comment 18

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Looks good to me. I've tried the revised patch under WinXP (libart) and Linux
and it works for me.

Comment 19

[tor]

Checked in.  Thanks.

Comment 20

[Robert McGovern]

How is the newly added nsSVGLibartBitmapAlpha.cpp called? I just did a find on
the source tree for nsSVGLibartBitmapAlpha and the only references I found were
the Makefile.in and the .cpp file itself.

Comment 21

[Tiago Freire]

Isn't Cairo the only backend now? I read the others were deprecated. If so, Is
this really fixed? Firefox 1.0.7 still paints the BG white (linux).