Microsoft-ui-xaml: Proposal: updating text controls to properly handle large files

[Sergio0694]

Proposal: updating text controls to properly handle large files

Creating this issue as suggested by @anawishnoff on Twitter. This proposal links back to a similar one on the UWP Community Toolkit about a virtualized RichEditBox control.

Summary

One common complaints about the native text controls on UWP (namely, TextBlock, TextBox, RichTextBlock, RichEditBox) is that they are not able to properly handle large files. Trying to load a 1MB text file into any of those controls will cause apps to either become unsustainably slow, or just crash. So far developers have either had to limit functionality in their apps to avoid hitting this issue, implement solutions like using multiple TextBlock controls in a virtualized items panel (which has its own set of downsides), or resort to (paid) 3rd party controls that properly supported this scenario. Some have just gave up on working on UWP because of this, unfortunately.
The proposal is to update the existing text controls so that they will behave properly even when dealing with large text documents to render.

NOTE: this proposal is pretty much a draft and meant to also just help spark a conversation about this issue. If a better approach to solve this would be to just add some new, specialized controls to handle large files, that could be ok too. The bottom line is, there should be a native way on UWP to display large text files, without the need for custom controls.

Rationale

• Rendering text is one of the most common things done my apps. Having controls that are able to properly handle large text files would make apps more responsive in general, and make life easier for many developers too.
• It might be a way to attract more developers to UWP, especially those that are now forced to stick to WPF because of this issue
• It would be another way to just give more devs the feeling that UWP is a framework that's perfectly capable to handle common tasks just like frameworks like WPF and WinForms without the fear of hitting unexpected issues or roadblocks

Scope

| Capability | Priority |
| :---------- | :------- |
| Being able to render large text files | Must |
| Being able to edit large text files | Must |

Open Questions

As mentioned in the note above, whether the best way to approach this would be to just update the existing controls, or to include some additional, specialized controls to WinUI, is open for discussion.

[yaichenbaum]

Very well written, this is something that has bugged me for quite some time and I would love to see it solved! One small thing I would suggest is to add the TextBox control to the issues description.

[dpaulino]

I need this.

For more clarity: I need this because I own a UWP rest client. When users ping an endpoint that returns an enormous amount of text, using UWP's native textbox controls will crash the app. For instance: https://github.com/jenius-apps/nightingale-rest-api-client/issues/6.

In the ideal world, my UWP rest client should be able to load text, edit text, and scroll the text with at least as much efficiency and performance as Notepad.

I would love to get a control with at least the same text performance as Notepad.

[adrientetar]

Yeah we need a control that can serve as a base for a code editor, with virtualization and callbacks when some text is changed to update the syntax highlighting for instance.

[Sergio0694]

@adrientetar We can more or less do that already by heavily customizing the RichEditBox control, see here a screen from my app Brainf*ck#. That control at least provides extensive support for customizing the formatting of all the text though, so I don't think we have such a big issue on that specific front. The real problem as mentioned before is the poor performance of the whole thing whenever you load a moderately large text, which is a game breaker for many devs unfortunately 😟

[adrientetar]

I'm not sure about the performance of using RichEditBox spans since it's "retained mode", I think more designed for things like a word processor, unlike say vscode syntax highlighting.

[Sergio0694]

Yeah no, I agree that the performance of the RichEditBox (like the other controls) is not great right now with large files, which is the whole point of this issue. What I meant to say was that at least regarding some basic formatting the control already offers APIs to do that through the RTF format, and that adding APIs specifically for syntax highlight etc. was not the main point of this issue. If you'd be interested in such an advanced control specifically to build a text editor (and don't get me wrong, I think that would be nice too!) you should open a separate proposal issue for that though.

I kept this one proposal very restricted in scope because it's a very specific issue and yet a very common one, and keeping the scope small will help the team properly track this.

[ryandemopoulos]

_(pasting this from the Discord conversation we had, so others can see it)_

Thanks for highlighting this Sergio. This issue is a reasonable request, and I appreciate how you scoped it too. What I don't know is when we'd be able to do this--the team is largely focused on 3 areas right now:

1) De-coupling WinUI 3 from the OS (largest use of our resources)
2) Getting us ready to go open source (a surprisingly large endeavor as we solve hundreds of private API dependencies)
3) Building new features/capabilities

This ask would kinda fall into bucket #3. Most of the "bucket 3" work we do is in WinUI 2--the reason being that it allows people to start using those new capabilities now instead of having to wait until WinUI 3 ships. Unfortunately we can't change how our text controls work via WinUI 2, since our text controls are "baked into the UWP XAML platform". So, if we wanted to improve this, then we're talking about doing this in WinUI 3.

We could certainly look at doing this in 3.0, or 3.1; we'd just have to weigh it against the other asks we have from the community, and everyone would need to know that it would be many months before the new capability would be something you could consume (due to it requiring WinUI 3 to ship first).

I'm going to unassign myself for now since I'm not actively working on it, but we can revisit once we start to wade thru the backlog of these WinUI 3-centric asks.