If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Implement the SVG rendering back end using Quartz 2D

RESOLVED WONTFIX

Status

()

Core
SVG
--
enhancement
RESOLVED WONTFIX
14 years ago
4 years ago

People

(Reporter: hsivonen, Unassigned)

Tracking

({perf})

Trunk
PowerPC
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
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).

Updated

14 years ago
Keywords: perf

Comment 1

14 years ago
Created attachment 129348 [details]
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

14 years ago
cc'ing peterv, because he's got a new quartz renderer.
Created attachment 143100 [details] [diff] [review]
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 ;-).
Attachment #129348 - Attachment is obsolete: true

Comment 4

14 years ago
Created attachment 143791 [details]
Quartz2D drawing status

An update on quartz 2D patched by Peter

Comment 5

14 years ago
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.
Blocks: 224213

Comment 6

14 years ago
Removing incorrect Camino block; bug 224213 has nothing to do with SVG.
No longer blocks: 224213
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
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?
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. 
(Reporter)

Comment 10

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

12 years ago
We're not taking this implementation route.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.