discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Painting gnustep-gui into OpenGL


From: David Chisnall
Subject: Re: Painting gnustep-gui into OpenGL
Date: Wed, 27 Apr 2011 16:09:09 +0100

On 27 Apr 2011, at 15:54, Ivan Vučica wrote:

> On Wed, Apr 27, 2011 at 11:08, David Chisnall <theraven@sucs.org> wrote:
> 
>> > Can I paint windows that way too? What backend should I use to prevent 
>> > them from actually appearing on the screen?
> 
> Probably, if you use the view class that GNUstep uses when not using a window 
> manager.
> 
> What view class is that? How do I tell a window to use it? 
> 
> I am not very familiar with inner workings of GNUstep yet. :-)

I'm not sure - I always use GNUstep with a window manager.

>>  The simplest thing to do is create the views in a window that you don't 
>> draw,
>> 
>> I suppose by creating a window and not making it visible?
>>  
>> then call the draw method on the root view in your hierarchy after locking 
>> focus on the destination NSImage.
> 
> Do you have some sample code? Just rendering, for example, a view with a 
> button into an NSImage would already be more than enough to get me started.

There's some sample code for this in my Cocoa Programming book I think - the 
examples can be downloaded from the book's page.

>> This should all be back-end independent (should work on OS X too - I think 
>> there is an example on CocoaDev for rendering a view hierarchy to a texture, 
>> but I may have imagined it).
> 
> Are you referring to this page?
> http://www.cocoadev.com/index.pl?GettingViewContentAsImage
> It appears to use this:
> [view cacheDisplayInRect:[view bounds] toBitmapImageRep:imageRep];

No, that looks a bit wrong.  

>> Don't forget that you'll also be responsible for handling the redraws too.
>> 
> For a game, this is typically a non-issue since UI is rendered each frame. 
> For optimization purposes, redraw could be triggered on an input event.
>  
> 
>> If you're interested in working on this, then some of the code would 
>> actually be helpful for implementing CoreAnimation.  We have the ability 
>> with Opal to draw into layers (off-screen textures), but we're still doing 
>> the compositing with Cairo.  It might be better to use OpenGL for the 
>> compositing of layers, so we can move them around and do things like the 
>> CoreImage effects with some OpenGL shaders.
> 
> Maybe! I was rather looking for something that paints into framebuffer 
> (without X11) that I could easily reuse to paint in-game, but maybe things 
> could easily be patched to render views into textures.

That's what NSImage lockFocus is for.  Call this, and the drawing target 
becomes that NSImage instance.  Then you can just get the data from it.

> I am not familiar with Cairo, however, and I did not take a look at Opal, so 
> I'm not sure how much I could help.
> 
> Is there some documentation/diagrams I could take a look to quickly 
> understand what piece of the puzzle does what, apart from studying the code 
> (which may generate more questions than answers)? For example, I am somewhat 
> confused by what Opal exactly is. :-)

Opal is an implementation of CoreGraphics, which (on OS X) sits between AppKit 
and the window server.  You don't really have to understand any of that for 
CoreAnimation though - just provide a mechanism for redirecting drawing to an 
OpenGL texture and animating a rectangle that this texture is attached to.

David

-- Sent from my STANTEC-ZEBRA




reply via email to

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