Bug 33366 - lines shift when scrolling (VIEWING)
Summary: lines shift when scrolling (VIEWING)
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2011-01-22 08:26 UTC by Dan Kimberg
Modified: 2015-03-07 14:42 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Pls. see Comment 5 (50.60 KB, application/vnd.oasis.opendocument.text)
2011-01-30 21:26 UTC, Rainer Bielefeld Retired

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Kimberg 2011-01-22 08:26:01 UTC
To demonstrate this bug, I create a writer document with a single line of text, e.g.:

these lines should be evenly spaced

and then copy/paste the line enough times to fill about ten pages of text.  Then I scroll through the document using the scroll wheel on my mouse.  Everything more or less looks fine, but if I hit CTRL-Shift-R (Restore View), some of the lines shift a bit, probably just 1 or 2 pixels.  After this, everything is fine until I scroll again.

In real world documents, I'll often see lines that are not only shifted but visibly clipped (perhaps shifted and then overdrawn by a neighboring line?).  Occasionally I'll see a line that's half okay, half shifted.  I thought this used to happen also with page-up and page-down keys as well, but I can't reproduce it that way right now.  I also thought the problem seemed to ease up a bit with 3.3.0rc2, but I can't swear that that's the case, maybe I just went through a period of light scroll wheel use.

In case it's relevant, I'm running Fedora 14 with the latest updates and a recent version of the proprietary NVIDIA driver.  I also see the problem on my work machine, which is Ubunutu 10.04, also running the nvidia driver.

I would be happy to help debug this if someone will give me an idea where to start looking.  The last time I tried (pre-LibreOffice), I found it difficult to get oriented because most of the comments and function names were in languages I don't read well.  But if it turns out that the relevant files have some English in them, I might be able to contribute.
Comment 1 Noel Power 2011-01-24 03:13:32 UTC
Of course I can't reproduce ( but then again I am not using the proprietary nv driver )

caolan, any ideas, I think you have looked at such strange bugs before, please reassign back to the list though if you don't feel you are can help with this one
Comment 2 Caolán McNamara 2011-01-24 03:25:58 UTC
Nah, unless it happens with e.g. nouveau then its not IMO worth investigating given the complexities of dealing with the proprietary driver
Comment 3 Dan Kimberg 2011-01-24 19:37:07 UTC
> Nah, unless it happens with e.g. nouveau then its not IMO worth investigating
> given the complexities of dealing with the proprietary driver

I've switched back to nouveau on one of my Fedora 14 laptop, and I still see the issue with nouveau.  I have noticed, though, that it seems to be sensitive to the document's magnification -- I couldn't demonstrate the issue with magnification at 100% or 160%, but it's easier to reproduce with magnification set at 175, 165, 164, or 105.  After a bit of playing around, I haven't seen an obvious pattern.

In case it matters, I used the right hand side of the trackpad to scroll this time, I didn't have a mouse handy.
Comment 4 Dan Kimberg 2011-01-26 12:28:09 UTC
Now that I'm paying more attention, I can add that I also see this without using the trackpad/scroll wheel to scroll, but just the right scroll bar.  At the moment, possibily because of a lucky combination of magnification and the details of the document I'm editing, it's easy to produce -- every time I scroll to a different part of the document, I see a lot of rendering errors.  I don't see the same behavior if I use page-up/page-down.
Comment 5 Rainer Bielefeld Retired 2011-01-30 21:24:59 UTC
[Reproducible] with "LibreOffice 3.3.0 RC4 - WIN7  Home Premium (64bit) German UI  [OOO330m19 (build 6 / tag]"
I created a Lorem Ipsum document as sample (pls. see attachment). 

For me with my PC
64 bit AMD Phenom II X4 955 Processor 32.2 GHz, 4GB RAM, 
Graphic Card: NVIDIA GeForce GT 430
It is reproducibel in the followint way:

0. Open document
1. make sure that Auto Spellcheck is disabled and caret is at the beginning
   of the text.
2. click scroll down button at the bottom end below scroll slider, so that 
   document scrolls line by line. Keep mouse button pushed for several seconds,
   until you will have reached page 3
3. <Ctl>+<shift>+<r> to restore view
   expected: scroll should have worked in a perfect way, nothing to restore
   actual: before you will have restored, many of the characters will have 
           looked a little blurred or scraggy. When I  restore view, I see the
           reported effect, and afterwards everything looks perfect.

Reproducibilty seems to be better with soft scroll activated

Unchecking antialiasing and hardware acceleration seems to be without influence
Comment 6 Rainer Bielefeld Retired 2011-01-30 21:26:07 UTC
Created attachment 42733 [details]
Pls. see Comment 5
Comment 7 Dan Kimberg 2011-02-18 07:00:59 UTC
For what it's worth, it appears to be insensitive to playing with the following options: "Screen font antialiasing," "Use hardware acceleration," "Use Anti-Aliasing," "Smooth scroll," and all of the writer compatibility options that have to do with spacing.  I've tried many others as well, these seemed the most relevant.

However, so far I've been unable to demonstrate it in Web Layout mode, only in Print Layout mode.

In case it matters, I can verify that this bug remains easy to demonstrate in 3.3.1rc2.  That doesn't seem to be an option in the drop-down above, but I've updated it to 3.3.1rc1.

I'll probably make another attempt to find the relevant code soon.  If anyone has any suggestions where to look, that would be helpful (last time I checked, there was a language barrier issue).
Comment 8 Dan Kimberg 2011-03-22 04:44:19 UTC
For the record, this bug remains in full force in 3.3.2.

I've now had the opportunity to observe it with both free and proprietary drivers on both ATI cards and NVIDIA cards (all Linux).  So I think it's safe to say that it's not a driver issue.

I've also updated the architecture to "all" because I've seen it on both x86 archtectures, and there doesn't seem to be a way to select just two.
Comment 9 Rainer Bielefeld Retired 2011-03-22 05:34:07 UTC
Comment 10 Dan Kimberg 2011-03-22 06:11:28 UTC
My mistake in mis-understanding the version field.  This bug occurs on all versions of LibreOffice Writer (and of OpenOffice going back at least 3-4 years), so I've marked it 3.3.0b2.
Comment 11 Björn Michaelsen 2011-12-23 11:46:30 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 12 Dan Kimberg 2011-12-23 16:39:11 UTC
This bug persists in 3.5.0beta1, observed on a 64-bit Linux build.
Comment 13 Aleksandar Katanovic 2013-02-03 17:56:18 UTC
I have a similar problem when viewing documents in LibreOffice Writer Version (Build ID: 5b93205). Some lines are blurred when scrolling in Web Layout View and they cannot be readable. Must switch to Print Layout View in order to read these lines.
Comment 14 QA Administrators 2015-02-19 15:39:58 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice ( or later): https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)

Thank you for your help!

-- The LibreOffice QA Team
This NEW Message was generated on: 2015-02-19
Comment 15 Buovjaga 2015-03-07 14:42:19 UTC
No repro -> WFM.

Win 7 Pro 64-bit, LibO Version:
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: fi_FI

Ubuntu 14.10 64-bit
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-