Reduce blanking effect?

[AndrewJDR]

Do you think it would be possible to reduce the amount of time that the terminal becomes blank between the updates?

i.e. Does it currently happen like this?
OnUpdate:
Clear Terminal
Gather / Print results

And if so, could it work more like this?
OnUpdate:
Gather / Buffer results
Clear terminal
Print buffered results

My reasoning:
The blanking causes me to lose my place visually. For example, if I'm trying to keep my eye on a particular watch expression, and I "next" (which triggers an update), The terminal blanks for probably a good 500-800 milliseconds before being redrawn, which causes me to lose my place...

[AndrewJDR]

I'm thinking this is out of your hands because that's how gdb does things?

But, I think I can use DASHBOARD_TTY as a workaround... that doesn't seem to exhibit the issue since it doesn't share printing with gdb.

[AndrewJDR]

I can confirm that using DASHBOARD_TTY is massively faster. Not only is the blanking practically non-existent, updates are way faster in general.
I assume the slow updates and long blanking time are fundamental limitations of the non-DASHBOARD_TTY approach, so feel free to close this if you also think so. Otherwise, feel free to pursue this more if you think something else is going on...

[cyrus-and]

Yeah, this is annoying, I know, and your reasoning is sound.

The time needed to build the dashboard is perceived as a blank terminal as the screen needs to be cleared in order to have the dashboard in the same place at the next step.

Unfortunately I cannot buffer the content because (to my knowledge) there's no way to fetch the normal GDB output (e.g., Continuing. Breakpoint 1, fun (n=1, data=0x7fffffffe918) at file.c:42); here's for example what happens after issuing the next command:

1. on_continue: the screen is cleared and the Output/messages divider is printed;
2. program I/O takes place;
3. GDB may print some run-time information;
4. on_stop: the dashboard is built and displayed.

Note that I cannot build the dashboard at step 1 an the program status has not evolved yet.

Now one could think to completely ignore that run-time information, but since it is not limited to breakpoints notification I'm not sure it's a good idea. Moreover, there's the program I/O which cannot be ignored.

I can confirm that using DASHBOARD_TTY is massively faster.

In that case it should not be blanking at all since as the dashboard can be buffered and the behavior is similar to the one you're suggesting.

Talking about solutions I can only think about to:

• try to find and remove the bottle necks in the modules lines() method in order to reduce the blank time;
• dig deeper into how GDB handles the program I/O and the log stream, but in my experience fiddling with the logging system is likely to cause buggy behavior.

I'll leave the issue open as I'd like to improve this aspect. Thanks for reporting.

[cyrus-and]

I finally managed to look into this, now the blanking effect should be drastically reduced, at least for what concerns the assembly module.