| Summary: | High CPU usage when deleting some text with backspace | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Telesto <telesto> |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | ilmari.lauhakangas, vmiklos, xiscofauli |
| Priority: | medium | Keywords: | perf |
| Version: | 5.1.0.3 release | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=113091 https://bugs.documentfoundation.org/show_bug.cgi?id=113067 |
||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 136524, 93529, 113510 | ||
| Attachments: |
Bibisect log
Blind patch. |
||
|
Description
Telesto
2017-11-23 16:36:12 UTC
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 |