Closed Bug 111152 Opened 23 years ago Closed 21 years ago

SVG doesn't render in all pixel formats

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jmt, Assigned: alex)

References

Details

(Whiteboard: [Hixie-P1])

Attachments

(6 files, 3 obsolete files)

updated liabrt patch
13.96 KB, patch
Details | Diff | Splinter Review
updated layout patch
17.40 KB, patch
Details | Diff | Splinter Review
Color test for SVG to HTML using Named WEB Safe colors
2.64 KB, text/xml
Details
What I see for the testcase
88.49 KB, image/jpeg
Details
Example showing shapes changing on highlight.
18.29 KB, image/jpeg
Details
build log: 2003092322 firebird + SVG_20020806_BRANCH
7.07 KB, text/plain
Details
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.
the code is enabled by an #ifdef, see the #define at the top of nsSVGRenderingContext.cpp
The patches have mangled line-endings, will post updated versions once I've got this working on Linux too.
+ #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 : 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?
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 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.
Checked in on SVG_0_9_6_BRANCH.
Attached patch patch for layout (obsolete) — — Splinter Review
(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?
Attachment #58682 - Attachment is obsolete: true
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.
Attachment #58683 - Attachment is obsolete: true
Attachment #60609 - Attachment is obsolete: true
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.
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!
Oh - one more thing broken on Windows: 4) Printing. This used to work o.k. before (albeit at the wrong scale).
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 ... ;-(
#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?
X is broken at 24/32 and at 32/32 bpp works dorrectly at 16bpp
Blocks: 118112
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).
Status: NEW → ASSIGNED
Alex Fritze: Will this fix print support, too ?
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.
*** Bug 118112 has been marked as a duplicate of this bug. ***
*** Bug 126136 has been marked as a duplicate of this bug. ***
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.
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
(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)
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
Whiteboard: [Hixie-P1]
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.
Summary: libArt needs to support native pixel formats → SVG doesn't render in all pixel formats
Blocks: 126121
*** Bug 126121 has been marked as a duplicate of this bug. ***
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. ...
Blocks: 132762
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*.
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).
> 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.
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).
> 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.
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 ?
> 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.
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.
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).
> 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.
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.
*** Bug 135881 has been marked as a duplicate of this bug. ***
*** Bug 141709 has been marked as a duplicate of this bug. ***
*** Bug 142946 has been marked as a duplicate of this bug. ***
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.
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
*** Bug 147592 has been marked as a duplicate of this bug. ***
But in the latest CVS build (5/27/02) I still get only gray. X 4.1.0
Blocks: 148623
I see all SVG demos in grey tones. Sometimes glitches of color. Sometimes (on redraw), shapes change aspect ratio.
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?
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)
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
*** Bug 176863 has been marked as a duplicate of this bug. ***
Depends on: svgbranch
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.
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.
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
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
Re #57 Lieven: Thanks for reporting the Windows color swapping. This is now fixed in CVS on SVG_20020806_BRANCH.
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.
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.
Build was failed with 2003092322 firebird + SVG_20020806_BRANCH and 2003092317 firebird + SVG_20020806_BRANCH source. It was succeeded 2003092117 firebird + SVG_20020806_BRANCH.
*** Bug 220554 has been marked as a duplicate of this bug. ***
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
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.
Fixed by bug #182533.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: