Description: The comment highlighting is painted after the text rendering and flashes when scrolling Steps to Reproduce: 1. Open the attached file 2. Go to page 134 3. Scroll up or down.. notice that the comment overlay highlighting being painted separately with a delay. [So first document rendered Actual Results: Flashes slightly Expected Results: Text and highlighting should be rendered in advance of screen. Reproducible: Always User Profile Reset: No Additional Info: Found in 7.3 and in 6.0 and Versie: 5.3.3.1 Build ID: 46360c72c4823cefeaa85af537fba22bd568da7e CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; Layout-Engine: nieuw; Locale: nl-NL (nl_NL); Calc: group and in 5.0 and in less obvious in 4.4.7.2 (but I think I'm still noticing it; timers appears to have an impact [bad for tracing it] :-( and with Version: 4.3.7.2 Build ID: 8a35821d8636a03b8bf4e15b48f59794652c68ba looks stable with Versie: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
Created attachment 175059 [details] Screencast
Created attachment 175060 [details] Example file
I don't see even "slightly" effect in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 80a47aae1419842f4496f02028e2b49763aea25b CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded
(In reply to Roman Kuznetsov from comment #3) > I don't see even "slightly" effect in Hmm.. A) You do notice the flickering in the screencast, I hope. B) How to you scroll, with scroll wheel or swiping? However I do see it while scrolling & dragging the vertical scrollbar. So it shouldn't make much of difference Note: does 'blink' once when scrolling content (with comments) of and on screen.
Created attachment 175113 [details] Bibisect log RTF Bisected against RTF (ODT import gives read-error in 43max repro Commit below - nested comments - made it - at minimum - more obvious.. commit f2ac4d7e67ecc8f2653049a3c79727ec9901b73d Author: Matthew Francis <mjay.francis@gmail.com> Date: Thu May 28 18:13:17 2015 +0800 source-hash-149640c229ca987ab3186d08fe4514200dd854c1 commit 149640c229ca987ab3186d08fe4514200dd854c1 Author: Miklos Vajna <vmiklos@collabora.co.uk> AuthorDate: Tue Jan 14 19:41:53 2014 +0100 Commit: Miklos Vajna <vmiklos@collabora.co.uk> CommitDate: Tue Jan 14 19:45:52 2014 +0100 RTF import: fix nested comments Change-Id: I6236c255708f13131117246743d86cd3448bce24 https://cgit.freedesktop.org/libreoffice/core/commit/?id=149640c229ca987ab3186d08fe4514200dd854c1
Created attachment 175114 [details] Example: More reduced
Hello Telesto, a new major major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Still reproducible Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 1c1647e6ee252fe68d7406d01043e88f1721590f CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL
Testing with the last pages of attachment 175114 [details] I guess I can see some very slight delay in painting the highlights, but it doesn't really bother me. I also tried with 4.3 and scrolling in that might be otherwise jumpy in a different way. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ec4babad021218b75dfe8534985d7db525edde69 CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_FI); UI: en-US Calc: threaded
Tested with attachment 175114 [details] and Version: 24.2.0.2 (X86_64) / LibreOffice Community Build ID: b1fd3a6f0759c6f806568e15c957f97194bbec8f CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded I can't see any effect similar to that effect in screencast of comment 1. Telesto, yould you please retest and - if you can still see it - rethink, if it is really worth to report it as a bug. Thank you => NEEDINFO
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4d381b54d1c598c181b4a21a8bf0db86eb4668d1 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded Looks fine to me
Created attachment 194598 [details] Screencast
Created attachment 194599 [details] Example file
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: aef28c23adc87b8e26eacb56c7dbcf652e907fb9 CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Tested with attachment 194599 [details] but I still can't confirm. Version: 24.8.0.0.beta1 (X86_64) / LibreOffice Community Build ID: 318462181c709ed29c01eb3239b4d600d7b82ecc CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded According to your previous comments: It looks fine with Windows but bug is still present with macOS?
Seems to be specific to Windows 8.
(In reply to Buovjaga from comment #16) > Seems to be specific to Windows 8. Well I initially reported it with Windows, I couldn't reproduce it anymore comment 11. I now see it on macOS comment 14. Scrolling the file is in general slow, so you can actually see two separate steps. Updating view port; overlaying the comment highlighting. So it's not Windows 8
I do actually notice this also with attachment 194599 [details] on Windows Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c39e4f6b8a942680bc7250177c34fd034a0605e0 CPU threads: 4; OS: Windows 8.1 X86_64 (6.3 build 9600); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded For quick machines. Create system load. Run prime95 in the background on all cores and/or attach CPU profiler to soffice.bin (or entire system).