(figured to keep the list cc-ed)
On Mon, 2008-05-12 at 11:47 +0100, Tommi Komulainen wrote:
> > 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.
>
> What I mean is that why doesn't the wrapper do it, something like:
>
> wrapper->impl = backend->create_stage()
> wrapper->impl->realize();
> if (!REALIZED(wrapper->impl)) { ... }
>
> Isn't it the wrapper doing the calls into the backend in the first
> place? So it could easily just do two calls instead of one and not
> start overlapping the semantics in the API.
I revisited the code this morning, and by double checking some of the
assumption, I was able to avoid a lot of stuff. now the default stage is
realized in clutter_init() and clutter_init_with_args() - because we
need it to be present before the initialization sequence terminates -
while the other stages are realized when clutter_actor_show() is called
with them.
> > 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.
>
> Err, so what exactly is ClutterBackend::ensure_context supposed to do then?
it ensures that the GL context is attached to the native window held by
the stage implementation.
> It's the stage parameter that I find misleading at the moment. To me
> it implies each stage has its own context (NSOpenGLContext:makeCurrent
> is separate from :setView, associating a view/window with the context)
> -- in GLX you need both it seems.
in GLX you create the GLX context and the call glXMakeCurrent() on it
with the X drawable you want to make current.
ensure_context() allows the backend to make the stage as the current
drawable for the GL context the backend is keeping.
> I think it would be more clear if backend API had a separate
> create_context() method and ensure_context(stage, context)
what might be clearer would be creating the GL context when creating the
backend; I don't know whether this is entirely feasible.
> > 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.
>
> I mean something along the lines:
>
> clutter_stage_realize()
> {
> SET_FLAGS(self, REALIZED); /* optimistic, needed for ensure_context etc. */
> backend->realize();
> if (!REALIZED(backend))
> UNSET_FLAGS(self, REALIZED); /* magic! back in sync with backend */
> self->ensure_context(); /* and not overlapping APIs */
> }
yeah, that would work. :-)
>
> > 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.
>
> Umm, has that ever been legal? What strikes me as odd is that as you
> said upper layers are enforcing consistent state transitions, but
> backends / implementations can't rely on it. Why bother? Makes a bad
> API contract IMO.
the implementations can rely on it, if the layers above are behaving
properly; even though I'd like to keep the backends safe even in case of
misuse.
> > > > - 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.
>
> So we're creating the context on realize and never destroying it?
obviously not: the GL context is destroyed with the backend.
> This makes no sense if you assume multiple GL contexts. It would be
> far more clear if you explicitly state there's support only for single
> context, and that it needs to be created during backend init. Perhaps
> even add an explicit create_context() method on the backend API and
> then clutter core could manage the contexts whichever way it chooses
> (ensure_context(stage, context))
the multiple GL contexts is a path we tried and did not work. yes: we
should be more explicit about the "single GL contexts" guideline, but I
always thought that multiple GL context are evil anyway and the "one
context per process" was already a guideline for GL-based applications.
> > 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.
>
> Don't we have the wrapper calling ensure context at proper times already?
no, we do it in the stage implementation because it is easier. :-)
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]
