Re: GNUstep QuartzCore demo video

[Ivan Vučica]

Hi David,

On 7. 9. 2012., at 09:59, David Chisnall <theraven@sucs.org> wrote:

> Wow!  That is VERY shiny.  

Thanks!

> Looking forward to the improvements.  Perhaps Gregory can give us an update 
> on his work to integrate Opal with GNUstep-back - it would be great to be 
> able to use this from AppKit...

I have a few thoughts on integrating with NSView even without Opal. Since 
CALayers (when notified) update their content by uploading CGBitmapContext's 
data into an OpenGL texture, it would not be too hard to have the NSView notify 
CALayer that it has updated its contents, and have the CALayer pull the data 
back.

This is not to say that having AppKit render through Opal would be unnecessary 
-- in fact, it'd solve a big downside of the proposed solution: inability to 
mix Core Graphics drawing calls with AppKit drawing calls.

The addon to AppKit I talk about could add almost everything it needs as a 
category on NSView, except a single ivar (perhaps avoidable via a global 
NSMutableDictionary which would map a pointer to NSView to a pointer to 
CALayer.). When -setWantsLayer: is called with YES, I'd simply create an 
NSOpenGLContext attached to the view that wants a layer, create a CARenderer, 
and paint things into it. If parent view is already layer-backed, then, 
naturally, OpenGL context and CARenderer are not created; instead the layer is 
simply added into the layer hierarchy.

> Have you done any profiling yet?

Not yet. Functionality was more important than optimization :-)

>  It looks fast enough in the video, but is there any extra load on the CPU 
> side that we can improve?  For example, if we JIT compiled the interpolation 
> functions for the animations, would that actually speed things up or are they 
> such a small part of total CPU cost that it's not worth it?  (I've wondered 
> this about Apple's implementation for a while)

Currently, there are far more pressing matters. Instead of monitoring 
offscreen-rasterized layer and its sublayers for changes, layers are uploaded 
to textures each frame. Even worse, framebuffers are not reused and are instead 
recreated every frame (including their backing textures). This is terribly, 
terribly wasteful. Framebuffers can easily be cached, but monitoring for 
important changes is a bit more difficult.

So currently, big slowdowns are caused by terrible misuse of GPU, and not by 
CPU.

Of course, slowdowns I talk about occur only if you use shadows or explicitly 
force offscreen rasterization. If shadows are not used, or are used on only a 
small number of layers, then there is no significant FPS drop. Good enough for 
many uses, but could (and needs) to be improved!

--
Ivan Vučica
ivan@vucica.net - http://ivan.vucica.net/