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

RESOLVED FIXED

Status

()

Core
SVG
RESOLVED FIXED
15 years ago
12 years ago

People

(Reporter: Robert Clark, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

15 years ago
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).
(Reporter)

Comment 1

15 years ago
Created attachment 77080 [details]
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.
what's the status of this?
(Reporter)

Comment 3

15 years ago
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

15 years ago
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

14 years ago
After around 1/2 year ...

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

Updated

13 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

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

Comment 7

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

Comment 8

13 years ago
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
(Reporter)

Comment 9

13 years ago
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 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. 
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.
Created attachment 163781 [details] [diff] [review]
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.
Created attachment 163782 [details]
Background to complex test case
Created attachment 163784 [details]
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

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

Comment 17

13 years ago
Created attachment 163860 [details] [diff] [review]
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.
Looks good to me. I've tried the revised patch under WinXP (libart) and Linux
and it works for me.

Comment 19

13 years ago
Checked in.  Thanks.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 20

13 years ago
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

12 years ago
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.