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.
For reference, what spec is your machine?
Here you have my DxDiag.
I know my rig is starting to get outdated, but I don’t think that’s the issue. I haven’t had this problem in previous versions of the engine.
In 4.5 preview, the Output Log causes a big performance hit. The larger the log, the worse.
Hiding the Output Log solves the issue. Clearing the Output Log solves the issue until it grows again.
In my case, the editor can go from 120fps to 20fps in just a few minutes with an empty scene and just one log per frame.
Since 4.5, same problem for me. When showing the output log, big slow down for the editor.
Also, the UI vertical scrolling bar is blocked.
Did you take a look into this ?
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. (?)
Sorry, not yet.
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.
Thanks for your patience.
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.
Great! Thank you Jamie.
I’ll try to avoid per-frame logs for now, then.
Please, don’t forget about the freezes when left-clicking on the Output Log. It’s not just a performance issue.
BTW, I get lots of this errors when I change the focus from the Output Log to other editor window :
LogWindowsTextInputMethodSystem:Error:
Deactivating a context failed while
setting focus to the disabled TSF
document manager.
I don’t know if it’s related.
Don’t worry about that warning, it’s unrelated and has actually been removed in 4.6 since it fired a lot when things were actually fine.
I’ve fixed your perf. issues when logging a lot of output log text: https://github.com/EpicGames/UnrealEngine/commit/7775242a9362fa07cfbba8b8270bf2f946852c25
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 :
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.
Scrolling with the wheel always works fine, btw.
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.
Hi Jamie, here’s the call stack :
[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.
The line 195 is this one :
*phrSession = AdviseSinkObject.TextStoreACPSink->OnLockGranted(LockManager.LockType);Excellent, thanks 
That’s the TSF based IME code. Are you using an IME, and if so, which?
I don’t think so. I didn’t even know that was a thing until know. I’m spanish and I have a standard spanish keyboard.
I think I got it! Looks like unplugging my Wacom tablet solves the issue.
Ah, that’s interesting.
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.
I always have my tablet plugged in but I never use it for navigation.
Looks like windows enables by default a service called “Touch Keyboard and Handwriting Panel”.
I disabled it following these instructions.
Now the editor doesn’t freezes anymore even with my tablet plugged in.
Success! 
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.
Should be fixed by 23cb8cbc5b90b684f65edd2c0a21a731d219fd56