When running certain cli commands, the terminal component is really slow to load.

[atljoseph]

Running plandex (github repo) inside the terminal, and it is VERY slow to load. This lib uses some TUI libraries.

Running nvtop is blazing fast.

Is there a way to make sure this is more efficient?

It is slow whether i run it for the first time opening terminal, or for the 10th time running a command on an existing terminal.

[andydotxyz]

Performance is based on the number of characters that change on each redraw. Text caching is improving in Fyne which will improve this greatly.

[atljoseph]

Also doesn’t seem to stream results back from whatever background process is handling the session with the os. Seems to sandbag until the end on some things. That plandex cli also uses a tui lib which might affect it

[andydotxyz]

Also doesn’t seem to stream results back from whatever background process is handling the session with the os. Seems to sandbag until the end on some things. That plandex cli also uses a tui lib which might affect it

I don't know what this means. When the shell gets bytes they will write to the screen of the terminal.
Perhaps you can describe the steps to replicate an issue where changes are not updating on screen...?

[atljoseph]

I don’t mean to confuse. I mean exactly what was said. Run “nvtop” or “top”. It’s fast. Clone and build the plandex repo in golang. Run it. It’s WAY slow on this terminal, and fast in a normal one. Thats all I know. I ran away after that, to another project.

…

On Wed, May 22, 2024 at 3:58 PM Andy Williams ***@***.***> wrote: Also doesn’t seem to stream results back from whatever background process is handling the session with the os. Seems to sandbag until the end on some things. That plandex cli also uses a tui lib which might affect it I don't know what this means. When the shell gets bytes they will write to the screen of the terminal. Perhaps you can describe the steps to replicate an issue where changes are not updating on screen...? — Reply to this email directly, view it on GitHub <#83 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF632FP5F6YSJLCWBHUKLZ3ZDT2GTAVCNFSM6AAAAABH63QRTSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRVGY2DGNBZGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[atljoseph]

Jumped over to use gowid terminal and not fyne On Thu, May 23, 2024 at 8:53 AM Joseph Gill ***@***.***> wrote:

…

I don’t mean to confuse. I mean exactly what was said. Run “crop” or “top”. It’s fast. Clone and build the plandex repo in golang. Run it. It’s WAY slow. Thats all I know. I ran away after that, to another project. On Wed, May 22, 2024 at 3:58 PM Andy Williams ***@***.***> wrote: > Also doesn’t seem to stream results back from whatever background process > is handling the session with the os. Seems to sandbag until the end on some > things. That plandex cli also uses a tui lib which might affect it > > I don't know what this means. When the shell gets bytes they will write > to the screen of the terminal. > Perhaps you can describe the steps to replicate an issue where changes > are not updating on screen...? > > — > Reply to this email directly, view it on GitHub > <#83 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AF632FP5F6YSJLCWBHUKLZ3ZDT2GTAVCNFSM6AAAAABH63QRTSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRVGY2DGNBZGA> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[andydotxyz]

It sounds like this may relate to scrolling. The movement of entire content up one row to add another below could be the source of slowness.
We should be able to include this as an appropriate optimisation - let's see what we can do.