Re: [PATCH] Speed up "gdb -tui" output

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Wed, 7 Jan 2015 10:56:11 -0800
> From: Doug Evans <dje@google.com>
> Cc: Pedro Alves <palves@redhat.com>, gdb-patches <gdb-patches@sourceware.org>
> 
> >> So, yeah, it seems like gdb_flush for tui needs to do a wrefresh
> >> (for gdb_stdout/stderr (/stdlog?))
> >
> > At least, see my other message.  And it should treat them differently,
> > since their buffering is different, and the rest of GDB relies on that
> > a lot.  And tui_puts currently doesn't know which stream it serves.
> 
> It's easy enough to make tui_puts know what stream it's serving though,

Yes, and then we'd need to figure out which stream to pass to it in
its other callers (there are 6 of them).

> >> One paints the window and then does a refresh.
> >
> > Except that for the command window, there's no such thing as "paint
> > the window", AFAICS.
> 
> By "paint the window" I mean writing something into that part of the
> screen.

This is only known on the upper level of the GDB code, the one that
actually generates the stuff that is to be written on the screen.
Lower levels have no idea whether they were called to output a single
character that is just a single character, or a part of a string.

And since there are literally gazillions of calls to output functions
on the higher level, it is only natural to try to fix this in a
smaller number of places, which means on lower levels.  I still hope
it's possible.  Maybe I'm dreaming.

> > Various parts of GDB write out various text
> > strings whenever they feel like.  You don't have a single point where
> > you can tell the window is done.  Currently, we simply refresh every
> > character.  My original suggestion to use a newline as such a point
> > was an attempt to find an easy solution, and we already know why that
> > is not good enough.
> 
> There's no "single" point, but OTOH there aren't many points either.

Not sure what you mean here.  Can you identify those points, or
explain how to identify them?

> >> We want to add scrolling of the command line window on
> >> top of that, but if the intent is for that to be handled by
> >> gdb's standard set height mechanism (which could use
> >> some TLC w.r.t. TUI), then the screen will be refreshed
> >> at the "Type <return> to continue, ..." prompt.
> >
> > Yes, of course.  And this is part of the problem that needs to be
> > solved.
> 
> Except that scrolling isn't straightforward in curses land.
> Do we "scroll" unfiltered output (that hasn't gone through
> the paginator) ?

We don't, but every text terminal window on any modern system has a
scroll-back buffer and a scroll bar to make use of it.  When you are
in TUI mode, this is lost.

> >> And therefore, I think we don't need to do any call to
> >> gdb_flush here.  Could be missing something though.
> >
> > Where's "there"?
> 
> tui_puts, at least in its current implementation.
> It's just an implementation detail though, so
> depending on how we fix things that can change.

Again, I don't understand how else can you emulate the standard
buffering behavior of the standard streams, which we rely upon in too
many places.