[cello-devel] High CPU load also on Linux!

[Frank Goenninger]

On Wed, 2004-03-10 at 16:23, Kenny Tilton wrote:
> Frank Goenninger wrote:
> 
> >After a bit of searching on WWW I found this bit of explanation:
> >
> >(An answer to a message complaining about high cpu usage when doing
> >OpenGL stuff):
> >
> ><QUOTE>
[SNIPPED]
> >void idelCB(void) {
> >... /* Do something */ ...
> >glutPostRedisplay(); /* <= This should be the problem */
> >
> I am almost certain you will discover one of two things. Either:
> 
> (1) the window is being created with ":display-continuous t", which gets 
> handled in mg-glut-display thus:
> 
>             (when (display-continuous *w*)
>               (trc nil "mg-glut-display > posting redisplay w " *w* 
> (glutgetwindow))
>               (glut-post-redisplay))
> 
Yes, this is in the code. But I can't find any place were we create
a window with :display-continuous t !

> or (2), that the ix-render method for the window class ends with 
> (glut-post-redisplay).

No. It doesn't.

> 
> If so, the high cpu load is intentional (by me). The problem (on win32) 
> becomes apparent when any such forced redisplay gets disabled. then the 
> shapes stop spinning,eg, so you know the application-forced redisplays 
> have stopped. At this point win32 still shows 100% cpu used by Freeglut, 
> because of the rush job I found out about yesterday. Apparently I can 
> get the fix by updating from the latest cvs on freeglut.
> 
Did it fix the problem on Win32 ???

> I have not noticed any discussion of the x11 side of things, so maybe 
> once you disable the redisplays your cpu load will just drop. 

It doesn't. I haven't disabled anything because I don't see superfluous
redisplay calls.

> I am 
> almost certain the patch I need to download is win32-only. so if you 
> still see a blazing high cpu load we might have a problem.
> 
Yep. I think we actually have one. A beast. But some ideas hereto:

You already coded an idle callback function and also get the "OS 
real time" in that function. So why not just save the realtime when
a redisplay has been posted? The next redisplay only gets posted if
there is a certain difference between the last posting and the current
one!

This difference should be settable such that one can tune the app
here to differing needs.

Will try that and report back.

 
Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cello-devel/attachments/20040310/800aafa9/attachment.sig>