[Libreoffice-bugs] [Bug 139296] scrolling document canvas down & up can cause a line of text to "tear" with loss of registration, it clears when the line moves out of view far enough or view passes to a new page

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Mon Jan 11 17:24:44 UTC 2021


https://bugs.documentfoundation.org/show_bug.cgi?id=139296

--- Comment #14 from V Stuart Foote <vstuart.foote at utsa.edu> ---
(In reply to spokanemagneto from comment #13)

> ... If it turns out that it is a bizarre driver issue, then I will
> admit I raised an alarm unnecessarily, but when I am told that it only
> affects 5% of users, then I know that the problem is genuine no matter what
> the eventual fix is and I was not wrong in bringing to everyone's attention.
> I felt I was being dissed by being told that it was a trivial problem and
> won't be addressed. I never asked that he drop everything to work on it or
> that it would be easy to find it, but there is a big difference between
> can't and won't. The latter term nearly made me uninstall LO, but I was
> hoping someone else would at least give finding the problem a try. 

I am sorry if you were feeling dissed--please it is not that at all, and thank
you for taking the time to file a valid issue.

But note this was *my* testing of the issue you raised, expending considerable
time I did confirm it.  It is trivial because it is *transient* and affects the
VCL canvas on Windows builds. An assessment based on 10 years for doing QA
review of issues on the LibreOffce and OOo.

It has been set NEW--rather than confirmed and closed as WONT FIX, or being set
NOT A BUG--and the lead dev working rendering issues notified.

However, my exact wording was "This occurs in a very low percentage of scroll
movements <5% , but it does occur with GDI default mode rendering, and with
both Skia Vulkan and Skia raster mode rendering."

You'll note not only did I test your submission, but also each of the other
rendering paths, and not just mouse scroll but the equally valid drag to
reposition the view frame with the 'thumb' on the scroll bar, while proving the
cursor Up/Down and Scrollbar Up/Down movements are likely not equally effected.

And losing view frame sync for a line of text at <5% of scroll movements was
generous, it is probably closer to <1%. It is difficult to reproduce, and so
nearly impossible to correct. I suspect it will be a y-height rounding issue
affecting buffer of vertical blocks of text on the VCL document canvas.

If there was a way to force it 100% by some combination of view port size, text
size, and scroll distance--sure it could probably be solved. But as is it STR
are too spurious to do anything with it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210111/afc32e7c/attachment.htm>


More information about the Libreoffice-bugs mailing list