Display refresh goes a-wonky

[Schmorgluck]

KildClient has been my favorite (well, only) MUD client for years, in fact from the very beginning of my playing MUDs. I picked it because I'm well-learned in Perl, which makes me feel empowered for handling aliases, macros, triggers, etc.

But now I'm frustrated, because the output area goes weird after a while. It doesn't refresh well, showing me older lines instead of the most recent ones. When I switch away from, then back again to the KildClient window, the display goes back to what it should be. Then it goes wonky again once enough lines have been sent by the MUD.

I'm not quite sure the problem comes from KildClient itself, but I'd like to know if someone else met that problem.

My system is Debian 8.2 (i686), with Cinnamon 2.2.16.

[semidec]

Seems to be the same problem I have. I even compiled version 3.0.1 (Debian offers 3.0.0) but it didn't help. I even looked at some sources, but it's so complex that I didn't find a place to force a more frequent refresh for a workaround. Maybe later I'll have time and energy.

It's a pity, because KC works in those things that I don't like in GGmud. If we (well, probably you people) can fix this, I'll change over.

I have Debian 3.16.7-ckt20-1+deb8u3 and MATE Desktop Environment 1.8.1

[ekalin]

This is likely to be a problem with some underlying library, such as GTK+, GDK, or even something of a lower level up to the X libraries, video driver, etc. KildClient doesn't deal with drawing or refreshing directly, instead it uses the widgets provided by GTK+, hoping that they simply work.

Unfortunately I don't know even where to start investigating this problem.

[Schmorgluck]

Okay, I've got something new. I removed (actually, moved) my .kildclient config directory and started afresh: the problem disappeared. So obviously it's an issue about my configuration.

I'll run some tests now and then to find out where it all comes from.

[Schmorgluck]

Actually, I was wrong, the issue didn't go away, it took longer to manifest itself. After some research, I found it reported on Debian bug report log (that, for some reason, seems to be blacklisted by the forum) under number #772096. It's an issue with GTK+, it would seem. Some workarounds are offered. I haven't tried them yet.

[Schmorgluck]

The bug report I mentioned previously was apparently about a different issue. But I have noticed something: the problem starts when the scrollback buffer is full. So for now the workaround I have is to set the number of lines to a high number, and restart KildClient now and then.

[Guilhaume]

It will up this post, but I think it is the best place to speak about my issue which seems to be the same as the original post here. I will try to solve this refreshing issue using the previous post.

Anyway, if it can help for the next update :
I use Kildclient for 1 month now, I hadn't this issue since the last 2 days. In fact I moved from Ubuntu 14.04 to Ubuntu 16.04 two days ago. That's the only change I made around Kild.

[semidec]

I made a quick and dirty workaround for this - it seems to work for me. In ansitextview.c:

Code: Select all

gboolean
ansitextview_prune_extra_lines(gpointer data)
{
  WorldGUI *gui = (WorldGUI *) data;
  gint      lines;

  if (!gui->world) {
    return TRUE;
  }

  lines = gtk_text_buffer_get_line_count(gui->txtBuffer);
  if (lines > gui->world->buffer_lines) {
    GtkTextIter start;
    GtkTextIter end;
    int         to_del;
    
    to_del = lines/2;

//    to_del = lines - gui->world->buffer_lines;

So, the idea is that the excess lines are not deleted all the time - when the maximum is reached, half of the lines are brutally removed. Of course you can set another divisor to cut only third or so on.

[ChrisKCMO]

This might also relate to topic "Scrolling bug in channels plugin" ( viewtopic.php?f=3&t=5438 ).

First of all, thank you for an awesome application. I use this both in Ubuntu and Windows 10, and it works pretty well. Unfortunately, after some time spent navigating and building on a MUSH server, usually after about 20 minutes, the text on the screen suddenly stops scrolling forward, and instead seems to get stuck on the text from about 10 or 20 rows earlier. Any attempt at issuing commands to the MUSH server does not cause the text to update, it just seems to be stuck. A work-around seems to be to press the Page Up button and Page Down button back and forth a few times, with an extra couple of Page Down button presses, after which the text then begins scrolling again with MUSH commands. Unfortunately the problem occurs again very soon. The only way to clear this for a while is to terminate the application and start it again.

However, it seems like the problem might only be occurring if I have multiple accounts logged on in different windows/tabs at the same time. I thought that a work-around to avoid the problem might be to open two separate running instances of the application, instead of using two separate windows/tabs in the same running instance, but this did not avoid the problem and it still occurred. As far as I can tell it doesn't seem to be a problem if I am connected to only one MUSH server, but since I logon as multiple accounts at the same time (regular player and wizard player) in order to test building, being able to logon multiple times at the same time is needed.

I'm currently running KildClient 3.2.0 on both Ubuntu and Windows, and the same problem is occurring in both operating systems. I downloaded the Windows application from the download web page ( https://www.kildclient.org/site/downloads ) and downloaded the Linux application from using the built-in Ubuntu application installer (app store).

Thank you in advance for any advice that you might be able to offer towards working around this.

Chris in KCMO