Re: User experience

[David Chisnall]

On 22 Dec 2013, at 17:00, Riccardo Canalicchio <riccardo.canalicchio@gmail.com> 
wrote:

> I think that gnustep has left behind the user experience during this years in 
> favors of portability.
> In my opinion, users and developers choose cocoa, firstly for the user 
> experience.
> We need a properly backed drawing for smooth animations and maybe an 
> accelerated window compositor (if GNUstep choose the "we are a desktop" 
> roadmap).
> 
> What do you think guys about an hardware accelerated drawing?

That depends on what you mean by drawing.  Aside from a couple of experimental 
things, I don't think I've seen anyone using hardware acceleration for line 
drawing recently, because the extra cost of sending all of the commands across 
the bus offsets everything else.  

On the other hand, hardware-assisted compositing is definitely a sensible thing 
to do.  Opal intends to support this, and Ivan's summer of code project made 
some progress in this direction last year.  

Doing it well requires restructuring the back end somewhat so that every 
drawing context is rendering to a memory buffer and then the window (or, for 
UIKit, screen) context will handle the compositing.

> Cairo is great, but is missing some important feature for modern UI.
> Currently is not possible to do blurs or shadows, animation are slow and I 
> think that this influence the overall experience of GNUstep.

Cairo does support these things, and Opal lets us use them.  

> I know that is possible to use cairo trough OpenGL but right now is missing 
> all the image filter part..

The image filter part is to do with the compositing layer, rather than the 
drawing layer.  Once you have a rendered view in an OpenGL texture, you just 
need to run a shader on the texture when you do the compositing.  Apple has 
moved to using OpenCL for these, so it's easier to be interoperable than 
before...

> I have looked at Skia, the graphic library used by google chrome:
> https://code.google.com/p/skia/
> 
> seems very nice and has already implemented most image filter directly on GPU

Skia is nice.  It's also likely to be supported by NaCL / PNaCl, which would be 
a very interesting deployment target.

At the moment, a more pressing concern is finishing up the CoreAnimation stuff. 
 This is really important for battery life on modern machines and for smooth 
effects.  It's also a prerequisite for CoreAnimation, which restructures the 
entire UI around composited layers exclusively - it's a nice addon for AppKit 
but absolutely essential for UIKit.  

We have an unfinished implementation that uses Opal (which implements 
CoreGraphics, and is another prerequisite for UIKit), and patches to that would 
be very welcome.  CoreGraphics, Skia, and Cairo all implement the PostScript 
display model, with slightly different names, so an alternative Opal 
implementation that uses Skia instead of Cairo would be interesting.

We discussed at Cambridge and more or less agreed on using CoreGraphics / Opal 
as the interface to the rendering back end.  We'd then use Opal on all 
platforms for drawing (the xlib and art back ends have been deprecated for 
years and need to die) and have the per-platform back ends just be responsible 
for creating the drawing contexts (possibly even just for creating OpenGL [ES] 
contexts) and handling input events.  

If you're interested in working on any of this then Fred, Eric, or Ivan can 
give you more detailed suggestions.

David



--
This email complies with ISO 3103