Description: Spinoff of bug 113091 (based on comment 5). The CPU usage is pretty high for deleting some content with backspace. This is about the small bump (of around 5%). Steps to Reproduce: 1. Open attachment 137565 [details] file based on bug 113067 2. Place the cursor and the end of the latest word on the first page 3. Hold backspace and monitor CPU usage Actual Results: A bump in CPU usage from 20% (LibO5.0) to 25% (since 5.1) Expected Results: Should be less CPU intensive Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 6.0.0.0.alpha1+ Build ID: c24c32bf71b8e64bd0d36e511f554e1f6c015842 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-11-22_23:15:41 Locale: nl-NL (nl_NL); Calc: group threaded and in 5.2 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 137946 [details] Bibisect log Bisected to: author Miklos Vajna <vmiklos@collabora.co.uk> 2015-08-07 14:35:11 (GMT) committer Miklos Vajna <vmiklos@collabora.co.uk> 2015-08-07 14:35:23 (GMT) commit c64a7ce1fcd1e30956a77530d0b76ad493841024 (patch) tree 723796de700b511614ffeb9c36b12284fa5d3255 parent a6c7a0bf105c399d087e2d9f843dbd9b175fdf42 (diff) Resolves: tdf#92982 vcl rendercontext: handle buffered paint of vcl::Cursor Instead of painting on the vcl::Window directly, take a PaintBufferGuard, and use the vcl::RenderContext of it, that may be either the vcl::Window or the toplevel frame's buffer. Trigger the paint of the buffer by informing the guard what area was painted. In case of direct painting, both the ctor and the dtor of the guard is a NOP. This means that finally we can also assert Invert() calls on the output device, so that direct paint can't happen when double-buffering.
65% for me without Auto spell check and 100% with Auto spell check. Arch Linux 64-bit Version: 6.0.0.0.alpha1+ Build ID: 008673c23db0c812eb0b48a1c29ab88b48aaa867 CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on November 23rd 2017
Adding Cc: to Miklos Vajna
*** Bug 116013 has been marked as a duplicate of this bug. ***
I assume that 100% and 25% is the same when you have 4 threads, just Linux interprets that as 100% and Windows divides the number by the number of threads. I don't really see a performance improvement if I undo the above commit on Linux, doing an optimized Windows build now, hopefully it'll be visible there.
Created attachment 142591 [details] Blind patch. I think what's misleading is that c64a7ce1fcd1e30956a77530d0b76ad493841024 on 2015-08-07 introduced the commit cited above, but then later on 2015-09-04 012a7115d11c6bc2f4c3c33180c319d043a22d51 optimized the non-double-buffered codepath. That means anything after that is really the same as the old state by default. Could you confirm that the attached patch doesn't fix the problem? (It's effectively a revert of both commits). If so, this is an opengl perf bug, not a regression. Thanks!
(In reply to Miklos Vajna from comment #6) > Created attachment 142591 [details] > Blind patch. No change on Linux.
OK, then what remains is a performance problem, the above later commit already addressed the regression part. I also add this to the GL tracker as the duplicate bug 116013 is specific to GL.
Lets close as a margin issue