Hi David, On 7. 9. 2012., at 09:59, David Chisnall <[email protected]> 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 [email protected] - http://ivan.vucica.net/ _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
