Hello Robert The reason I am asking is I am trying to understand the performance implication of rendering in retained mode versus sending calls directly to opengl. I understand that batching opengl call for later gives the oportunity to optimize the rendering by grouping draw calls that share the same textures or the same materials (to avoid too many state changes). However, when there is a lot of rendering to process, would it be best to pass the draw calls and state changes directly to opengl? I have used cogl_flush() in many situations to explicitly force the rendering. This way I can do some direct opengl calls and restore the states that I have changed before given the control back to Clutter/COGL. I thought about implementing the functions that I require in COGL but I am afraid this comes down to reimplementing many opengl calls and states in a retained mode fashion.
That is why I wonder if the option of having an immediate mode can improve performance and also avoid the buffering of opengl calls and states (which requires some internal management and data structures). Cheers John On Mon, Nov 23, 2009 at 10:25 AM, Robert Bragg <[email protected]> wrote: > Excerpts from john delahey's message of Wed Nov 18 04:49:46 +0000 2009: > > >Hello > > > >When using the OpenGL backup, can Clutter render in immediate mode? That > is, > >send all Opengl command to the GPU instead of backing them with COGL. Are > >there fundamental reasons why this can't be done? > > Hi John, > > We could potentially consider adding API to disable the Cogl journal > which batches a lot of draw calls, or we could make the journal > pluggable potentially. Aside from GL draw calls though there are lots of > other GL calls which we defer. E.g. glEnable calls or glBindXYZ calls > tend to get deferred until the last moment so we avoid redundant state > changes. > > Can you be more specific about the problem you are facing? For example > there are the cogl_flush() and cogl_begin_gl/cogl_end_gl APIs that > may be of some help. > > Since I'm assuming you're asking this because you're trying to break out > into raw GL, I'll note one thing that we can't support and that is > interleaving of Cogl and GL calls done in such a way that you are trying > to affect the behaviour of Cogl via manual GL calls. We can only support > interleaved OpenGL calls that diligently save and restore the GL state > that they change, before returning to Cogl calls, and even then it's a > risky business and we'd much rather see proposals to improve the Cogl > API if possible. > > kind regards, > - Robert > > -- > Robert Bragg, Intel Open Source Technology Center > -- > To unsubscribe send a mail to > [email protected]<clutter%[email protected]> > >
