On Thu, Jan 26, 2012 at 00:22, Eric Wasylishen
<address@hidden> wrote:
I got opal and the examples to run on Jan 2 - try r34396. When I was working on it the dependencies listed in README were accurate; now Amr has added a dependency on corebase.
Updating opal to r34396 did not help. More carefully reading the errors, I figured out the problem might actually be in corebase.
And so it was! CFStream.h was added to corebase, included from CoreFoundation.h, but never actually listed in GNUmakefile. This resulted in it never being installed. So I dug in and added it to "
common.mk" in corebase. Hope noone minds me committing it, since this got opal to compile as well.
I'm not sure what Amr is planning to do with opal. I don't have a plan for it either, but I would like to see gnustep-gui use it.
Ditto. But I'd love it if it didn't become AppKit-dependent. GSDisplayServer, GNUstepGUI and hence gnustep-back don't seem to be easily usable without the entirety of gnustep-gui, which is a shame since all of this could and should be reused in UIKit. When I catch some time, I'll explore what can be done.
On Thu, Jan 26, 2012 at 12:24, David Chisnall
<address@hidden> wrote:
Absolutely. Opal is intended to sit in the same place CoreGraphics does in Cocoa: below AppKit (or UIKit).
The short-term aim (which has been a short-term aim for about two years) is for -back to be modified to just handle event handling and window management and delegate the handling of drawing to Opal.
If someone finally digs in and refactors -back, I'd love if it could -- along with GSDisplayServer -- be made as -gui-independent as possible.
With regard to CoreAnimation, Banlu has some demos of rendering GNUstep AppKit views to OpenGL textures and then compositing and animating them.
I presume using [NSImage lockFocus]?
While it should be possible to get basic CoreAnimation stuff working without OpenGL (Opal already has CGLayer), I'm not convinced that it's sensible: Apple's CoreAnimation also uses CoreImage a lot, and CoreImage allows you to run OpenCL programs on the images - this is pretty trivial to implement for an OpenGL texture, but requires a bit effort for a Cairo pattern (you need to copy it - probably back from the display server - copy it to the GPU, run the program, and then do the whole thing in reverse).
I agree. Since I need it to work on UIKit, I planned to implement CoreAnimation. I was going to make a "renderer" class which would establish an OpenGL context and contain a layer that one can render into. This is basically what Apple does on OS X with its CARenderer class and should be relatively simple to implement.
In fact, I think this'll be the next thing I'll work on: just getting basic compositing of CGImageRefs to work using a CARenderer, with CARenderer using a pre-created OpenGL context (probably created with NSOpenGLView since we don't use CGL).