gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Discussing Opal which implements Quartz on top of Cairo (was Re: goo


From: BALATON Zoltan
Subject: Re: Discussing Opal which implements Quartz on top of Cairo (was Re: google summer of code)
Date: Wed, 17 May 2006 23:00:00 +0200 (CEST)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]