Closed Bug 134708 Opened 19 years ago Closed 16 years ago
SVG fragments should be composited with their background (transparent SVG gets white bg)
433 bytes, text/xml
16.24 KB, patch
|Details | Diff | Splinter Review|
4.93 KB, image/gif
1.14 KB, application/xhtml+xml
18.87 KB, patch
|Details | Diff | Splinter Review|
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 dependency.
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.
After around 1/2 year ... ... what's the status of this bug?
*** 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 firstname.lastname@example.org. 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.
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.
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.
Status: NEW → RESOLVED
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 Makefile.in 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.