214912 - Implement the SVG rendering back end using Quartz 2D

Status: RESOLVED WONTFIX

(Core :: SVG, enhancement)

Description

[Henri Sivonen (:hsivonen)]

In order to make SVG (hopefully) faster on Mac OS X, in order to make it print
as vector graphics and in order to better integrate with the OS text/font
subsystems, it would be desirable to implement the SVG rendering back end using
Quartz 2D on Mac OS X.

Issues:
* Avoid unnecessary intemediate bitmapping in order to pass as much data as
paths to Quartz 2D as possible.
* How to do hit testing (point and path insideness testing) on the Quartz 2D level?
* Is it better to start with a copy of the GDI+ impl or the Libart impl?
* For QuickDraw/Quartz 2D mixing it would be good to know when a series of
consecutive SVG drawing calls starts and when it ends (in order to avoid per
drawing operation QuickDraw/Quartz switching).

Comment 1

[James Turner]

Attachment: Partial implementation of SVG renderer using Quartz

Well, here's something to get you started : the work I did about 6 months ago
to implement SVG rendering using Quartz. It compiles and links, but it doesn't
actually work, it needs major debugging. There is no text support, but all the
basic filling, stroking and hit-testing should be there (with bugs, of course).
No support for gradients or anything fancy either.

Issues
- will probably have rotted a bit
- My method for hit-testing is a bit clunky, relies on BitmapToRegion and
drawing the Quartz graphics into a 1-bit GWorld which I've grabbed a CGContext
for. However, this rather ugly process will only be done when style or content
changes, and it should give pixel-accurate hit-testing, even for hard cases
like dashed-stroke-patterns.

To get going, unpack the tarball in (I think) layout/svg/renderers, alongside
the gdiplus dir. You'll need to do some Makefile glue of course, but that
should be about it. Note that there should ne header or linker issues to
resolve, since there's already code in gfx that uses Quartz.

Any questions, please let me know.

Comment 2

[Alex Fritze]

cc'ing peterv, because he's got a new quartz renderer.

Comment 3

[Peter Van der Beken [:peterv]]

Attachment: v1.1

Plenty of problems left (crashes, text not implemented, foreignObject support
broken, ...), but it might be useful to some people who seem keen on doing it
all over again by themselves ;-).

Comment 4

[Kenneth C. Feldt]

Attachment: Quartz2D drawing status

An update on quartz 2D patched by Peter

Comment 5

[Peter of the Norse]

Adding a Camino bug as dependent. It already uses a mix of QuickDraw and Quartz
which causes a bug in 10.3. There has been talk in the message board about
moving over to pure Quartz, but there have been a lack of volenteers.

Comment 6

[Stuart Morgan]

Removing incorrect Camino block; bug 224213 has nothing to do with SVG.

Comment 7

[Jonathan Watt [:jwatt]]

Mass reassign of SVG bugs that aren't currently being worked on by Alex to
[e-mail]. 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. 

Comment 8

[Jonathan Watt [:jwatt]]

Kenneth, peterv: what's the status of this bug? Should it now be marked WONTFIX
if we plan to use cairo as a cross-platform renderer. Is anyone still working on
this? Did you move onto working on the cairo instead Kenneth?

Comment 9

[Michal 'hramrach' Suchanek]

As I read the first comment it was meant to make a fast implementation that uses
the vector drawing features of Quartz.
I do not know if Cairo is a functionally equivalent replacement.

If it does not use Quartz directly as originally intended by the Quartz backend
I would suggest postponing this until somebody wants to work on it. 

Comment 10

[Henri Sivonen (:hsivonen)]

This is not only about speed (though I expect Quartz to be faster than any
reinvention of the wheel on OS X) but also about getting vector graphics
printing right with transparency etc.

Comment 11

[tor]

We're not taking this implementation route.