PrintPreview on long strings loops endless

Hi Severin,

The problem here is that the Microsoft WPF text formatting API we use in SyntaxEditor needs to wrap text at a certain point that would exceed some x-value or else an exception occurs in their code.  That point is very far out and normally in 99.9% of cases never gets hit, but will be hit in your example.  So we have it set up to word wrap before that point is hit.  Your example causes word wrapping to execute multiple times and if you profile the app, you can see nearly all this time is hung up in the Microsoft text formatter call.  I'm not sure exactly what it's doing that's taking the time but perhaps it's extra bad because you don't have any spaces in there.  Nevertheless, extremely long lines are the only performance issue we're aware of in the product, as code in the Microsoft text formatter takes a while to handle them.  So unfortunately I'm not sure if our product will work for you since we use their text formatter and it introduces the performance lag in that scenario.

Hi,

many thanks for your explanation of what is going on behind the scenes. There is only one additional question:

when I modify the code in the OnLoaded function below, the text is loaded into the document view without any problems and good performance:

private void OnLoaded(object sender, RoutedEventArgs e)

 {

 string newText = new string('1', 500000);

 Action action = () => this.editor.Document.SetText(newText);

 Dispatcher.BeginInvoke(action);

 //this.Dispatcher.BeginInvoke(DispatcherPriority.Send, (DispatcherOperationCallback)delegate(object arg) {

 // this.RefreshPrintPreview();

 // return null;

 //}, null);

 }

The problem occurs only in the RefreshPrintPreview. When I forgo printing such documents I could use your SyntaxEditor, because all other features I want to use like highlighting, searching for strings and custom line numbering are working fine with very long strings. Are you using different text formatters for Printing and for viewing/editing?

Brgds

Severin

I think what happens is that since the editor views allow very long lines by default, word wrapping in your test case only occurs a handful of times.  Even so, typing is somewhat laggy due to the need to recalculate word wrap again for the extremely long lines and recalculate everything for 500,000 characters.

The print views probably take longer since those wrap much sooner and more often, at the edge of each page's available width.  So whereas an editor view might have say 20 lines wrapped (due to the reasons described in our previous post), the printer view will have thousands of lines wrapped.  And that takes longer to process.  I believe that is the difference here.