[SDL] Newbie question.

Ajit Kamat groups.lists at gmail.com
Sun Jan 23 12:48:16 PST 2005

On Fri, 2005-01-07 at 09:33 -0600, Steve Smith wrote:
> On Fri, 7 Jan 2005 13:59:33 +0100, Johannes Schmidt <sdl at myrealbox.com> wrote:
> > Huh?
> > Sorry, I have to ask:
> > Are you really sure that it is glClear that takes this long?
> > glClear just fills the buffers with 0's or the given clear color.
> > 
> > Every software renderer does a better job on this.
> I suspected it should as well, but I don't know how else to explain
> it.  I don't have the code right in front of me, but it looks
> something like this:
> CStopWatch clearWatch;
> clearWatch.reset();
> clearWatch.start();
> COutput::Clear();    // this function just calls glClear() with color
> and depth bits
> clearWatch.stop();
> printf("display cleared in %d ms\n", clearWatch.getTime());
> And when I look in stdout.txt after running this from my P2 550
> running Win98, I see a bunch of lines that look like this:
> display cleared in 278 ms
> display cleared in 266 ms
> etc. etc.
> It might be completely far-fetched, but is it possible that because
> I'm double buffering, all of my rendering calls are just being cached
> instead of actually executed, and the rendering itself isn't happening
> until the next frame is being cleared?

That could happen. Through in a call to glFinish before, and after,the
call to glClear. That should isolate that one call for timing. Also, it
is much more accurate to get the cumulative time over several hundred
calls and then do the division to get the rate than to try to measure
each individual action. I don't know the precision of the timer you are
using, I doubt it is the source of the problem right now, it may be a
problem after you put in fglFinish. 

		Bob Pendleton

> I hope that makes sense to somebody other than me, and I hope I'm way
> wrong, heh.
> Thanks all for your help,
> Steve
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl

More information about the SDL mailing list