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
