The output log is our most extreme example of a multi-line editable text, however it shouldn’t be causing that level of performance degradation. Given that it only happens when the log is visible, it’s most likely something in OnPaint() - I’ll take a look.
I also noticed that left-clicking inside the Output Log freezes the editor, like when an application gets stuck into an infinite loop.
I suppose is related. (?)
I have an open ticket for it, and I’ve been trying to get to it but I’ve just been really busy with other changes for 4.6. I hope to take a look at it before the end of the week.
Just to let you know, I’m currently looking at this.
When the output log isn’t being modified, most of the perf. drop comes from text rendering. I’ve done some work to improve the font cache access, but really there’s some larger Slate perf. changes that will become part of 4.7 that should make this equivalent of the perf. in 4.4.
When the output log is being modified, as in the case of your “log once per-frame” case, the perf. drop comes from the increasing layout complexity as new text is added. Seeing as we’re not wrapping the output log, there should be some nice wins that we can get by skipping some parts of the layout process. I’m currently investigating these.
It turned out to be quite simple. FTextLayout::AddLine was causing a re-flow of the entire document when a new line was added, rather than only flowing the line that was being added.
I’ve not being able to reproduce your hang when left-clicking (or right-clicking) in the output log. Does that happen all the time, or only when there is a lot of text in the output log?
Great news! Thank you Jamie. I suppose the fix will be included into 4.6 release, right ?
About the hangs, I’ve been investigating further and it happens :
Always when left-clicking, except if you make the first left-click into the first line of the log (you can interact normally with the text after that).
Never when right-clicking, except if it is the first click you make and you have left-clicked before.
When I say first click, I mean the first click you make after having clicked any other part of the editor, not necessarily the first click you make after the application starts.
I’ve still not been able to reproduce the hang, however several people have reported it now, so you’re certainly not alone.
Are you building from source? It sounds like something is getting stuck in a loop, and if you’re building from source it would be really handy if you could reproduce the hang, then pause the debugger and post the callstack from the main thread. That should give me a better idea of where to look.
[Código externo]
> UE4Editor-Core.dll!FTextStoreACP::RequestLock(unsigned long dwLockFlags, HRESULT * phrSession) Línea 195 C++
[Código externo]
UE4Editor-Core.dll!FWindowsPlatformMisc::PumpMessages(bool bFromMainLoop) Línea 757 C++
UE4Editor.exe!FEngineLoop::Tick() Línea 2111 C++
UE4Editor.exe!GuardedMain(const wchar_t * CmdLine, HINSTANCE__ * hInInstance, HINSTANCE__ * hPrevInstance, int nCmdShow) Línea 133 C++
UE4Editor.exe!WinMain(HINSTANCE__ * hInInstance, HINSTANCE__ * hPrevInstance, char * __formal, int nCmdShow) Línea 190 C++
[Código externo]
Just for clarification (in case something has changed in 4.5.1) I used the 4.5.0 source code to make the test.
When you’re getting the hangs, are you actively using the tablet to navigate (as if it were a mouse), and do you know if you have any handwriting input features enabled for it?
It’s possible that it’s being picked up as an IME device, and that we’re not handling it correctly.
Thanks for your help tracking this down, it would have never occurred to me that this combination would cause that behaviour.
I’m going to try and get my hands on a tablet to test with as several people have reported this hang (I’m also checking to see if they have the same root cause - at least one of the callstacks is the same as what you posted above).
I’ll reply again once I have more information, and hopefully, a fix
Okay, I managed to get hold of a Wacom Bamboo tablet today.
The issue only seemed to happen on Windows 8, and was seemingly caused by us telling the TSF run info that it had a length much greater than the maximum buffer size it told us was available - I’m guessing this caused TSF to overrun an internal buffer.