Thank you for the very detailed response. In my original question, I was
setting an offscreen buffer (the same size as the window) just to derive
the rendering from the main frame buffer to and an offscreen texture.
That is, I expected my texture to be just like what would have appeared
on screen. But setting an offscreen buffer changes the the modelview and
projection matrices as you explained!

Jay


Robert Bragg wrote:
> Excerpts from Jay Taoko's message of Wed Sep 16 21:08:03 +0100 2009:
>   
>> Hello
>>
>> I am doing some rendering within the paint callback of an actor. I set
>> an offscreen render target created with cogl_offscreen_new_to_texture,
>> draw the actor and set back the window target with
>> cogl_set_draw_buffer(COGL_WINDOW_BUFFER, 0).
>> I can see my actor in the offscreen render target, but it looks like it
>> is clipped or the projection is not correct. When that actor is facing
>> the screen, it looks right. When it is rotated around the Y axis it does
>> not look right. I am using only COGL calls. When the offscreen render
>> target is removed, everything draws correctly again.
>>
>> Is something drastic changing when an offscreen buffer is set as render
>> target?
>>     
>
> Sadly the current cogl-fbo support is rather primitive and not really well
> designed. It's just about enough to support the
> clutter_texture_new_from_actor () API, but you may have difficulty using
> it manually.
>
> Here are some notes that may help you deal with it though:
>
> - When you set an offscreen draw buffer then Cogl will load an identity
>   modelview and projection matrix and set the viewport to the size of
>   the buffer.
> - The identity matrices give you a coordinate space like OpenGL's
>   default, with -1 and 1 mapping to the extents of the viewport.
> - For clutter_texture_new_from_actor () Clutter is currently using some
>   internal only API to setup a modelview matrix as if the draw buffer
>   were the same size as the stage, and with (0,0) top left.
>   - It's not ideal but you should be able to copy this code from
>     _cogl_setup_viewport into your application for now.
>   - For more details you should look at cogl_texture_paint and look at
>     the block of code under if (priv->fbo_handle != COGL_INVALID_HANDLE)
> - ClutterTexture is also using some internal API to tweak the projection
>   so the source actor looks like it would at its original stage
>   location.  (If you also desire the same kind of behaviour you could
>   look at clutter_texture_set_fbo_projection())
> - The cogl-fbo API will save and restore the modelview and projection
>   matrix and viewport when switching to/from the onscreen draw buffer,
>   but wont do that for offscreen buffers.
>
> Generally speaking we haven't used offscreen draw buffers much ourselves
> yet so they haven't had much testing. For instance Neil Roberts opened
> this bug the other day: http://bugzilla.o-hand.com/show_bug.cgi?id=1809
> just something to be aware of if you also start playing with Clipping.
>
> If after looking through the above notes you think you have found a bug,
> I'd be interested in any small unit test you may have that demonstrates
> a problem.
>
> How we can hopefully improve things:
> - At some point I think the code in _cogl_setup_viewport should be
>   migrated up to Clutter and exposed publicly.
> - clutter_texture_set_fbo_projection could be made public too - possibly
>   with a rename.
> - I think it would be better to remove all mucking about with the
>   modelview/projection/viewport when setting a draw buffer. None of
>   it's documented, and it seems non-orthogonal.
>
> You may also be interested in this bug discussing the need to rework how
> Clutter exposes fbos:
> http://bugzilla.o-hand.com/show_bug.cgi?id=1573
>
> Also as part of my general effort to have Cogl eventually be a
> standalone library an important part of that is the core API used to
> manage framebuffers.  (window system framebuffers and
> framebuffer_objects) So although the clutter/cogl fbo APIs aren't great
> a.t.m we are working to hopefully improve things.
>
> kind regards,
> - Robert
>   

Reply via email to