111152 - SVG doesn't render in all pixel formats

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[James Turner]

In order to work at all under Mac (which has no 24-bit color mode), and to work
efficently (and support foreign objects) under Linux, the libArt code needs to
support rendering to surfaces with a format other than 24-bit byte-packed.

The attached patches : add support to art_render_new for choosing a pixel-format
and modify the SVG code to use nsDrawingSurface::GetPixelFormat and then create
the ArtRender with the appropriate format.

Comment 1

[James Turner]

Attachment: change SVG to use to pixel-format support in libart

the code is enabled by an #ifdef, see the #define at the top of
nsSVGRenderingContext.cpp

Comment 2

[James Turner]

Attachment: change libArt to accept a pixel-format argument to art_render_new

Comment 3

[James Turner]

The patches have mangled line-endings, will post updated versions once I've got
this working on Linux too.

Comment 4

[Bradley Baetz (:bbaetz)]

+                                        #ifndef SVG_LIBART_PIXEL_FORMAT
+                                          |  NS_CREATEDRAWINGSURFACE_24BIT
+                                       #endif 

I thought that the plan was to not require that, give the lack of support for it
on non-windows platforms?

Comment 5

[James Turner]

Comment : indeed, the 24 bit stuff can be removed; the patch is just me doing
least change so it's obvious what is happening. BTW I applied on Linux, defined
USE_SURFACE to 1 and everything compiled fine (I had to change some tests in
testart.c to compile, or you can just remove testart from the build).

However, it segfaults on any SVG page : no doubt some dumb mistake. I'm having
some trouble debugging, becuase when I run  './mozilla -g', DDD starts, I hit
'run', and it promptly dies in an PR_ASSERT *really* early on. (doing XPCOM2Init)

Any suggestions on how to get further with debugging?

Comment 6

[Bradley Baetz (:bbaetz)]

well, lets get rid of the old stuff. We should support the test programs too -
it won't be too much effort to keep them working, will it? For one thing,
testart will be able to tell you whether its libart with the problem, or mozilla.

To debug, you want a cvs gdb, and to see:
http://www.mozilla.org/unix/debugging-faq.html

I won't be able to touch this til Wed or Thu at the earliest.

If it asserts before crashing, then you can get a back trace by setting
XPCOM_DEBUG_BREAK=stack before running (w/o the debugger). This will print out
an approximate stack whenever we hit an assertion.

Comment 7

[Bradley Baetz (:bbaetz)]

Comment on attachment 58683 [details] [diff] [review]
change libArt to accept a pixel-format argument to art_render_new

Just eyeballing the patch (haven't applied it yet), where do you use
ART_PF_GREEN_6_MASK? The render->depth == 8 vs 5 looks strange, too.

Comment 8

[Alex Fritze]

Checked in on SVG_0_9_6_BRANCH.

Comment 9

[Bradley Baetz (:bbaetz)]

Attachment: patch for layout

(Hmm, lost my comment. Oh well)

The attached patch modifies James' in order to not create the locked buffer
each time. This is really expensive on unix, ebcause we go from server->client
image, and then back. > 50% of the time was taken in doing this w/o my change

Some problems:

a) colors are wrong, becuase my display is 565, not 555.

b) Something wierd is happening (even with teh original patch). Try teh xbl
demo with the movable triangles. If the shape is at the top left of the window,
everything is fine, but as you move it, you get wierd clipping artifacts. I
have no idea what is causing this - are we getting clipping on the view wrong
somehow?

James, afri - ideas?

Comment 10

[Bradley Baetz (:bbaetz)]

OK, I spent _ages_ tracing down a bug in the code, where only part of the image
was displayed. This turned out to be two things:

1) The clip region is inherited by the new drawing surface, so we have to move it.
2) bug 114255, where updating the clip rect, then creating the drawing surface,
didn't actually change the clip rect.

I've also fixed the 565 issue, and replaced the c++ style comments in libart
with c ones.

Note that art_render_clear_rgb will cause a crash, so Don't Do That.

Foreign object sort of works, but I think I broke update notification, or
something. If you take circles3.xml, then the jpeg doesn't display. If you load
the jpeg, then the .svg, it does work. Also, text wrapping is wrong.

Alex, any ideas?

This needs to be tested on win and mac, so that it can be committed for 0.9.7
(ie tomorrow...) If it works, then I think it should go in, and we can iron out
the minor bugs later.

Comment 11

[Bradley Baetz (:bbaetz)]

Attachment: updated liabrt patch

Comment 12

[Bradley Baetz (:bbaetz)]

Attachment: updated layout patch

Comment 13

[Bradley Baetz (:bbaetz)]

OK, this has been checked in. There are issues with 32 bits on windows, apart from:

  /* extract the pixel size (in bits) and divide by 8 */
  int dst_pixstride = (render->pixel_format & ART_PF_PIXEL_SIZE_MASK) >> 8;
  
which is clearly wrong (it should be << 3), it appears hard coded for mac format.

<foreignobject> doesn't work correctly on linux, either, ATM.

Leaving open for those issues.

Comment 14

[Alex Fritze]

So, to summarize, the things broken by this patch on Windows are:

1) 32bpp mode: weird colors (maybe an endian-issue?) + horizontally squished
   (fixed by '<<8' -> '<<3', but is this correct on Mac?)
2) paletted modes (and other weird modes): We'll need to fall back onto our old 
   method for these.  At the moment we just crash.
3) resolution changing: When changing resolution you have to restart Mozilla or 
   the displayed svg will be screwed. Worked before.

Help wanted!

Comment 15

[Alex Fritze]

Oh - one more thing broken on Windows:
4) Printing. This used to work o.k. before (albeit at the wrong scale).

Comment 16

[Roland Mainz]

Printing may be more problematic as it does not have support for alpha-channel
nor offscreen drawing surfaces.

Rendering the whole thing at the client side in the printers resolution is no
option, too - except you have some hundred MB of main memory for this task ...
;-(

Comment 17

[Stuart Ballard]

#1 also seems to apply on Linux/X - at least, I'm seeing weird grayscale-like
colorings and some bizarre positioning effects in 32bpp in 0.9.7 linux on all
the SVG samples on croczilla. Daa reproduced the problem on X (on irc #svg) and
confirmed that it's 32bpp only.

Is a fix for this in the works?

Comment 18

[david avery]

X is broken at 24/32 and at 32/32 bpp works dorrectly at 16bpp

Comment 19

[Alex Fritze]

There is an easy fix for all of the display problems associated with this bug: 
Back out the native pixel-format patch and revert to the old method of 
rendering (using nsIImage) on Linux and Macintosh. 
Doing that would break support for <foreignObject>s on those platforms, but I 
think that is not such a big deal, since foreignObjects don't work that well 
anyway (e.g. if you put an iframe into a <foreignObject>, it doesn't adhere to 
the z-order, rotation doesn't work, etc, etc).

Comment 20

[Roland Mainz]

Alex Fritze:
Will this fix print support, too ?

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I told you guys you'd need view manager support to handle foreignObjects sooner
or later :-).

After 1.0 we should work out how to fix things up so foreignObject always works.

Comment 22

[david avery]

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

Comment 23

[Bradley Baetz (:bbaetz)]

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

Comment 24

[Steve]

Hi All

I'll put up a color page of stripes for testing and post it here and at the
newsgroup. Red is not the only color effected.

Seeing the same thing in. 
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.8+) Gecko/20020215

Hadn't noticed before , am usually running 16 bit.

Comment 25

[Steve]

Hi All

Here is a color test page using safe, named colors.
AT 16bit okay, at 32 bit, not okay.

http://www.skeeter-s.com/svg/color-test.xml

However also check out the Gecko Icon up in the upper left
corner of the browser, perhaps this means something else.
Its color is also wrong at 32bit

-- 
steve
http://www.skeeter-s.com/svg
SVG examples for Mozilla unplugged

Comment 26

[Peter Henderson]

(WinME)
Test URL looks fine for me at 16 bit. My video card won't get up to 32, but at
24 bit all the red and blue channels are switched. For example, yellow (#ffff00)
and aqua (#00ffff) are swapped. Same with all the other combinations (green
channel is good, but red and blue channels are switched).

(Gecko icon looks fine at both 16 and 24, again I couldn't test at 32)

Comment 27

[Steve]

Hi
Perhaps the ico thing was just my screen I was jumping back and forth without a
new start.

I have added background color to the named colors.

Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.8+) Gecko/20020215

Comment 28

[Alex Fritze]

I'm renaming this bug to "SVG doesn't render in all pixel formats". 
For two reasons, supporting native pixel formats in libArt seems to be somewhat 
of a dead end. Firstly, there are so many different possible pixel formats 
(think paletted) that it would be a major job to add support for all of them; a 
job that we don't have the resources for. Secondly, libArt is designed to work 
in only one pixel format and to do so well. I think it would be hard to 
convince libArt users outside of Mozilla that multiple pixel formats are the 
way forward. So by going against mainstream libArt development we'd invariably 
be forking the code. That can't be a good thing.
As it stands, a large proportion of bugs reported on SVG can be traced to our 
current incomplete native pixel support. I suggest we sharpishly go ahead with 
the approach described in comment #19.

Comment 29

[Alex Fritze]

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

Comment 30

[Roland Mainz]

Alex Fritze write:
> I suggest we sharpishly go ahead with the approach described in comment #19.

You are aware that such an early design decision will it make impossible to
print SVG some day, right ?
Rendering the whole thing using nsIImage to a printer will result in very large
job sizes, for example DIN-A4 at 300DPI gives (2400 * 3150 * 24) / (3 * 1024 *
1024) = ~58MB
600DPI will be four times larger etc. etc. ...

Comment 31

[Alex Fritze]

By using libart we're using a 'lowest common denominator'-approach to 
rendering. Yes, it is slow and memory-intensive (both for rendering and 
printing), but at least it works without needing much in the way of OS support. 
Furthermore, as for printing, many (most?) printers don't support the necessary 
primitives for full SVG rendering, so sending a raster image is the only 
option. Even Postscript doesn't support things like transparency, so you'll 
have to rasterize in the worst case.
The long-term solution to these problems is to use the OS-native rendering APIs 
and maybe keep libart around as a fallback.  MacOS X should be able to handle 
all our rendering, and on Windows we could use GDI+.
Anyway, IMO, whatever we do, any moves to more comprehensive rendering API 
should be done as part of a gfx rewrite and not just patched on for the SVG 
code. In the meanwhile, changing back to rendering via nsIImage isn't so much a 
major design decision; it is just a quick move to make the current code *work*.

Comment 32

[Roland Mainz]

Alex Fritze wrote:
> By using libart we're using a 'lowest common denominator'-approach to 
> rendering. Yes, it is slow and memory-intensive (both for rendering and 
> printing), but at least it works without needing much in the way of OS 
> support.

A 58MB print job cannot be printed. This is a DDOS-attack against a printer -
even those ones which have 128MB builtin memory refuse to print such a print
job.

> Furthermore, as for printing, many (most?) printers don't support the 
> necessary primitives for full SVG rendering, so sending a raster image is 
> the only  option. Even Postscript doesn't support things like transparency, 
> so you'll have to rasterize in the worst case.

Not really. The resolution of PostScript printers (>= 300DPI) is high enougth to
do some rendering "tricks" to "emulate" alpha ("stipple alpha" rendering)
without getting an ugly result. I tried this with a 300DPI printer and a
modified Xprt version and an extension to add alpha channel support to the X
rendering API and the results are very good.

> The long-term solution to these problems is to use the OS-native rendering 
> APIs and maybe keep libart around as a fallback.  MacOS X should be able to 
> handle all our rendering, and on Windows we could use GDI+.
> Anyway, IMO, whatever we do, any moves to more comprehensive rendering API 
> should be done as part of a gfx rewrite

Is there any ToDo list for this gfx rewrite ?

> and not just patched on for the SVG 
> code. In the meanwhile, changing back to rendering via nsIImage isn't so much 
> a major design decision; it is just a quick move to make the current code 
> *work*.

Sure, but we should not design it in a way which makes it impossible to print
the whole thing (see the initial comment about job size).

Comment 33

[Alex Fritze]

> Sure, but we should not design it in a way which makes it impossible to print
> the whole thing (see the initial comment about job size).

The design decision that impacts printing has already been made: it is that we 
decided to use libart. Whether we render through an nsIImage or directly to an 
nsISurface is irrelevant from the point of view of printing. 
I don't see how we can fully address the printing issue without going over to 
platform native apis in the long term. 
Also, while you might be able to do some tricks on postscript, most printers 
can't even do postscript. Think of all the low-cost inkjets in circulation. You 
will have to send the full 58MB in one way or another. 
For the medium term, one thing we could look at to make these large files 
printable is banding, where we cut a page into stripes and render to each 
stripe individually. The GDI prints like that IIRC.

Comment 34

[Roland Mainz]

Alex Fritze wrote:
> > Sure, but we should not design it in a way which makes it impossible to 
> > print the whole thing (see the initial comment about job size).
>
> The design decision that impacts printing has already been made: it is that we 
> decided to use libart.

Just wondering: Why do we depend on libArt ?
AFAIK the "old" SVG code did not depend on it - and worked perfectly (for the
demo pages... :)
Using libArt seems to have various disadvantages - we can't print, can we never
make SVG part of the default build due the licensing issues...

> Whether we render through an nsIImage or directly to an 
> nsISurface is irrelevant from the point of view of printing.

What about using vector rendering calls (for example (X11 API, PostScript has
similar things), XDrawArcs(), XDrawPolygon(), XSetLineAttributes() etc.) instead
of rendering to an image (I know - we have to support the alpha channel- but
that can be "done" by a clever stipple algorithm for PostScript/Xprint stuff) ?

> Also, while you might be able to do some tricks on postscript, most printers 
> can't even do postscript. Think of all the low-cost inkjets in circulation. 
> You  will have to send the full 58MB in one way or another. 

This is more or less covered by the PostScript case, too. For
non-"PostScript-able"-printers the GhostScript driver has to do the conversion -
but the stipple-alpha code can still be used (and is still better than the 
fully rasterised version - stipple alpha images can be compressed better using
the simple algorithms used for those inkjet printers (RLE comes in mind)) in
this case.

> For the medium term, one thing we could look at to make these large files 
> printable is banding, where we cut a page into stripes and render to each 
> stripe individually.

I am still not sure whether there will be a difference between one large image
in a 58MB job or (for example) 16x16 smaller images in a 58MB job.

> The GDI prints like that IIRC.

a) Isn't banding driver-specific ?
b) Using GDI won't help for PostScript (Mac, Unix) nor for Xprint (Unix).

Comment 35

[Alex Fritze]

> Just wondering: Why do we depend on libArt ?

The standard Mozilla rendering context doesn't provide enough functionality to 
render svg. Among other things we need beziers, stroking, alpha-blending and 
anti-aliasing. Also, libart gives us structures on which we can do things like 
mouse hit testing. We need hit-testing for dynamic svg.

> AFAIK the "old" SVG code did not depend on it - and worked perfectly (for the
> demo pages... :)
The old code could do nothing more than draw lines and polygons. No 
antialiasing, no transparency, no dash styles, no curves, no ellipses, no 
interactivity.

> What about using vector rendering calls (for example (X11 API, PostScript has
> similar things), XDrawArcs(), XDrawPolygon(), XSetLineAttributes() etc.) 
> instead of rendering to an image (I know - we have to support the alpha 
> channel- but that can be "done" by a clever stipple algorithm for 
> PostScript/Xprint stuff) ?

I don't believe that SVG can be mapped onto the X11 API unless someone shows me 
otherwise. At least it wouldn't look nice. We'd really need XRender. Also X11 
is only one platform. So this is not a cross-platform approach. I conceed that 
we will have to go platform-native at some stage. But it will be a *big* job 
and one that shouldn't just be done in the context of SVG.
We should really discuss these broader issues on a different bug. In the short 
term I don't see any way of moving platform-native. Let's restrict this bug to 
what it originally was: fixing the rendering on those pixel-depths where it 
currently is failing.

> This is more or less covered by the PostScript case, too. For
> non-"PostScript-able"-printers the GhostScript driver has to do the 
> conversion -
As far as we're concerned for the SVG implementation, we'd like something 
higher-level then postscript. We don't want to have to use some 'clever stipple 
algorithm', we want our api to support true alpha. 
The postscript-ghostscript pipeline is a very unix-centric view of printing. 
Why force postscript into the equation anyway when most printers can't do 
postscript? 
Printing should really be the OS's job and we should rely on the OS to present 
us with a suitable graphics api that abstracts all output devices. 
I view postscript as just one of many rendering backends that need to be 
supported by a much higher level api in gfx.

Comment 36

[Roland Mainz]

Alex Fritze wrote:
> > Just wondering: Why do we depend on libArt ?
> 
> The standard Mozilla rendering context doesn't provide enough functionality to 
> render svg. Among other things we need beziers, stroking, alpha-blending and 
> anti-aliasing.

beziers and stroking can be emulated by X11 API, alpha-blending may be
difficult...

> Also, libart gives us structures on which we can do things like 
> mouse hit testing. We need hit-testing for dynamic svg.

Ah... OK...
 
> > AFAIK the "old" SVG code did not depend on it - and worked perfectly (for 
> > the demo pages... :)
> The old code could do nothing more than draw lines and polygons. No 
> antialiasing, no transparency, no dash styles, no curves, no ellipses, no 
> interactivity.
> 
> > What about using vector rendering calls (for example (X11 API, PostScript 
> > has
> > similar things), XDrawArcs(), XDrawPolygon(), XSetLineAttributes() etc.) 
> > instead of rendering to an image (I know - we have to support the alpha 
> > channel- but that can be "done" by a clever stipple algorithm for 
> > PostScript/Xprint stuff) ?
> 
> I don't believe that SVG can be mapped onto the X11 API unless someone shows 
> me otherwise. At least it wouldn't look nice. We'd really need XRender.

XRender is no option (at least in the next two or three years - and hopefully
someone comes up with a better solution). XRender is a Xfree86-only
(experimental ?!) extension not supported by any other X vendor. Xfree86.org is
not X.org - and as long as the X Consortium does not support XRender officially
there will be no support by other vendors (and even if X.org supports it it is
highly uncertain if the other vendors will implement it).
And XRender is limited in functionality and device support. For example... think
about devices with 8bit color displays...

> Also X11 
> is only one platform. So this is not a cross-platform approach. I conceed that 
> we will have to go platform-native at some stage. But it will be a *big* job 
> and one that shouldn't just be done in the context of SVG.
> We should really discuss these broader issues on a different bug.

Which one ? Is there any filed yet ?

[snip]
> > This is more or less covered by the PostScript case, too. For
> > non-"PostScript-able"-printers the GhostScript driver has to do the 
> > conversion -
> As far as we're concerned for the SVG implementation, we'd like something 
> higher-level then postscript. We don't want to have to use some 'clever 
> stipple algorithm', we want our api to support true alpha.

Sure... but not all devices support an alpha channel...

> The postscript-ghostscript pipeline is a very unix-centric view of printing. 
> Why force postscript into the equation anyway when most printers can't do 
> postscript?

We can add PCL[1] and other printer languages to the equation - and still get
the result that printers do not support an alpha channel... ;-(

[1]=Actually PCL5 has support for an alpha channel - but it does not work
properly on many printers... ;-(

> Printing should really be the OS's job and we should rely on the OS to present 
> us with a suitable graphics api that abstracts all output devices. 
> I view postscript as just one of many rendering backends that need to be 
> supported by a much higher level api in gfx.

OK... but what should we do when the OS API tells us that an alpha-channel is
not supported or only allows 1bit/2bit alpha depths ?

Comment 37

[Alex Fritze]

> beziers and stroking can be emulated by X11 API, alpha-blending may be
> difficult...

You're right. Everything can be emulated in X11. It's not a trivial task, 
though. But, in fact, fortunately we have a comprehensive emulation layer in 
place already. It can even do alpha-blending and anti-aliasing ... and it is 
called libart ;-) 
Could you emulate alpha-blending and anti-aliasing satisfactorily without 
rendering pixel by pixel? I doubt it. Stipple surely wouldn't look very nice on 
a screen? 
So unless we use a different API to X11, I don't see how we can get by with 
something lesser than libart.

>> We should really discuss these broader issues on a different bug.
> Which one ? Is there any filed yet ?

Not that I am aware of.

> XRender is no option (at least in the next two or three years - and hopefully
> someone comes up with a better solution).

Well - it looks like on Unix we'll have to fall back on libart for a while 
then. 

>> As far as we're concerned for the SVG implementation, we'd like something 
>> higher-level then postscript. We don't want to have to use some 'clever 
>> stipple algorithm', we want our api to support true alpha.
> Sure... but not all devices support an alpha channel...

Then it will have to be emulated by the driver or by the api backend. Not all 
devices support drawing of straight lines, and yet every graphic api has a 
function to this extent. When it comes to *modern* graphic apis, you'd expect 
the same for alpha.
And postscript doesn't help here. Next to no device (screen or printer) 
supports postscript natively. You don't want to embed postscript drivers for 
all possible devices in Mozilla, do you?

> OK... but what should we do when the OS API tells us that an alpha-channel is
> not supported or only allows 1bit/2bit alpha depths ?

That's my point about needing a *highlevel* gfx api. If the OS doesn't have 
alpha, well then gfx needs to emulate alpha. Better still, the OS driver should 
emulate it. At the moment we emulate alpha blending, anti-aliasing, etc., in 
the svg code using libart. In the long term we don't want to have to worry 
about these things in the *svg* code. Libart being used the way it is in the 
svg code is only a transitionary thing until gfx gets powerful enough. 

Comment 38

[Alex Fritze]

For one final thought on printing:

If postscript output is what we're after, maybe we shouldn't go through the 
usual rendering pipeline, but instead convert the svg file into a ps file using 
XSLT. Just a thought.

Comment 39

[Stuart Ballard]

I don't know a whole lot about postscript, but I do know it's a turing-complete
language.

Surely it would be possible to add a constant header to every ps print job that
would define functions to support alpha-channel? Said function could use "clever
stipple patterns" or just manually calculate a corrected csv (or whatever) value
based on the values originally located at the appropriate point.

I'd also suggest that a *short-term* solution would be to simply render the svg
image at screen-resolution and print that. Sure, you lose one of the main
benefits of SVG, but it's better than sending a print job that's guaranteed to
crash the computer. At least the content of the image will probably be legible
(at least if it was legible on screen).

Comment 40

[Alex Fritze]

> I don't know a whole lot about postscript, but I do know it's a turing 
> complete language.

Hey - we could port libart to postscript. Any FORTH programmers out there? ;-)

> I'd also suggest that a *short-term* solution would be to simply render the 
> svg image at screen-resolution and print that. Sure, you lose one of the main
> benefits of SVG, but it's better than sending a print job that's guaranteed to
> crash the computer. At least the content of the image will probably be legible
> (at least if it was legible on screen).

Maybe we could even go for some 'capped resolution' scheme, where we make the 
max image size a user preference and adjust the resolution accordingly. This 
scheme would ensure that in those cases where the SVG image is small, we get 
the best possible resolution.

Anyway - printing really is a separate issue to this bug.
I've just opened bug #133964, so that we can continue any SVG printing specific 
discussion there. 

Comment 41

[Roland Mainz]

Alex Fritze wrote:
> > beziers and stroking can be emulated by X11 API, alpha-blending may be
> > difficult...
> 
> You're right. Everything can be emulated in X11. It's not a trivial task, 
> though. But, in fact, fortunately we have a comprehensive emulation layer in 
> place already. It can even do alpha-blending and anti-aliasing ... and it is 
> called libart ;-) 
> Could you emulate alpha-blending and anti-aliasing satisfactorily without 
> rendering pixel by pixel? I doubt it. Stipple surely wouldn't look very nice 
> on a screen?

I was thinking of using "stipple-based" alpha-blending on printer resolution
which usually starts at 300 DPI. And at 600 DPI you need very very good eyes and
hold the paper 10cm away from your eyes to see such tricks...

> So unless we use a different API to X11, I don't see how we can get by with 
> something lesser than libart.

What are the requirements for an API to match the needs of Mozilla's SVG code ?

[snip]
> > XRender is no option (at least in the next two or three years - and 
> > hopefully
> > someone comes up with a better solution).
> 
> Well - it looks like on Unix we'll have to fall back on libart for a while 
> then.

The "while" may take (at least) two years (until the next version cycle of the
major Unix releases is done) or it will never happen because noone except
Xfree86.org implements it.
The other major issue is that Xrender can (AFAIK, please correct me if I am
wrong) not be supported on non-TrueColor devices - which means that any
(example!) embedded devices (which use PseudoColor, StaticGray or GrayScale
visual) will NOT work if you rely on Xrender.

Comment 42

[R.K.Aa.]

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

Comment 43

[R.K.Aa.]

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

Comment 44

[mental]

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

Comment 45

[Steve]

Attachment: Color test for SVG to HTML using Named WEB Safe colors

Just installed Mozilla 1.0.0+
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0+) Gecko/20020523
svg-mathml zip
and found out that now even at 16 bit the colors are being rendered false.

This was just in 24 and 32 bit, but now it is down to 16 bit also.
Build # with Gecko/20020519 was able to render 16 bit correctly.

Comment 46

[Steve]

Just installed
Mozilla 1.0.0+
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0+) Gecko/20020527
No change

Comment 47

[Bradley Baetz (:bbaetz)]

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

Comment 48

[hugo van woerkom]

But in the latest CVS build (5/27/02) I still get only gray. X 4.1.0

Comment 49

[Antonio Fiol]

Attachment: What I see for the testcase

I see all SVG demos in grey tones.

Sometimes glitches of color.

Sometimes (on redraw), shapes change aspect ratio.

Comment 50

[Gyles Harvey]

Attachment: Example showing shapes changing on highlight.

Just to add a "me too".

I'm running Moz 1.0, on Solaris 8, Suns Xserver and 24 bit colour.

I see essentially the same as Antonio.

To elaborate a bit on his "Sometimes (on redraw), shapes change aspect ratio."

In http://www.croczilla.com/svg/circles2.xml I see the attached after moving
over the circles a few times.

Should this bug get a priority & target?

Comment 51

[Steve]

Hi All

Using 
Mozilla 1.1b
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1b) Gecko/20020805

In 16 bit color depth -- Colors are now correctly rendered!
In 32 bit color depth -- Colors are not. (Can't check other depths)

Comment 52

[Steve]

Hello All

this is for windows, 
In:Mozilla 1.1b
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1b) Gecko/20020814
downloaded from here
http://www.croczilla.com/svg/mozilla-svg-gdiplus-20020814.zip

16 bit and 32 bit depth are now rendering correctly. See this
http://bugzilla.mozilla.org/attachment.cgi?id=85099&action=view

Or go to the net copy http://www.skeeter-s.com/svg/color-test.xml
This is great, also if you all haven't heard, this version from Alex is also
doing text!!!!!!1

Comment 53

[Nick Blievers]

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

Comment 54

[nemo]

Re: #52 
Well, it isn't doing text for me, but nice to see the colours show up correctly
again.

Nightlies still look as ugly as ever.

Comment 55

[Alex Butcher]

This bug is still present in the 1.3.1 release (tested under Linux/XFree86 4.3.0
at 24bpp depth). It renders perfectly in 16bpp (or was it 15bpp???), but I use
24bpp on a day-to-day basis.

Is there a secret way to get this working? I see the 60977/60978 patches appear
to be in the 1.3.1 tree already.

Comment 56

[Geoff Leach]

Confirming works for me. Linux, RHL 9.

Configure arguments

--enable-svg --enable-svg-renderer-libart --enable-calendar --enable-crypto
--enable-default-toolkit=gtk2 --enable-xft --enable-freetype2 
--enable-extensions --with-system-jpeg --with-system-zlib --with-system-png
--with-system-mng

Comment 57

[Lieven Buts]

After noticing some strange colors in the
tiger SVG example, I looked at the color test
page at http://skeeter-s.com/svg/color-test.xml
using Mozilla suite nightly build "2003091211"
(downloaded as 
mozilla-win32-svg-libart-mathml.zip).

Results:
Green, purple, gray, lime and silver are OK.
Red/blue, yellow/aqua, maroon/navy and teal/olive
pairs are swapped.

System settings:
Windows 98 4.10.1998
ATI 3D Rage Pro adapter
ATI drivers 9.15.1998
24-bit TrueColor @ 800x600 resolution

Comment 58

[Alex Fritze]

Re #57 
Lieven: Thanks for reporting the Windows color swapping. This is now fixed in
CVS on SVG_20020806_BRANCH.

Comment 59

[Takanori MATSUURA]

I also tested SVG_20020806_BRANCH source on the following environment.

OS: Red Hat Linux 9
Browser: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030917
Firebird/0.6.1+

attachment 85099 [details]
http://www.skeeter-s.com/svg/color-test.xml
http://www.skeeter-s.com/svg/
and some other sites shows SVG image properly.

I hope this fix should be reflected immediately to the mainstream CVS tree.

Comment 60

[Takanori MATSUURA]

Addittional tests.

All SVG files at
http://www.croczilla.com/svg/
are shown preperly except for
  foreign1.xml: browser is down if push the button in it.
  arcs1.xml: black bar(s) is displayed.

Comment 61

[Takanori MATSUURA]

Attachment: build log: 2003092322 firebird + SVG_20020806_BRANCH

Build was failed with 2003092322 firebird + SVG_20020806_BRANCH and 2003092317
firebird + SVG_20020806_BRANCH source.
It was succeeded 2003092117 firebird + SVG_20020806_BRANCH.

Comment 62

[Alex Fritze]

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

Comment 63

[Takanori MATSUURA]

Comment 61 is a temporally problem, not a bug. I checked build is successful at
2003092[458]17 firebird + SVG_20020806_BRANCH
2003092904 seamonley + SVG_20020806_BRANCH

Comment 64

[Alexandre Jasmin]

On unpatched, X11, gtk2 build of mozilla 1.5 SVG works correctly in 16bpp but at
24bpp the picture is gray and it seams to be translated or stretched.

Comment 65

[Alex Fritze]

Fixed by bug #182533.