Created attachment 71579 [details] Screenshot broken scrolling I switched from 3.5.7 to 3.6.4 on my Ubuntu 12.04 box with Gnome Classic Desktop and radeon graphics driver for chipset "ATI Radeon 9250 5960 (AGP)" (Xorg.0.log). When opening any ODT document, scrolling destroys the page with vertically repeated stripes, see attached screenshot. Sometimes those stripes overlap, and the origin changes with every scrolling. Writer is totally unusable with this. With 3.5.7, all those documents opened and scrolled flawlessly on the same system.
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.
I confirm this bug on Ubuntu 12.04 64bits Version: 4.3.5.2 Build ID: 430m0(Build:2) Sourced from PPA I suspect JRE because other java based apps have similar glitches.
(In reply to Pamir Talazan from comment #32) > I suspect JRE because other java based apps have similar glitches. Running Freemind and jEdit (both Java apps) are as stable as any other GTK or QT apps on my system. Firefox is also perfectly stable. I also Abiword (a GTK word processor), 100% stable.
@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.
(In reply to Pamir Talazan from comment #32) > I suspect JRE because other java based apps have similar glitches. LibreOffice is not a Java-based app, for the record. It does have Java components, but it’s written in C++. When will this misconception go away
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.