Sergio0694 commented 4 years ago

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.

dpaulino commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

WelterDevelopment commented 3 years ago

For people who stumble over this and are searching for a fast text editor control for WinUI 3 that handles >10000 lines: CodeWriter-WinUI Its only a proof of concept but you can build your own text control from there pretty easily.

bogdan-patraucean commented 2 years ago

Just tried to open a file of 600 Kb in a RichEditBox with the Document.LoadFromStream() method. As it doesn't have any async method it just blocks the UI thread for 2 seconds (considering I have a very powerful configuration on my PC). This should be prioritized as it's a very serious limitation for anyone trying to display file contents. For now I'll have to park the feature I worked on because I spent a few days trying to unblock the UI thread with no results.

Sergio0694 commented 1 year ago

Bumping this (see https://github.com/microsoft/microsoft-ui-xaml/discussions/8638).

aquinn39 commented 5 months ago

To add to this, text seems to disappear from text controls when there is too much of it - happens in both WinUI 2 and 3. Despite the text not rendering, it can still be copy and pasted. This issue does not happen with WPF (Or at least, its threshold is far greater). Kind of disappointing for Microsoft's 'latest and greatest' UI platform. It's not even a particularly large amount of text that causes this either. It's also not even documented as a known limitation, leading to unwelcome surprises from developers migrating from WPF to UWP and/or WinUI. WPF is from 2006 and yet does not have this issue. This is probably why Notepad is stuck using GDI to render text, even though the rest of the UI uses WinUI 2.

Text eventually starts to render weirdly then stops rendering at all:

Balkoth commented 3 months ago

Another day, another WTF in WinUI3-Land.

microsoft / microsoft-ui-xaml