On Sat, 2008-05-10 at 23:15 +0100, Tommi Komulainen wrote: > Some more details below: > > > ClutterBackend::create_stage > > -- This function is used to create the stage implementation. It will > > receive as an argument the ClutterStage instance that is "wrapping" > > the actual implementation being created. The backend must create > > its stage implementation and call _clutter_stage_set_window() with > > the wrapper and the stage implementation instance: > > > > _clutter_stage_set_window (wrapper, CLUTTER_STAGE_WINDOW (impl)); > > > > The backend must also call clutter_actor_realize() on the stage > > implementation, > > Err, why the backend? Also as realize is expected to set the new stage > current, isn't this making a mess of any context management?
it has to do with the default stage and the fact that we need a GL context ready during the init sequence to be able to query the features. I tried delaying the realization and require it for the default stage only, but it seems to be breaking. > > > and then check if the stage has been realized, using > > the CLUTTER_ACTOR_IS_REALIZED() macro; if the stage was not > > realized, it must return NULL and set the passed GError. > > Again, why in the backend? because we need to report back to clutter_init() that the default stage failed to be initialized. > Might be worth noting that this leaves the > wrapper in inconsistent state as a result of previous call to > _clutter_stage_set_window() -- the stage should've been destroyed by > now (since, well, create failed) true; I'll update the other backends. > > Inside the ::realize function the stage implementation should: > > - create the drawing context (either GL or GLES) and assign it > > to the backend, if it's not already present > > What does 'assigning to backend' mean? That you can only have single GL > context? yes. in theory it would be possible, through accurate locking and by migrating caches, to have multiple contexts in the same process - but this is non advisable. > > > - set the CLUTTER_ACTOR_REALIZED flag on *both* the wrapper and the > > stage implementation > > - call clutter_stage_ensure_current() with the wrapper instance > > Why in the backend? Especially manipulating the wrapper state feels > bordering silly. IMO the wrapper should forward all relevant state > change from the wrapper to implementation (documentation suggests this > is the case) but also mirror the resulting state from implementation > back to the wrapper. flags cannot be "forwarded"; the only reason to set the realized state on the stage wrapper from within the stage implementation is that the stage implementation will then have to call clutter_stage_ensure_context() with the stage wrapper as the argument; the ensure_context() call checks whether the stage wrapper is realized to control the context assignment. > Just to note, the consequence of not setting REALIZED on the wrapper > resulted in realize+realize call sequence into the backend, no > unrealize in between. This raises a question, which of the following > is correct: > > 1) > realize(): g_assert(!REALIZED) > show(): g_assert(!MAPPED) > hide(): g_assert(MAPPED) > unrealize(): g_assert(REALIZED) > > 2) > realize(): if(REALIZED) return; > show(): if (MAPPED) return; > hide(): if (!MAPPED) return; > unrealized(): if (!REALIZED) return; showing and hiding might be called multiple times, so an assertion would be quire useless. so: 3) realize(): g_assert (!REALIZED) show(): if (MAPPED) return; hide(): if (!MAPPED) return; unrealized(): g_assert (REALIZED) the layers above should keep consistency anyway, but they don't protect from direct calling of the vfuncs. > Also, need / expectation to chain up to parent is rather vague. if you're subclassing from straight ClutterActor, and if you set the flags yourself, you shouldn't need to chain up. > > Inside the ::unrealize function the stage implementation should: > > > > - unset the CLUTTER_ACTOR_REALIZED flag > > But not on the wrapper? What about chaining up to parent? Would it do that? yes. > > - call _clutter_shader_release_all() if the backend supports shaders > > and the GL programmable pipeline > > Is there some call ordering constraint requiring this to be done in > the backend rather than in the core / wrapper? this is mostly a fluke - I was reading the GLX backend code. the shaders should be released before destroying the GL context, though. > > > - destroy the native window handle > > - call clutter_stage_ensure_context() with the wrapper instance > > Err, why? Didn't we just destroy the underlying resources, including GL > context? no, the GL context should still be alive when a stage is destroyed. the ensure context will make sure that the backend knows that the GL context should be unassigned. it's part of the clean up process. ciao, Emmanuele. -- Emmanuele Bassi, OpenedHand Ltd. Unit R, Homesdale Business Centre 216-218 Homesdale Rd., Bromley - BR12QZ http://www.o-hand.com -- To unsubscribe send a mail to [EMAIL PROTECTED]
