[GH-ISSUE #533] TextView slow when highlighting in text with a lot of styling #385

New issue

Closed

opened 2026-03-04 01:04:33 +03:00 by kerem · 3 comments

kerem commented

2026-03-04 01:04:33 +03:00

Owner

Originally created by @normen on GitHub (Nov 25, 2020).
Original GitHub issue: https://github.com/rivo/tview/issues/533

Hi,

in my app I am using jp2a to display images in a text window. This happens through the ANSIWriter adapter and works fine. jp2a generates colored "ASCII Art" from the images. However when the TextView displays about 5 or 10 of such images (not too many characters really) then setting highlights in that TextView become slower and slower. I noticed that its probably the highlights because I can scroll the textView just fine, only setting a highlight is slow.

Cheers for this library, its awesome!
Normen

Originally created by @normen on GitHub (Nov 25, 2020). Original GitHub issue: https://github.com/rivo/tview/issues/533 Hi, in my app I am using jp2a to display images in a text window. This happens through the ANSIWriter adapter and works fine. jp2a generates colored "ASCII Art" from the images. However when the TextView displays about 5 or 10 of such images (not too many characters really) then setting highlights in that TextView become slower and slower. I noticed that its probably the highlights because I can scroll the textView just fine, only setting a highlight is slow. Cheers for this library, its awesome! Normen

kerem closed this issue

2026-03-04 01:04:33 +03:00

kerem commented

2026-03-04 01:04:33 +03:00

Author

Owner

@rivo commented on GitHub (Dec 4, 2020):

Yeah, I'm guessing the ANSIWriter creates a lot of extra tags which then have to be parsed again and translated back into colours, line breaking and all. I would expect this to get slow the more you add.

I'm not sure I have a quick fix for this. But I do have an Image primitive in mind for the future that will do something similar to jp2a. That way, you won't have to go through the TextView. Implementing it would mean ignoring issues for a while, though, so I'm not yet sure where to set priorities.

@rivo commented on GitHub (Dec 4, 2020): Yeah, I'm guessing the ANSIWriter creates a lot of extra tags which then have to be parsed again and translated back into colours, line breaking and all. I would expect this to get slow the more you add. I'm not sure I have a quick fix for this. But I do have an `Image` primitive in mind for the future that will do something similar to `jp2a`. That way, you won't have to go through the `TextView`. Implementing it would mean ignoring issues for a while, though, so I'm not yet sure where to set priorities.

kerem commented

2026-03-04 01:04:33 +03:00

Author

Owner

@normen commented on GitHub (Dec 4, 2020):

I see, thanks for the answer. I saw that the matrix client gomuks has a nice ANSI-Image conversion thingy, maybe thats interesting.

@normen commented on GitHub (Dec 4, 2020): I see, thanks for the answer. I saw that the matrix client [gomuks](https://github.com/tulir/gomuks) has a nice ANSI-Image conversion thingy, maybe thats interesting.

kerem commented

2026-03-04 01:04:34 +03:00

Author

Owner

@rivo commented on GitHub (Dec 12, 2022):

Closing this as I don't see any solution to this issue. Performance will get better with improvements made to TextView but the double-conversion will always remain and potentially slow the application down.

@rivo commented on GitHub (Dec 12, 2022): Closing this as I don't see any solution to this issue. Performance will get better with improvements made to `TextView` but the double-conversion will always remain and potentially slow the application down.

kerem referenced this issue

2026-03-04 01:05:22 +03:00

[GH-ISSUE #657] [Feature Request] add Flex.GetItem() #482