Excessive Processor Use for a text-interface?

[AnonymousHero]

It shouldn't be using 100% CPU (busy-waiting), regardless of whether your X11 client is local or remote. It might be *slow* to use a remote X11 client, but if the X11 client and server are on the same LAN it also shouldn't be that noticable... and certainly should result in 100% CPU usage.

[SaThaRiel]

Locally i havent seen a cpu load of 100% - neither with the local install (SVN version) nor with the Ubuntu version with X11-forwarding.
When i tested short on the Ubuntu machine, the load was high when using maximized window. So i guess i can reproduce the problem - even if its in an VM.

[pav]

Note that it's not Angband but the window manager what is spinning. I used to have this too. I am not an expert but I suppose the window manager is not happy with the angband refusing to resize to whatever the WM is throwing at it. Because Angband cannot fill any pixelcount but it needs a multiple of tile/font size. That is what I would start poking at first...

[ekolis]

Couldn't Angband be modified to ignore any "extra" pixels beyond a multiple of tilesize?

[SaThaRiel]

Hm, can't reproduce the problem with VBox - i think that my resolution is to small (800x600 - only have a netbook). Xorg is running a bit wild but that pulseaudio crap is worse. I will try to get rid of pulseaudio and trace Xorg then. Angband itself is throwing more or less the same EGAIN messages like before.
I think that pav maybe right - it really sounds like a pixel-resolution problem, if you resize the window you will always have a multiple of tile-size. But i hadn't such a problem with openbox (1920x1200 resolution) and not here with dwm (1024x576) - but i configured dwm at least to ignore the font size and always display terminals in full size.
Someone might test Ubuntu 8.10 or something with Angband 3.1.1-1626. Maybe it has something to do with the whole clicky-like-apple behaviour :?

[AnonymousHero]

Note that it's not Angband but the window manager what is spinning.

Is it? I just saw 100% CPU usage mentioned, but I didn't notice any mention of which process it was that was actually using 100% CPU, so I assumed it was the Angband process.

SaThaRiel, can you confirm which process is it? ('top' or 'htop' will tell you).

I used to have this too. I am not an expert but I suppose the window manager is not happy with the angband refusing to resize to whatever the WM is throwing at it. Because Angband cannot fill any pixelcount but it needs a multiple of tile/font size. That is what I would start poking at first...

Sound like a reasonable theory; that it's a "battle of resizing".

As a first approximation you could try to just comment out the section

                        if ((Infowin->w != wid) || (Infowin->h != hgt))
                        {
                                /* Resize window */
                                Infowin_set(td->win);
                                Infowin_resize(wid, hgt);
                        }

around line 1923 of main-x11.c just to see what happens. I think it might lead to a crash, but you never know -- maybe X automatically clips "painting" to the apps area automatically.

[Nick]

I've tested this - I'm getting 40% from Xorg, 40% from wnck-applet and 20% from metacity. That's on a 2560x1440 screen.

[AnonymousHero]

Yeah, I think I may actually be seeing it too here after a little testing... but only while the resize actually happens.

My window manager (kwin) seems to somehow "converge" towards the size which the angband window wants to be after a few iterations of "fighting" with the client. That is: when I maximize the window, it starts by maximizing, but angband resizes itself down, then tries to maximize again, angband resizes itself down, etc. etc. Roughly a second of this and suddenly the angband window is the size it "wants to be" (not fully maximized).

I'll see if I can find an easy fix today.

EDIT: It should be easy enough even if the above suggestion (disabling the auto-resize) doesn't work. All that should be required is to resize the virtual terminal *down* if the requested dimensions aren't exact multiples of the window size requested by the X server. That would mean a black border on the right/bottom (in this particular case), but it's preferable to the current behavior.

[Nick]

Right - looks like kwin might deal with it a bit better than metacity.

[AnonymousHero]

Could someone please try the attached patch? It seems to do the trick for me.

[Magnate]

Could someone please try the attached patch? It seems to do the trick for me.

Good work - committed as r2009. This has been outstanding for a *long* time - many thanks for the fix.

[chris]

Could someone please try the attached patch? It seems to do the trick for me.

Thanks to everyone who looked at this

The patch works like a charm!