I'm experiencing an odd and extremely annoying screen refresh bug on my laptop. It only seems to happen (or, at least, severely enough to be noticeable) in terminal windows: if I leave irssi open in Xfce Terminal with no other activity on-screen, the clock on the status bar (which displays the current time as a hh:mm:ss timestamp) will only update itself every 2 seconds. If there is any activity anywhere else on-screen, e.g. by moving the mouse, an animated GIF displayed in Firefox or even just the flashing caret in the text box I'm using to write this message, the irssi clock updates itself at the correct speed. The problem isn't unique to irssi either; I've encountered the same delay while tab-completing file names from the shell and waiting for the status line in nano to be updated. Sometimes the delay is significantly longer than 2 seconds - I think the longest I've waited for a tab-completion to be displayed in the shell is about 5 seconds.

I'm not sure what information is necessary to debug this because I have absolutely no idea where to start, so here's everything relevant I can think of: I'm running Slackware64 13.37 with Robby's Xfce 4.8 packages, kernel 2.6.39 (I can post my .config if required), Xorg 1.9.5 with the xf86-video-intel 2.15.0 driver, and mesa 7.9.2. The chipset is a Mobile Intel GM45 Express. This problem is making my laptop almost unusable, so any help whatsoever would be appreciated!

hi, just a quick comment since i cannot re-create the problem: it sounds more like an issue related to the scheduler than the video subsystem. play with the scheduler settings -- tickless, pre-emption model, type of scheduler (CFS/BFS), scheduling priorities. Does it happen with other applications?

Good idea - I just tested this with 13.37's default (huge) 2.6.37.6 kernel, but I get the same problem. Is it still likely to be the kernel? I thought the Slackware default .config was designed to be pretty safe. I didn't have this problem when I used 13.1 with GSB 2.32 (when upgrading to 13.37 I decided to format and install from scratch to eliminate some cruft). I don't notice the problem with any other applications, but I guess that doesn't mean it's not happening - but it's definitely most noticeable with Xfce Terminal.

edit: after some further testing, I've found that the problem never happens on the console, further strengthening my belief that this is X's or the graphics driver's fault...

Confirming that the problem in fact appears to lie with Xfce Terminal - other terminal emulators (sakura, gnome-terminal) don't display this behaviour. I tried changing all available settings but nothing seemed to have an effect. Shame too, because Xfce Terminal is a nice lightweight alternative to gnome-terminal with almost the same feature set. I'll report it to the developers and hope it gets fixed in time for 4.10.

I remember this from 13.0/13.1's CHANGES_AND_HINTS.TXT:
Though I'm not sure how relevant it is in 13.37 or in Xfce 4.8 (as opposed to 4.6). If it is no longer relevant and I just wasted your time, I apologize; I haven't used Xfce in 13.37 and I don't use Robby's upgraded Xfce packages.

As T3slider has suggested a similar problem on my system solved with the following in /etc/X11/xorg.conf:

This is with xfce 4.6.2, I had hoped this would not be necessary in newer versions .

Confirming that both T3slider's and andrew.46's suggestions work - sadly, yes, it appears to be necessary in Xfce 4.8 too. The original Bugzilla report about this, linked in CHANGES_AND_HINTS.TXT, has been marked closed/invalid so I guess it'll continue to be necessary in future versions of Xfce.