Re: [clutter] Offscreen Clutter Stage

[Bob Murphy]

Hi Robert,

Thanks for your reply! I figured people were probably on holiday, but  
that's when I've had to work on this. :-)

What I've got so far is a new API, clutter_stage_new_offscreen(), that  
sets an "offscreen stage" property in the stage. Once the stage is  
realized, the offscreen-vs-onscreen status is locked. So conceivably  
you could  do a clutter_stage_new() and set the property later, as  
long as it's before the stage is realized. There's also an API for  
copying from that stage into an X Pixmap.

All my other work so far is in the X11 and GLX backends. GLX sets a  
new capabilities flag advertising you can do this. And the code is in  
place so that rendering is redirected to an FBO attached to a texture.

I'm running into problems due to my lack of OpenGL experience, but am  
gradually getting past those. (If you'd be amenable to providing  
advice, I'd be deeply, deeply grateful.) In particular, there's some  
kind of state problem preventing the texture from actually drawing the  
way I expect.

I hope this approach is not at odds with what people were planning to  
do otherwise. But we need these capabilities in the next few weeks, so  
I had to do something. :-)

Right now, we're focused on GLX and EGLX because those are our initial  
target platforms. We will eventually need to support Windows and Mac  
OS X as well, but that's down the road.

Thanks,
Bob

On Jan 5, 2010, at 7:49 AM, Robert Bragg wrote:

Hi Bob,

You picked a time when everyone was on holiday so sorry you didn't  
get a
reply sooner.

A while back we did have some primitive offscreen stage support in the
backends, which only the GLX backend tried to implement via PBuffers.
This was removed though because it was a messy solution, and at the
moment we are trying to reduce the complexity of clutter backends so  
we
can start figuring out how we can migrate bits down into Cogl.

The current plan for supporting offscreen stages in a more portable  
way
(the same code for GLX/EGL/WGL etc) is to use framebuffer objects
instead of window system specific features such as PBuffers. For  
sharing
these between processes we would aim to use GEM/TTM handles  
eventually.

Cogl's offscreen rendering support recently had a first pass overhaul
giving us a CoglFramebuffer abstract base class that is subclassed to
implement CoglOffscreen (and eventually CoglOnscreen) objects. The  
plan
is to continue extending the capabilities of these objects/ 
abstractions
and expose more ARB/EXT/OES_framebuffer_object features this way.

All Clutter stages will eventually be CoglFramebuffers, and at this
point, hopefully, Clutter won't need to care if it's a CoglOnscreen or
CoglOffscreen framebuffer.

Assuming you are only dealing with X Window stages (You only mentioned
GLX and EGLX), then for a nsapi plugin I wonder if you could redirect
the X window of a stage offscreen using the X composite extension?
You can get the stage window XID via clutter_x11_get_stage_window().

I hope that helps to some extent; though I guess a bit late.

If you are interested in the work to migrate parts of the Clutter
backends to Cogl so you can track the progress of this work I can look
at publishing the crude stabs I've made at this work so far in a  
branch
and perhaps you can provide some feedback on it.

Hopefully we will have a wiki for Clutter soon so it will be easier to
see what ideas are being thrown around for Clutter and Cogl.

kind regards.
- Robert

Excerpts from Bob Murphy's message of Mon Dec 21 05:15:04 +0000 2009:
Hi all,

I'm on a team writing a windowless npapi (browser) plug-in. Such  
plug-
ins don't let you have a window to draw into, just an offscreen  
pixbuf
that the browser blits to the main browser window.

We also need to use Clutter as an underlying technology, but we can't
offer an on-screen window for Clutter to use for a stage.

I gather the ClutterOffscreen container proposed for Bug 1573  
requires
an on-screen stage window - if so, it won't work for us.

So I'm thinking of writing a ClutterOffscreenStage. This would
subclass ClutterStage, accept normal ClutterActors as children, but
render to an offscreen pixbuffer (which can be platform-specific).

Oh, and whatever I do needs to work on GLX and EGLX in the next two
weeks. :-) Fortunately, I have full time to work on that, and lots of
good coffee available.

So I'd be very grateful for advice, reality-checks, comments,
alternatives, suggestions, etc. Anybody who helps will get a hearty
handshake and a free beer, whiskey, coffee, tea, soft drink, or other
beverage of their choice at the next FOSS conference we're both at.

Thanks,
Bob

P.S. Here are some things I'm thinking about this so far, and would
appreciate corrections and advice from people who know more than I  
do:

It seems to me that an offscreen stage is necessary to build a
completely offscreen scene graph, without any on-screen window, and
render it into an offscreen pixbuf. Is this correct? Or is there
another, simpler way to accomplish those goals?

I'd like to do this without doing any backend-specific code. But it
doesn't look like that's feasible. Is that right?

Many ClutterStage implementation details are done in the back-ends.  
So
ClutterOffscreenStage would need to do the same thing. Is that right?

Do any of the ClutterActors make assumptions, like about being on-
screen, that would cause problems if they were embedded in a
ClutterOffscreenStage?

--
Robert Bragg, Intel Open Source Technology Center
--
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com



--
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com