Closed Bug 134708 Opened 19 years ago Closed 16 years ago

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


(Core :: SVG, defect)

Not set





(Reporter: bugzilla3, Unassigned)




(5 files)

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).
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.
what's the status of this?
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
I've encountered this bug myself using the 28.11.2002 SVG build at, 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.
After around 1/2 year ...

... what's the status of this bug?
Ever confirmed: true
*** Bug 231174 has been marked as a duplicate of this bug. ***
Did the backend rewrite done in bug #182533 fix this?
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.
OS: Linux → All
Confirming it's still there in the libart backend as well (mozilla 1.7b).
*** Bug 244061 has been marked as a duplicate of this bug. ***
Summary: SVG fragments should be composited with their background → SVG fragments should be composited with their background (transparent SVG gets white bg)
Mass reassign of SVG bugs that aren't currently being worked on by Alex to
general@svg.bugs. If you think someone should be assigned to your bug you can
join the #svg channel on's IRC server ( irc:// )
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. 
Assignee: alex → general
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.
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 to Makefile in
/layout/svg/renderer/src/libart/Makefile manually.

Beware, it could be all wrong as it's my first ever patch.
Attached file 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.
Cairo also just works if the nsISVGRendererCanvas::Clear call in
nsSVGOuterSVGFrame::Paint is removed.
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.
Looks good to me. I've tried the revised patch under WinXP (libart) and Linux
and it works for me.
Checked in.  Thanks.
Closed: 16 years ago
Resolution: --- → FIXED
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 and the .cpp file itself.
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).
You need to log in before you can comment on or make changes to this bug.