Reduce blanking effect? about gdb-dashboard HOT 4 CLOSED

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.

from gdb-dashboard.

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...

from gdb-dashboard.

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.

from gdb-dashboard.

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

from gdb-dashboard.