Opened 13 years ago

Closed 13 years ago

#742 closed bug (fixed)

[GLTeapot] uses 100% cpu

Reported by: diver Owned by: axeld
Priority: normal Milestone: R1
Component: Applications Version:
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by korli)

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

Change History (11)

comment:1 by fekdahl@…, 13 years ago

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

comment:2 by diver, 13 years ago

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?

comment:3 by ekdahl, 13 years ago

Platform: All

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.

comment:4 by korli, 13 years ago

Description: modified (diff)

Is it still valid ?

comment:5 by diver, 13 years ago

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

comment:6 by ekdahl, 13 years ago

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.

comment:7 by axeld, 13 years ago

Resolution: fixed
Status: newclosed

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.

comment:8 by jackburton, 13 years ago

Axel, could this have fixed also bug #484 ?

in reply to:  7 ; comment:9 by jackburton, 13 years ago

Resolution: fixed
Status: closedreopened

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.

in reply to:  9 comment:10 by jackburton, 13 years ago

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 ?

comment:11 by axeld, 13 years ago

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.