<div>Hi Zack,</div> <div> </div> <div>> For example your code isn't measuing the time needed to render a frame but to<br>> retrace a set of calls. The difference being that your measurments will be<br>> skewed by both the time needed to parse and decompress the trace file and the<br> > asynchronous nature of the underlaying graphics api.</div> <div> </div> <div>I accept. I made a wrong assumption that glXSwapBuffers() blocks until all previous gl calls</div> <div> finish execution. But actually It just flushes all the commands to gpu command buffer and returns immediately.</div> <div> </div> <div>> In other words it isn't reliable, in particular because snappy will decompress in chunks so the long<br>> frame that you might be seeing might not be related to rendering at all but be<br>> caused by decompression kicking in for the given set of calls. It just<br> > requires a bit more thought and probably a careful usage of gpu timer queries<br>> to separate the cpu time from the gpu time.</div> <div> </div> <div>Yes, we have to use gpu timer queries to get more meaningful rendering timings.</div> <div> </div> <div>Thanks</div> <div>Anuj</div>