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

[David Chisnall]

On 2 Jan 2010, at 23:45, Riccardo Mottola wrote:

> I despise that choice, having a hard dependency on cairo is bad, as  
> much as Fred likes that. I have yet to see those backens match xlib  
> in flexibility and speed of several operations.

Flexibility?  The xlib back end doesn't support transparency or  
antialiasing.  Speed... maybe, in an increasingly limited set of  
cases.  Supporting new X extensions requires adding new code in the  
back end, which no one is doing.  Using Cairo, we take advantage of  
hardware acceleration and so on.

> We must consider that workstations are not our only target.  
> Increasing so in the future. Depending on something like libart or  
> cairo for a small netbook or a handheld is too much of a burden.

Absolutely not true.  Modern handhelds don't just come with a GPU,  
they come with a GPU which has a fully programmable shader pipeline.

There's a reason why UIKit is fundamentally different to AppKit; the  
constraints of modern handhelds are very different to the constraints  
of an '80s workstation.  Compositing is now much faster because it can  
be done in hardware and wasting RAM (for buffers) is vastly better  
than wasting CPU cycles drawing:  RAM uses a roughly constant amount  
of power, while the CPU uses more when it's in use, so you get better  
power usage by using a CoreAnimation-like model than the old AppKit  
model.  You also have a vastly higher ratio of RAM to pixels on an  
older handheld like the Nokia 770 than you had on the best  
workstations NeXT ever sold.

> Portability is also a major concern, since cairo isn't that portable  
> at all. (Just to cite, it doesn't support the not-so-ancient mac  
> 10.3.x).

OS X 10.3?  It's not a supported platform by Apple.  Other projects  
have already dropped support for it long ago.  VLC doesn't even  
support 10.4 anymore.  Supporting old platforms should never come at  
the expense of new features.  I'm entirely in favour of keeping  
support for older platforms where possible, but if the choice is  
between crippling new platforms or dropping support for old ones, then  
we have to drop the old platforms or we become irrelevant.

Cairo currently supports xlib, Win32 and BeOS, and work-in-progress  
back ends include OS/2, DirectFB, OpenVG (which will be hardware  
accelerated in the next generation of mobile devices) and OpenGL.  It  
also supports outputting to a memory buffer, which will work on any  
vaguely POSIXy platform.

This will dramatically simplify -back and, most importantly, bring the  
Win32 back end up to feature parity with the UNIX back ends.  Rather  
than having separate drawing implementations for every platform, we'll  
just have a single drawing implementation, using a third-party  
abstraction layer that we don't have to spend any developer resources  
maintaining, and a thin -back implementation for creating windows and  
generating NSEvents.

This will make supporting new platforms easier, not harder.  A new - 
back implementation will no longer need to implement something like a  
lightweight PostScript VM, it will just need to do the things that are  
really platform-specific.

> I like Felipes idea of doing things at the low level, on the other  
> hand I can understand that if it is available in Cairo, why not use  
> it?


Exactly.  Cairo is already there.  Cairo contains a massive amount of  
code to use the newer X11 features when they are there and fall back  
to primitive X11 stuff when they are not.  We have two choices:

- Use Cairo.
- Reimplement 90% of Cairo's features on every platform that we want  
to support.

My vote goes to the first option, but if someone else is willing to  
put in the effort of doing the second then they're welcome to, as long  
as they are willing to make a commitment to maintain it and ensure  
that it performs well compared to Cairo.

David

-- Sent from my Cray X1