[Cogl] [PATCH 3/3] Add CoglFrameTimings

[Neil Roberts]

Hi,

I'm not sure whether it would make sense to make the ‘frame time’ a
property of a framebuffer.

As far as I understand, the frame time that gets passed to
cogl_onscreen_begin_frame() is a kind of relative time that is used to
determine what should be painted. I guess when an actor (or whatever) is
being painted it will need to know this time so that for example it will
know how far to progress an animation before painting. I'm assuming the
idea is that the framebuffer would be used as a central location to
store this common bit of information.

However this probably doesn't make a lot of sense because a single frame
can make use of multiple framebuffers. For example, in Clutter an actor
can be redirected to an offscreen buffer. If the actor's paint method
tries to look at the framebuffer it is painting to in order to get the
frame time, it will end up getting the frame time of the offscreen
buffer. I don't think it really makes sense to have a frame time on an
offscreen buffer because there is no set lifetime for its contents.

I would imagine it would work that the toolkit would begin rendering a
frame at some point, decide the frame time and immediately get the frame
timings object. It would then cause all of the actors to paint to
whatever framebuffer and it would explicitly pass this frame timing
object to the actors, perhaps as part of a paint context or as a
property of the stage. That way the actors don't need to guess which
framebuffer their contents relates to.

I think that is pretty much what Owen was originally suggesting.

For Cogl 2.0 where we can change the API, I think it could be quite nice
to conflate the swap buffer complete and frame timings callbacks into
one. Then it would be more like a single callback to report that the
current frame has progressed to another point and maybe some more of the
information is available. Then we could have an enum property to report
what the current state of the frame is. It seems quite likely that we
would eventually add more states for the frame and having separate
callbacks for all of them doesn't seem very convenient.

I'm not totally sold on the idea of Cogl itself maintaining the history
of timing objects. If Cogl is not consuming the information, then the
size of the buffer it chooses seems arbitrary. As the objects are
ref-counted, it seems like it would be simple for a toolkit to keep as
many of the objects as it wants and manage them itself.

- Neil
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.