Re: Determinate progress bar

[Ivan Vučica]

All of what David said -- and it gets more fun as, under OS X, some (most?) layers may actually get sent over to WindowServer for rendering.

I remember running into that factoid somewhere while researching CA, but I didn't bother confirming. So take that with a grain of salt.

Also, to add, as far as I understand, NSViews don't have a CALayer unless they have wantsLayer set, or are children of a view that wantsLayer. But I would not be surprised to find out that, if a view is animated in a way that would make having CALayer simplify things, the view suddenly gets a CALayer no matter if the app has set wantsLayer to YES or not.

sent from phone

On Sat, Nov 22, 2014, 18:40 David Chisnall <theraven@sucs.org> wrote:

On 22 Nov 2014, at 00:37, Ivan Vučica <ivan@vucica.net> wrote:

> I'd guess that under OS X this is done with Core Animation, as many animations don't stop even if the UI thread is blocked. But -- we don't have that, so ...

CoreAnimation is part of the story, multithreaded rendering is another.  On OS X, each view (or, at least, most views) have a CA layer attached and so can independently render into that layer.  A renderer thread can composite the result.  Views marked as not supporting threaded drawing are all rendered in the same thread (typically because they interact with controllers that are not thread-safe), but this isn't necessarily the same thread as the thread that composites all of the results together.

We can't do that with the current drawing model in GNUstep, because every view renders directly into the target window.

David

-- Sent from my STANTEC-ZEBRA