[GLTeapot] uses 100% cpu

[diver]

GLTeapot (thread name: Simon) uses 100% cpu. Tested with hrev18522 under vmware.

[fekdahl@…]

I guess that is expected to happen since it constantly redraws the BGLView with the software renderer (which currently just prints a text string iirc). CPU usage would drop if you used a hardware renderer and the CPU is no longer the bottleneck. So, I'd say this is not a bug.

/Fredrik Ekdahl

[diver]

Well, i IMHO this just shouldn't be like this, i don't think that any app in main distro should create a feeling of slow os, should it?

[ekdahl]

If you get the feeling that it's slowing down the rest of the os, then the solution is probably to lower the thread priority for the thread simon.

[korli]

Is it still valid ?

[diver]

Well i think it was fixed with mesa_soft addition, but i guess if you remove it the bug shows up again.

[ekdahl]

Well i think it was fixed with mesa_soft addition, but i guess if you remove it the bug shows up again. Do you mean its not using 100% now? Sounds very strange.

I think it's still valid. But I don't think it's a bug. It's a benchmark that tries to render the teapot with as many updates per second as possible, and when using the software renderer, the cpu gets to do all the work, so of course the cpu usage is high. That is supposed to happen. But if that slows down using the ui, the render thread has too high priority.

[axeld]

The thread priorities of all windows and menu trackers/popups were too low, the rendering thread itself should be fine at B_NORMAL_PRIORITY (could be further reduced, but the UI should stay responsive in this case, as on BeOS). Fixed in hrev18821.

[jackburton]

Axel, could this have fixed also bug #484 ?

[jackburton]

Replying to axeld:

The thread priorities of all windows and menu trackers/popups were too low, the rendering thread itself should be fine at B_NORMAL_PRIORITY (could be further reduced, but the UI should stay responsive in this case, as on BeOS). Fixed in hrev18821.

Axel, when I launch GLTeapot, the deskbar (and menus in general) still becomes really slow and unresponsive. Note that I can lower the "simon" thread priority to low, and still the system is unresponsive and the cpu occupation is 100%. This shouldn't happen, should it ? Menu tracking threads use B_DISPLAY_PRIORITY now. Only if I lower the thread priority to "idle" menus become responsive again. Of course, our menus tracking could be improved, at least :), but still I feel there's something wrong.

[jackburton]

Replying to jackburton:

Oh, another thing I noticed: The BWindow threads priority is now B_DISPLAY_PRIORITY (your change), but the ServerWindow threads priority in app_server is B_NORMAL_PRIORITY. Does this make sense or you just forgot to make the change in there ?

[axeld]

Thanks! That was really a stupid oversight - it's fixed in hrev19398.