discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Determinate progress bar


From: Ivan Vučica
Subject: Re: Determinate progress bar
Date: Sun, 23 Nov 2014 16:16:27 +0000

On Sun, Nov 23, 2014 at 3:44 AM, Gregory Casamento <greg.casamento@gmail.com> wrote:
Ivan,

So does it make sense for us to change our rendering model so that it incorporates CoreAnimation? 

It makes sense to incorporate it in the first place, I just don't think too many changes are needed.

In fact, if the Opal backend in -back ends up being fast enough and stable enough, I suspect most of CA-related changes to views can be implemented in a category of NSView.

That is because the biggest benefit is compositing in another thread. All of this means most of the work is in finishing, fixing and reworking CA, and less in reworking -gui. I'd have to get back into CA to be able to be more specific, but I think the needed changes to -gui involve adding an extra instance variable (or variables) for CA to keep its layer and other data in, while a change to -base may be needed to better integrate into the NSRunLoop. (I recall that under OS X this is done through registering something into a CFRunLoop, but I can't remember what exactly.) 

In CA itself, we need to 1. redraw frame only if an animation is running or when a property changes (more detailed TODO available somewhere in mailing list archives), 2. ensure thread safety, 3. work on the aforementioned NSView category which would create an OpenGL context when wantsLayer=YES, create layers for itself and its child views, start render thread if needed, tell the render thread to composite layers into this context. 
--
Ivan Vučica
ivan@vucica.net

reply via email to

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