Re: Opal/CoreGraphics (was Re: UIKit?)

[Jeff Teunissen]

Gregory Casamento wrote:
> Eric,
> 
> On Sat, Jan 2, 2010 at 6:04 PM, Eric Wasylishen <ewasylishen@gmail.com> wrote:
>> Hey,
>>
>> As David mentioned, I implemented a bit more of Opal over the holidays 
>> (transparency layers,
>> and CGLayer). I think Balaton's approach of implementing CoreGraphics as a 
>> thin wrapper
>> over  Cairo is the right choice in terms of performance (should be 
>> excellent, especially
>> with Cairo's
>> new OpenGL compositor backend under development), completeness/output 
>> quality (should
>> closely match Apple's), and feasibility/minimal development effort. It 
>> currently implements a
>> fairly large subset of CG and is under 4k lines of code. I'll move it to the 
>> /dev-libs directory in
>> GNUstep SVN soon.
>>
>> There are a few ways we could use Opal in GNUstep. The possibility I am 
>> currently exploring
>> (planning to put in a branch in svn) is modifying -gui to use CoreGraphics 
>> directly. This would
>> entail making Opal a dependency of -gui, eliminating the Display PostScript 
>> api between -gui
>> and -back. -back would be reduced to the xlib and Win32 window server code.
> 
> I think this is a good idea, but I should mention that even Apple
> still has the Display Postscript operators/API available in spite of
> the fact that they are undocumented on Mac OS X.   They are, in fact,
> there.  :)   Even though they are not officially supported, it would
> be nice to keep support for them.
> 
>> At the cost
>> of not having a choice of graphics backend, this could make the code in -gui 
>> clearer, improve
>> performance, and make possible a CoreAnimation implementation and porting a 
>> larger set of
>> OS X applications.
> 
> GNUstep's backend was conceived of at a time when there weren't any
> cross platform graphics libraries such as Cairo.   Basically, this
> change would offload the work to support additional drawing backends
> onto the Cairo team, which has done an excellent job of making it work
> on a large number of platforms.

I see no reason that this "Opal" stuff needs to get involved in the back-end
at all -- just make everything use Cairo. Make that the basic level on which
all graphics APIs supported by GNUstep are handled.

Build the CG* library on top of Cairo, for the Mac people who are slumming in
the real world. Build the [D]PS* functions on top of Cairo, for the ex-NeXT
people with old code or old thinking, or who are merely "reasonable" and just
don't want to rewrite their code again...and then don't use EITHER of those to
build the AppKit (again, going directly to Cairo), except for a little bit of
shim stuff to make the three Cairo interfaces equivalent (totaling perhaps a
month of work).

Further, it seems that the correct course of action would be to allow (even
facilitate) access to Cairo itself from every level of the GUI (including user
code!!) without going through a clone of some OTHER API. If 85+ percent of
Opal (and 100% of DPS*) is just a shim over Cairo (and it is/would be), why
should I (or anyone else, for that matter) have to use Opal just to get access
to the stuff I want from Cairo?

PS/DPS* functions weren't there because NeXT implemented an API on top of
something else: they were there because the library implementing them was the
one the AppKit itself used. Then there were the GameKit mechanisms that
bypassed the AppKit and DPS almost entirely, allowing you to draw directly to
video memory.

Lastly, stacking APIs that do the same thing on top of each other only
increases the opportunity for hideous breakage, and for limitations or design
choices at one level to cause huge problems at another. The design patterns of
Core* are not the same as those of the AppKit; if they were, they'd be the
same damn library. So why the urge to build one on top of the other, when one
of them is already built on top of yet another (equivalent!) graphics API layer?

-- 
| Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek at d2dc.net
| GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project     http://www.quakeforge.net/
| Debian GNU/Linux            http://www.d2dc.net.ipv4.sixxs.org/~deek/