Update: the same error happens with Libreoffice 3.6.5.2-2 on the same system: Ubuntu 12.04 with Gnome Classic and Xorg Radeon driver (6.14.99~git20111219.aacbd629-0ubuntu2), whereas a Debian testing x64 system with Xorg Radeon driver (6.14.4-6) and Cinnamon shell does not show this bug, neither does 3.5.7 on this system. Seems the 3.6 branch has introduced a severe display bug that happens only on rare systems, but mine is one them.

Thanks for reporting. But I'm convinced this is exactly same behavior is already reported.

Kind regards,
Joren

*** This bug has been marked as a duplicate of bug 56932 ***

> *** Bug 60031 has been marked as a duplicate of this bug. ***
> *** Bug 58358 has been marked as a duplicate of this bug. ***

I am definitely not happy having seeing those to bugs being marked as duplicates of this one. Bug 60031 is definitely a duplicate of my bug 58358, but they describe a much more severe failure than the more cosmetic failures described here.

When 58358 or 60031 surface, any editing of a longer writer document is impossible. It is the sole reason that kept me from updating my 3.5.7 installation to any 3.6 version. It occurs only with rare combinations (of graphic driver, setting, what else?), but on my main system I found no workaround.

#3 was a cross post from bug 56932, so "this bug" refers to 56932.

Created attachment 81506 [details]
Screencast showing scrolling bug

This bug is still there with version 4.0.4, and it did start with 3.6 series as a regression. 3.5.7 is the last that worked. Having this bug as a duplicate of 56932 is ridiculous - this is a severe one making it nearly impossible to edit a text file, the latter is cosmetic, having some letters shifted for some pixels, and only onscreen.

To underline the severity of this bug I attach a screencast video with LibreOffice 4.0.4 on a Ubuntu 12.04 box with radeon video driver.

Some new findings: I can reproduce the bug only with zoom levels of 184% and higher, not with 183% and below. And clicking onto the page restores its content - most of the time. With a distorted page, cursor left / right still steps along the letters of the (invisible) true content.

And can anybody correct the wrong association of bug 60031 with bug 56932 and set it as a duplicate of this one?

Using 4.0.4 now on a regular basis I found out: this bug appears only when the zoom level is set to page width - this is what I use most, but it vanishes with zoom set to optimal or to page height. Maybe this also has to do with screen resolution: I use 1680x1050.

With this bug editing sometimes seems to leave the text unchanged, only the cursor advances - changing zoom levels or forcing a screen redraw shows the text in fact _is_ changed, but the screen did not show it - very confusing.

*** Bug 60031 has been marked as a duplicate of this bug. ***

*** Bug 65603 has been marked as a duplicate of this bug. ***

Changed version to oldest known (from Bug 65603).

Does It still reproducible with 4.1?

Update:

With 4.0.4 I saw this bug also on another system with Ubuntu 12.04, with Intel Chipset graphics on a Atom netbook. On this system the bug appeared with zoom set to optimal, and vanished with zoom set to page width, in contrast to my desktop.

With 4.0.5 on the bug appeared on my desktop system (with maximized application window) with zoom set to page width, full page and custom zoom levels starting with 184% up to 600%; no bug was seen with 183% and below, and with 'optimal'.

4.1.1.2 changes the picture somewhat. The bug is still there, with zoom set to page width and with custom zoom levels from 184% up to 215%; there is no bug with zoom 183% and below or 216% and above, and no bug with full page or optimal.

When scrolling with high zoom levels (400% and above) I noticed a similar picture during scrolling as seen with the bug, but as soon as scrolling stopped and screen redraw has finished, all is well. This points me to a possible explanation of the bug: could this be a race condition? Redraw takes pixels from a region that itself has not been fully redrawn yet?

@Heinz Repp: Thanks for confirming. Could you also try to change the settings mentioned at bug 60537 comment 2, and report the results here? thanks.

Tested with LibO 4.1.1.2:

Bug present with print layout mode, not present with web layout mode

Settings of hardware acceleration, anti aliasing or smooth scroll (on or off) do not change anything.

This bug also appears on FreeBSD (9.2-STABLE, x86) with a Nvidia/331.67, with LO since version 4. Currently using LO 4.1.6.2. Bug in my case only present in Calc, and changing zoom levels have no effect.

(In reply to comment #15)

> ... Bug in my case only
> present in Calc, and changing zoom levels have no effect.

Then this is a different bug: please file it separately.

Update for this bug: it still happens with 4.2. up to 4.2.4. I saw it on at least 4 different systems: debian testing amd64, ubuntu/xfce 12.04 i386, ubuntu/gnome classic 12.04 i386, kubuntu 14.04 i386. It is extremely annoying when opening ms-word97etc-doc-documents, because they open always with a zoom level that exhibits the bug. On different systems the zoom levels that show the bug differ, on one system "fit width" works, optimal does not, on another system it is the other way round. On all systems 150% zoom is ok.

Created attachment 105226 [details]
Print screen in view  mode, zoom 160

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 02)

Fedora LXDE.

Libreoffice 4.3.0 Writer is unusable, no matter the zoom setting. I did not have any rendering problem with my previous 3.3 installation.

As stated in another comment changing the preferences is ineffective.
Turning off hardware acceleration on my system:

(.baschrc)
# Turning off hardware acceleration

export LIBGL_ALWAYS_SOFTWARE=1

Slightly improve the screen rendering, but as soon as add comments (Ctrl+Alt+C) in view mode, the screen rendering is totally garbled.

Created attachment 105227 [details]
Print screen in view  mode, zoom 100

Correction: in Print Layout (not in view mode)

Created attachment 105228 [details]
Print screen in Print Layout mode + comments

(In reply to comment #17)
> Libreoffice 4.3.0 Writer is unusable, no matter the zoom setting. I did not
> have any rendering problem with my previous 3.3 installation.

I agree, 4.3.0 aggravates the problem: with my systems, the 150% zoom that did work always now often fails - it is pretty hard to find a zoom level with correct rendering. Seems full page view is the last resort, but often is hard to read; and forced refresh (minimize-restore) gives a correct view - until you scroll again.

I think the problem is the combination of LibreOffice with certain display drivers, radeon being the most prominent. 3.6 has changed something in addressing the video driver as compared to 3.5, and since then this bug is there, and no one addressing it.

Well I seem to have joined this club with 4.3.1.2. I have no problem with 4.2.6. I use Ubuntu 12.04 with Radeon Graphics. View Full Page works without a problem. The problem shows up with longer documents, a complex page layout, headers, footers multiple fonts. Bypass to use full page whilst scrolling.

The problem is still there with 4.3.2.2 on Ubuntu 12.04

Still there with 4.4.0.0 alpha 1. Can bypass by adjusting the slider at the bottom right. Peter

Created attachment 108904 [details]
Screenshot of document with footer 01

This is my joy to use the new header/footer on 4.3 (4.3.2.2).

Created attachment 108905 [details]
Screenshot of document with footer 02

I don't see this as ever having been confirmed by QA - moving to UNCONFIRMED as REOPENED is incorrect.

@jmadero: what more do need for confirmation?!?

*** Bug 38644 has been marked as a duplicate of this bug. ***

Would agree with this being confirmed and set NEW

This is applicable to Linux systems (mix of GPUs)

OS X on Apple hardware is bug 56932

Other related display repaint on scroll issues, bug 43498 closed for lack of activity, pointing to a gtk3 issue. bug 58510 (for distortion with scrolling a Calc spreadsheet). And a smattering of other variants, bug 38644 probably predates all of them but was never followed up by its OP.

Seems to be a general issue with GPU and LibreOffice's inherited OOo drawing layer repainting.

It would be helpful to get more precise Steps to Reproduce and specific hardware/OS/driver combinations for testing.

Created attachment 110436 [details]
Impress outline window showing the normal window

This problem affects every modules of LibreOffice on my system.
I needed to make a presentation with Impress this morning.
I uploaded a final screenshot of what I experience when I click on the "Outline" tab.
I reloading or scrolling up/down has no effect.

@Pamir Talazan, @nomnex
(In reply to Pamir Talazan from comment #32)
(In reply to nomnex from comment #31)

Please review earlier details of this bug, it is mostly concerned with distortions to the GPUs display of pages being redraw during scrolling at various zoom levels on Linux with various GPUs and drivers.

Not sure there would be any facet of that caused by Java based helpers.

Created attachment 112691 [details]
Scrolling text corruption bug in Windows 7, LibreOffice 4.3.2.2

LibreOffice 4.3.2.2 (happened in earlier 4.x versions also)
CPU: i7 860 2.79Ghz
Graphics: Radeon 7850
OS: Windows 7

Corruption occurs after scrolling via any method. Corruption does not ALWAYS occur, but the document must be closed and re-opened to reset it and try again.

This is not just a Linux bug. I have this bug (or something very similar) in Windows 7.

Specifically I have a long document (41 pages, 151KB) which sometimes displays the scrolling bug. When the issue occurs, the file needs to be closed and opened again and it's then fine. When it happens, text formatting is garbled after scrolling - this includes using the scroller or pressing PgDown, using the mouse wheel etc.

Zooming to anything other than 100% also fixes it (including 110% or 90%). My screen resolution is 1600x1200.

Also see my attachment above.

Same kind of problem here. If you open a Word-document (.doc), change to Web layout and start scrolling the contents of the screen get completely scrambled.

Steps to reproduce:
[1] Open Writer
[2] Open an existing Word-document [.doc]
[3] Change to Web Layout via View / Web Layout
[4] Press [CTRL] and start scrolling by moving the scroll wheel of the mouse.
[5] scrambling occurs.

Pressing ctrl and scrolling changes zoom factor...are you sure those steps are right?

Hmm, @Patrick/#38:

As I reported earlier (#14), on my system this happens only in print layout mode, not web layout mode. And it happens with scrolling, but not with changing the zoom factor. In fact, changing the zoom factor redraws the screen correctly after messing up, this is why it was a workaround in earlier versions, but in recent I did not find any "safe" zoom levels greater than "whole page" that did not expose this bug *when srcolling*. And on my system this only happens with Writer, and not with Calc which I use heavily. And it does not matter which format, it happens with odt, doc and docx.

and  @N/@36+37:
Judging from your screenshot this is a totally different appearance and a totally different bug than this one. This bug repeats horizontal stripes when you scroll, yours has letters shifted sideways. It reminds me of one bug reported for the Mac bug (#56932) - maybe you should report there.

Just for the record: 4.4.0.3 still has this bug (for me: introduced with 3.6.0, not seen up to 3.5.7).

@Stuart Foote/#30:
> It would be helpful to get more precise Steps to Reproduce and specific
> hardware/OS/driver combinations for testing.

This seems only to happen in rare combinations (else we would see a lot more activity here), so I doubt we can reproduce it easily on a developer's machine.
My system consistently exposes this bug, on Ubuntu 12.04 through all updates to LTS-raring kernels&video, after upgrade to 14.04 and still after changing kernel to LTS-utopic (3.16); it happens with and without hardware acceleration: when enabled glxinfo reports:
> OpenGL renderer string: Mesa DRI R200 (RV280 5960) x86/MMX+/3DNow!+/SSE2 TCL DRI2
latest driver is xserver-xorg-video-radeon 1:7.3.0-1ubuntu3.1
Chipset: "ATI Radeon 9250 5960 (AGP)" (ChipID = 0x5960)

*** Bug 84484 has been marked as a duplicate of this bug. ***

While I know most if not all you Ubuntu users will be working with Gnome as your DE, back on 2013-09-06 I filed bug 69011 in which I explain how to induce and reverse corrupted rendering similar, if not identical to this, in KDE.

The TLDR of it is that, within KDE, activating font hinting and sub-pixel rendering at the desktop level completely bollixes LO's ability to correctly render its screens (including the help facility).  Disabling said features entirely mitigates the problem.

This is completely irrespective of the Hardware Acceleration, Anti Aliasing, and Smooth Scrolling settings (as per bug 60537 comment 2) within LO itself, which have no affect on this (mis)behaviour whatsoever.

Not sure how to disable sub-pixel rendering and font hinting in Gnome, but maybe give that a shot.  If anything, it might narrow down whether what I observe on my machines is a bug within just LO or all KDE (LO is the only adversely affected program I've seen to date).

I've confirmed this on three x86 and x86_64 rigs equipped either with nVidia (proprietary and nouveau drivers) or Radeon (FOSS only drivers) running Mageia 4; KDE 4.12.5; with LO up to 4.4.1.2 release.

Hope this helps.

My DE are LXDE & XFCE (Fedora). Both notebooks run a Pentium VI, with an ATI Radeon (so the Nouveau driver). They have respectively 786 MB and 1 GB of RAM. I have just tired John instructions on XFCE. The screen rendering looks like "back in the 80's" and the fonts look terrible, but I can confirm that – so far – the libreoffice modules (Writer, Impress, Draw, and Calc) are not distorted anymore on my system!

The text rendering is still noticeably lagging (or slow) when I scroll UP/Down with the mouse wheel. It's a tad better when I "Page UP/Down" with the keyboard. But scrolling does not break all the windows as it used to be. Great findings John!

How about the other users affected by the same problem?

@nomnex

I'm delighted my discovery has finally (after 2 years) helped someone, and that you've confirmed the issue isn't exclusive to KDE.

In comment 43 you said that after applying the workaround your screen rendering went slow and back to looking like the 80's.  To me that suggests you've completely disabled anti-aliasing and hardware acceleration.  Going that far shouldn't be necessary.  In my experience disabling hinting and sub-pixel rendering is enough to make LO behave itself.

All this should be a bad memory once OpenGL support is properly implemented.  I made some new discoveries over the weekend: see bug 69011, comment 14 for details.  

Cheers.


P.S. I added bug 58358 and bug 69011 to the other's respective "See Also" lists.  If that's what you meant by "merge", disregard my confusion in bug 69011, comment 13.

(In reply to John L. ten Wolde from comment #44)
> @nomnex

<snip>

> In comment 43 you said that after applying the workaround your screen
> rendering went slow and back to looking like the 80's.  To me that suggests
> you've completely disabled anti-aliasing and hardware acceleration.

Good observation John. I could not edit my comment after re-enabling anti-aliasing. Still, font rending without hinting and sub-pixel disabled looks poor on my screen res. 1024 x 768. Hardware acceleration is not supported with my configuration.

> All this should be a bad memory once OpenGL support is properly implemented.

I use OpenGL, but it did not help in the present case. Perhaps, my hardware is too old? By the way, I use LO 4.4.0.3 rpm package directly from the LibreOffice website.

> P.S. I added bug 58358 and bug 69011 to the other's respective "See Also"
> lists.  If that's what you meant by "merge", disregard my confusion in bug
> 69011, comment 13.

Since the issue look similar, wouldn't it better to keep one single bug report, and to mark the others as duplicates?

Some news from my side:

1. Using Gnome, I had some tests with various combinations of hinting and anti-aliasing using gnome-tweak-tool, with mixed results - sometimes this bug was barely reproducible, but then with identical settings it was prevalent all the time.

2. This bug bites me also with the new 5.0.0.5 version

3. I made a new observation: when this bug strikes, and I scroll _very slowly_, I can see:
- screen advances one stripe, old contents is still there where the next content should show up
- with a remarkable delay the new content is drawn
When I scroll faster than the new content is drawn, the old content is repeated over and over
- when I scroll back one step, and then scroll forward very slowly, I often can correct the wrong content.

Looks like following is going on when scrolling:
1. already painted and cached areas are copied to the new location
2. the newly visible area is painted and cached
Whenever a new iteration of this procedure happens before step 2 of the previous step finished, the next 1st step will copy also content and cache of the previous new area even when it hasn't been updated until then, copying the old previous content. It is a kind of cache poisoning, as invalid content still waiting to be newly painted is cached and thus validated.

Created attachment 120288 [details]
render gap windows7 x64 at 50% zoom

While scrolling gaps appear when more than 1 page is displayed (side by side). It doesn't matter what zoom level is picked.

My problem: https://bugs.documentfoundation.org/show_bug.cgi?id=58358#c47
seems to have been resolved in v5.0.3.2

Created attachment 122945 [details]
Text scrolling glitch when using tables

I too have the problem with latest release of LibreOffice when using tables or spreadsheets. It seems to occur with either one line or one word.
Zoom 120% 
Corrected when scrolling past the text and returning.
Text does not render correctly. This bug also appears on both Writer and Calc

I have disabled Hardware acceleration and anti-alisting as suggested in the comments (many thanks) and not yet been able to recreate the bug when disabled.

5.1.0.3
Win10 64-bit

See "Text scrolling glitch when using tables" attachment.

Not reproducible for me with LO 5.1.4.0.0+ built at home under Ubuntu 16.04 x86-64.

Closing as WorksForMe. Please feel free to reopen if it is still reproducible for you with current stable version. In that case, please attach a document with which you reproduce the problem.

Best regards. JBF

If it was that easy to close a bug that bites only a very small minority: just find someone who is not involved to close it worksforme: you could get rid of most of the bugs here in no time ...

btw, still present and unchanged in Libreoffice 5.1.3.2 on Ubuntu 14.04.3 32 bit ...

Hi, I'm trying to reuse an old notebook with the following specs:

- Pentium T3400 (fairly reasonable 64-bit CPU)
- 2 GB RAM
- 14" 1280x800 LCD controlled by a SiS 771/671 chip <-- the problem!

That chip is somewhat of a pain to use in Linux. Originally with Vista, I only found an "official" driver for Win7 at SiS. For Linux/Xorg, there's a driver (sisimedia) by Thomas Winischhofer, which Mageia 5 makes available.

Though only able to play videos at 640x480 maximum, the driver enables satisfactory use of most other kinds of applications at 1280x800. Firefox, Dolphin, Thunar, KPatience, Chromium BSU, Megamario, Okular, Kwin & KDE settings, Xfcewm & Configuration Manager... every program I ran did not present any kind of problem when scrolling (I tried also to vary the zoom). Programs were retested to ensure accuracy in the present report.

In Libreoffice Writer 4.4.7.2 (the version in Mageia 5) I can see the same kind of artifact shown on the previously attached pics. Also, I verified the problems seems to disappear below 55% zoom. The problem shows in Print layout and Web layout likewise.

I confirm Heinz Repp's comment #14 here, too, with regard to the same settings mentioned -- no setting in Libreoffice could improve the situation.

Calc does not present that behavior. On a simple spreadsheet (columns with months' names), at varying zoom scales, text was always perfectly rendered.

BUT:

A workaround I found is disabling acceleration in xorg.conf (Option "NoAccel" "True"). Using that option for this hardware and driver makes the problem go away. I don't know if the same solution will help other kinds of hardware.

Thanks!

(In reply to Renato Miró from comment #53)
> A workaround I found is disabling acceleration in xorg.conf (Option
> "NoAccel" "True"). Using that option for this hardware and driver makes the
> problem go away. I don't know if the same solution will help other kinds of
> hardware.

Hi Renato.  The description of your issue is so similar to mine and others that I'm not convinced your video hardware is at fault.  I'm also using KDE under Mageia 5 (but with LO Fresh 5.1.4) and this issue still persists for me.  As a possibly more satisfactory workaround, I recommend checking to make sure that your sub-pixel rendering is disabled:

KDE System Settings > Application Appearance > Fonts > Use Anti-Aliasing [Configure...]

If it isn't, disable it, then re-enable your hardware acceleration, and see if this improves your user experience.  If it does, you'll likely notice a slight degradation in the appearance of fonts in other apps (notably Firefox), but given the choice between sub-pixel rendering versus hardware acceleration, I'd choose to dump sub-pixels in order to keep hardware acceleration every time.

For a more verbose treatment on all this, see my step-by-step report at Bug 69011.  Note I wrote that report while running Mageia 3 and much of the flakiness KDE was exhibiting at that time has since been ironed out.


Best of luck.


P.S.  I've still got my fingers crossed that when the remaining issues with OpenGL get sorted and we Linux users can actually enable it again -- for examples see Bug 97904 and Bug 99299 -- all this will be just an ugly memory.  In Bug 97904, comment 4, Caolán committed an OpenGL patch to 5.1.2, but I haven't noticed a difference so far.  I'm hoping it works in the 5.2.x branch.

(In reply to John L. ten Wolde from comment #54)
> (In reply to Renato Miró from comment #53)

> Hi Renato.

Hi, John, how do you do?

> The description of your issue is so similar to mine and others

> make sure that your sub-pixel rendering is disabled:
 
> KDE System Settings > Application Appearance > Fonts > Use Anti-Aliasing
> [Configure...]

Sorry, didn't work in my case. I guess this "winmodem"-style video card is way more primitive than whatever hardware you may have. To me, that Thomas guy is starting to look like a hero.
 
> but given the choice between sub-pixel rendering versus hardware
> acceleration, I'd choose to dump sub-pixels in order to keep hardware
> acceleration every time.

I would, too, but this chip only uses EXA ("Option AccelMethod not used" in the X log). I tried to select XAA, but got that message. Besides, frankly, accelerated means glxgears gives 99 fps instead of 81.

> For a more verbose treatment on all this, see my step-by-step report at Bug
> 69011.  Note I wrote that report while running Mageia 3 and much of the
> flakiness KDE was exhibiting at that time has since been ironed out.

I've read it to check whether I did the right steps. Though in my case, KDE is choosing Xrender even when I opt for OpenGL 1.2 -- which means my problems are not really about GL.

> Best of luck.

Likewise, my friend. For your information, I'm using the document "BH3501-IntroductiontoBase.odt" (just search "BH3501 filetype:odt" on Google). Scrolling the first page already clearly creates artifacts.

Off-topic, but perhaps related: I've read elsewhere that "unusual" DPI settings can also lead to problems. Not sure about it, but the theory goes like rescaling 96DPI fonts to, say, 117 DPI could produce truncation errors (because we can't have 0.5 pixel) and thus the recomendation was to use more exact multiples like 96 itself or 120 (=96 x 1.25). Don't know if that makes any difference. Some three years ago I had problems with fonts in Firefox, now I don't. 

> P.S.  I've still got my fingers crossed that when the remaining issues with
> OpenGL get sorted and we Linux users can actually enable it again -- for
> examples see Bug 97904 and Bug 99299 -- all this will be just an ugly
> memory.  In Bug 97904, comment 4, Caolán committed an OpenGL patch to 5.1.2,
> but I haven't noticed a difference so far.  I'm hoping it works in the 5.2.x
> branch.

Not that it helps in your case, but for the record I use Libreoffice a lot with Intel integrated video and old Nvidia Geforce cards (10+ year old!) and can say without any chance of mistake that I have not had any kind of problem before like the present one.

Also, check the OpenGL version which your h/w accepts. I once tried to use OpenGL 2.0 with a board which would only accept 1.2 with disastrous consequences; in the same vein, don't deactivate OpenGL (Mesa) and try to run Libreoffice with that "Use OpenGL..." option activated. It will crash repeatedly at start until you edit a *.xcu file in ~/.config/libreoffice to change it back to false.

IMHO it's possible that it is the case of a bad interaction between the hardware+driver set and some low-level video access by Libreoffice. It's even possible there's no bug in Libreoffice but rather some shortcoming in these more, erm, "exotic" video cards -- which other packages learned to avoid but which is still not worked around by LO.

Thanks, again!

Hello everyone... I would like some new facts which happened on the hardware I mentioned in comment #53 (a notebook with SiS 771/671 graphics and using the sisimedia X driver).

Just to summarize, in Mageia 5 everything went fine and only Libreoffice had a problem exactly as shown in the clear attachments by Mr. Heinz Repp.

Now, I'm testing the Mageia 6 stable 1 release and surprisingly found that things work the opposite way: after installing, display corruption occurs e.g. in a terminal while using midnight commander -- but not in Libreoffice, which works perfectly. This is the Mageia bug:

          https://bugs.mageia.org/show_bug.cgi?id=19620

The workaround is the same: disabling acceleration in xorg.conf (and not in Libreoffice!).

Between Mageia 5 and 6 something weird happened and I'm inclined to believe it is related to X11 and its drivers -- and not to Libreoffice.

It seems to me that Libreoffice is not at fault in the present case.

Created attachment 129887 [details]
LO 5.2.4.2 help browser still borked with sub-pixel rendering enabled.


It's a Christmas Miracle!  Well, sort of...

I just installed 5.2.4.2 from Fresh and amazingly I am finally able to activate sub-pixel rendering without it corrupting Writer's editing window.  Unfortunately, as you can see from the attached screen shot, it still does corrupt the Help Browser. In any case this is a huge step forward!

Happy Holidays everyone.


P.S.  I neglected to respond to Renato in comment 55 and comment 56, but after doing some testing of my own, he is absolutely correct: on Linux, disabling hardware acceleration in xorg.conf (awful a choice as that is to have to make) completely prevents this bug from manifesting itself.

Sigh...

Disregard my excitement in comment 57.  It was premature and I was wrong.  Upon opening a document more than a couple of pages long I see that the corruption in the editing window persists.  All is the same as it has been for so long.  I've disabled sub-pixel rendering again.  :-(

I'm sorry it didn't work for you, John. In my case, I did some tests and verified that other Xorg options (ShadowFB off, BackingStore off, Silkenmouse off) didn't help -- while NoAccel effectively prevented problems in Libreoffice and in other situations, both when using Xfce and KDE4 (on Mageia 5).

Perhaps this is a complex bug which results from problems both in the X11 drivers and Libreoffice's inability to deal with these driver problems.

BTW, what hardware & driver combination are you using (please describe the machines on which the bug occurs).

If you're using an Nvidia card, have you tried Nouveau? Have you tried the VESA or fbdev driver (if any of these works in your hardware)

It's also worth noting that maybe, in spite of symptoms being similar, solutions might not be the same on different hardware. I'm attaching an image of the bug happening over here with anti-aliasing turned off, which apparently would prevent the bug on your hardware.

To test a big document, I used "WG42-WriterGuideLO.odt", available online with 480+ pages and ~14MB. With option NoAccel, no problem happened over here.

I don't know much, really, but these problems are usually associated with bad screen handling: either two things are writing to the video memory, a buffer is updated with the wrong content, the screen is refreshed from the buffer and partially overwrites what Libreoffice has already written, or Libreoffice writes to the wrong buffer, or maybe there's even a speed problem. In my case using acceleration seemingly causes that sort of mistakes in screen updating. Maybe if we knew details about your hardware (particularly the video card brand and model), we could search for similar problems on that hardware.

Good luck!

PS: If you really have to live without font anti-aliasing, try to use a big resolution. At 1920x1080 I feel less need to use sub-pixel rendering.

Created attachment 130268 [details]
Problem with anti-aliasing and subpixel rendering off

Just an informational bump to report that there is no improvement whatsoever in 5.3.0.3.

Also, I ran across these two meta bugs tracking OpenGL issues: bug 94691 (OS agnostic) and bug 97937 (Linux specific). Just in case our bug is tangentially related to the ongoing OpenGL shenanigans I thought I'd link them here.

--
(In reply to Renato Miró from comment #59)
> I'm sorry it didn't work for you, John.
Hi Renato.  I think you misunderstood my retraction in comment #58.  I jumped to erroneous conclusions about the bug being fixed, not about your workaround being ineffective.  As far as I've seen, it (your workaround) always does the job.  I apologise for putting you up to all that typing.  Cheers.

Well, I would not rush to blame drivers and video cards. It's more likely that LO is to blame. I have the same problem on win 10 laptop, 4K screen, with nvidia 4GB, bought just a few days ago. When I scroll down through text, the lines get meshed up, cut, distorted, the whole gamut of things that can go wrong appears.

I use 5.3.2.2 LO.

All x86 hardware (x86 and x86-64) has this issue.

This bug still affects version 5.3.4.2

Several days ago I upgraded to Mageia 6 which switched me from KDE4 to Plasma 5 and, while I was at it, I also pulled in LibreOffice Fresh 5.4.0.3.  *Finally* I can use LO with full sub-pixel rendering enabled.  I no longer see corruption in Writer or the Help browser (I haven't checked the other components yet).  Whether this is because of a fix in LO or it's because of the switch to Plasma 5, I have no idea.

It's been a long 4 to 5 years of living with this headache, but for the moment it WORKSFORME.  Hopefully the fix was in LO and the issue is resolved for the rest of you as well.  Maybe we can finally put this bug to bed.

OpenGL is still a colossal train wreck though...

Hi John,

(In reply to John L. ten Wolde from comment #65)
> Several days ago I upgraded to Mageia 6 which switched me from KDE4 to
> Plasma 5 and, while I was at it, I also pulled in LibreOffice Fresh 5.4.0.3.
> *Finally* I can use LO with full sub-pixel rendering enabled.  I no longer
> see corruption in Writer or the Help browser (I haven't checked the other
> components yet).  Whether this is because of a fix in LO or it's because of
> the switch to Plasma 5, I have no idea.
> 
> It's been a long 4 to 5 years of living with this headache, but for the
> moment it WORKSFORME.  Hopefully the fix was in LO and the issue is resolved


Thanks for reporting and sorry that it annoyed you such a long time. As you can notice from the comments/QA-volunteers, it didn't seem a general issue, easy to reproduce, rather something due to specific circumstance(s) XYZ.. ;)

> for the rest of you as well.  Maybe we can finally put this bug to bed.
> 
> OpenGL is still a colossal train wreck though...

:)  
Thanks again & enjoy LibreOffice!
Cor

This problem is still present in the latest versions. I verified this today in versions 6.1.5.2 and 6.2.2.1, which I have installed. Fortunately, I still have version 6.0.7.3 installed, and it does NOT have this problem. Scrolling through text in Writer is also noticeably slower in versions 6.1.5.2 and 6.2.2.1, in comparison to version 6.0.7.3. Apparently this is a regression, which prevents me (and I assume others also) from enjoying the features in the newer releases.

I am running Ubuntu 18.10, Mate Edition, but with the Cinnamon Desktop.

(In reply to David Burleigh from comment #68)
> This problem is still present in the latest versions. I verified this today
> in versions 6.1.5.2 and 6.2.2.1, which I have installed. Fortunately, I
> still have version 6.0.7.3 installed, and it does NOT have this problem.
> Scrolling through text in Writer is also noticeably slower in versions
> 6.1.5.2 and 6.2.2.1, in comparison to version 6.0.7.3. Apparently this is a
> regression, which prevents me (and I assume others also) from enjoying the
> features in the newer releases.
> 
> I am running Ubuntu 18.10, Mate Edition, but with the Cinnamon Desktop.

Dear David Burleigh,
This bug has been in RESOLVED WORKSFORME status for more than 6 months.
If the issue is still reproducible with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/, please report a new issue in https://bugs.documentfoundation.org/enter_bug.cgi providing, if     needed, the steps and documents to reproduce it.
Thanks for your understanding and collaboration.
Closing as RESOLVED WORKSFORME