Re: Discussing Opal which implements Quartz on top of Cairo (was Re: google summer of code)

[BALATON Zoltan]

On Wed, 17 May 2006, Quentin Mathé wrote:
> That looks quite exciting. I can think of two possible interesting uses right 
> now. First one would be the possibility to compile Camino in straight forward 
> way (thanks to GCC 4.1 and Nib compatibility work done by Gregory Casamento), 
> they were in process of rewriting the code used by their web view from 
> QuickDraw to Quartz, it might be not yet finished (I didn't check recently).

To me this does not look so straight forward considering the complexity of 
the mozilla codebase but it is certainly an interesting project.

> The other one would a comprehensive Quartz backend for GNUstep, allowing to 
> bypass the X11 barrier/dependency.

This is exacly what I was considering. IMO the advantages of having an API 
which follows the Quartz API built using cairo would bring us the 
following advantages:

Using Cairo provides:
- Antialiased drawing and accelerated compositing on X (via XRender
  extension or OpenGL)
- Windows backend for free (cairo aims to have win32 output which is
  maintained by their developers and not using up our scarce resources)
- Printing via cairo's PDF and PS backends

Opal adds to this:
- Additional source code compatibility for apps using Quartz for drawing
  (demonstrated using unchanged apple sample code; with nib compatibility
   it would be possible to compile the samples almost without modification)
- Documented API on which GUI, PDFKit, etc. can be built
- apple-apple-gnu library combo is not that theoretical any longer
  (this could lower the access barrier for more gui developers)

> > Currently implemented are:
> > - CGAffineTransform, CGGeometry: reused from base/gui with some
> >  optimisations
>
> I suppose that means you are calling base/gui code from Opal ?… or perhaps 
> you just copied the code and reworked it.

I just copied and did minor optimisations. Opal currently does not depend 
on GNUstep and is in plain C. The idea is to use it as a base for gui so 
it cannot depend on gui itself. The only common parts between CGGeometry 
and NSGeometry in base probably does not justify depending on base, so the 
optimisations could just added back to base from Opal and have the same 
code at to places (this is not a good thing to do normally but avoids 
dependency beetween base and Opal).

> > - CGColorSpace, CGColor: RGB and Gray color spaces supported without color
> >  management (I have further ideas on how to improve it)
>
> Do you mean you have plans to extend GNUstep with color management support ?

I have plans to extend CGColorSpace with color management (at first only 
support for different color spaces and conversion between them, not full 
color matching but that may also be possible). This could be used from 
GNUstep as well.

> > - CGFont: Enough to get fonts from Fontconfig for CGContextSelectFont
>
> Is there any code to support Fontconfig in GNUstep right now ?

I don't know but it is not needed. CGFont objects can also be created from 
FT_Face (Freetype2) font objects via CGFontCreateWithPlatformFont. I've 
only used Fontconfig because Cairo depends on it already and it was easier 
to implement CGContextSelectFont this way.

> Isn't GGPath quite similar to NSBezierPath ?

It is, but to be able to interoperate with a cairo context I'd rather use 
cairo's path implementation instead to avoid unneded conversions and 
consistent behaviour with the CGContextAdd* functions. The problem with 
this is that currently cairo only have public API to get a path from a 
context and add it back, but it does not provide public functions to 
manipulate the copied path (needed for MutablePath's). Such an API was 
mentioned to be added to Cairo but it is not clear when. Currently I see 
two possible ways around it: either create a dummy context and manipulate 
the path on it and only copy/convert when needed or use cairo's internal 
API (which then needs careful version checking or including the cairo 
source code in Opal).

> > - CGPattern and CGShading maybe possible with Cairo although the APIs
> >  differ somewhat
>
> I think there is still no pattern drawing support in GNUstep, Fred was 
> planning to add it… well, it's possible it's done now and I missed it.

Cairo does have implementations for this but they may be more limited than 
the Quartz ones currently. I didn't looked at them more closely yet.

Regards,
BALATON Zoltan