UI: page scroll bar not functioning properly (dragging not responding; not properly positioned when scrolling)
Steps to Reproduce:
1. Open the attached file
2. Click the vertical scroll bar and drag down -> Not responding
3. Scroll down to bottom (or using page down key and scroll up)
-> Skia painting issue
User Profile Reset: No
Version: 126.96.36.199.alpha0+ (x64)
Build ID: 94e6e140491de31c0788c91af855a75a3bb12709
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Created attachment 166462 [details]
*** Bug 137975 has been marked as a duplicate of this bug. ***
I do not reproduce with either 94e6e140491de31c0788c91af855a75a3bb12709 or today's master on Linux Fedora 32.
Telesto: would you please retest to see whether you can reproduce with a most recent master? I yes, then could you try to bibisect, following the instructions on the wiki page:
(Bibisecting is not that hard! And it's fun and helpful for bug fixes)
(In reply to Kevin Suo from comment #3)
> I do not reproduce with either 94e6e140491de31c0788c91af855a75a3bb12709 or
> today's master on Linux Fedora 32.
> Telesto: would you please retest to see whether you can reproduce with a
> most recent master? I yes, then could you try to bibisect, following the
> instructions on the wiki page:
> (Bibisecting is not that hard! And it's fun and helpful for bug fixes)
This is likely a Skia issue; not sure if ran in Linux Skia mode
Bibisecting is not that hard! And it's fun and helpful for bug fixes)
BTW: Not totally new around here ;-). And have done number of bibisect already.
Fun, matter of preference :D. This is luckily for me a straight forward bibisect
Created attachment 167083 [details]
author Luboš Luňák <email@example.com> 2020-10-06 22:14:36 +0200
committer Luboš Luňák <firstname.lastname@example.org> 2020-10-08 13:40:14 +0200
commit d18731f71c60cbb6c02cabb042004b1aa9454de8 (patch)
parent 47fda617fc4dad8273919227ca45ea3b8b61aea1 (diff)
track dirty areas for Skia drawing
Updates to the screen in raster mode aren't _that_ slow, in fact
it seems using SkRegion can make things slower because of manipulating
the region, but with SkIRect this could sometimes help a bit.
It also appears that StretchDIBits() that is used by the Windows
raster code doesn't work correctly if only a subset of the y-axis
range is specified, which reduces the usefulness.
Setting to NEW by duplicate + bibisect
Adding CC: to Luboš Luňák
I cannot reproduce. And the information is contradictory, you say it's Skia, but the system info in the original comment says Skia is not enabled. So what exactly is the setup to reproduce this?
Created attachment 167201 [details]
(In reply to Luboš Luňák from comment #8)
> I cannot reproduce. And the information is contradictory, you say it's Skia,
> but the system info in the original comment says Skia is not enabled. So
> what exactly is the setup to reproduce this?
That's because I tested Skia first, switched to GDI (to compare) and copy/pasted that they about
To observe the bug, start near the end of a multi-page *.odt file, and scroll up; the slider is double: one very thin one that moves normally, and the thick, normal-looking slider that lags behind —doubleSlider.png.
After I wrote this screenshot, the thick slider spontaneously caught up with the thin one —doubleSlide.png. It seems that the slider simply redisplays too slowly.
Created attachment 167226 [details]
screenshot of double slider
Created attachment 167227 [details]
screenshot of double slider merged into one piece
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":
fix updates of Skia draw region for Windows widgets (tdf#137559)
It will be available in 7.1.0.
The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.