Bug 95320 - Redraw/refresh of document window badly incorrect
Summary: Redraw/refresh of document window badly incorrect
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.2.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-26 02:22 UTC by Luke Kendall
Modified: 2018-01-17 22:44 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Two screesnhots showing the refresh problem (392.71 KB, application/zip)
2015-10-26 02:22 UTC, Luke Kendall
Details
LO consuming 100%CPU and failing to update menus, window content (144.25 KB, image/png)
2016-03-28 13:44 UTC, Maris Nartiss
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kendall 2015-10-26 02:22:52 UTC
Created attachment 119949 [details]
Two screesnhots showing the refresh problem

(I began this bug report thinking the correct Summary line was this:

"Undo of font style change is not displayed correctly "

but realised it was different as I gathered more data.)

Initially, I had changed a word in a sentence from Garamond to Georgia font (both, 9 point) (just to compare the appearance of the two fonts).  I then undid the change: the text was not re-rendered: the Undo appeared to have no effect.  I did Undo a few more times, and realised that although the selection area changed, what was displayed did not match what I knew the changes to be.  I selected the text which I thought was wrongly displayed, and copied and pasted it into a terminal window: the text in Terminal displayed what I believed was written.  When I clicked back into LO, the text redrew correctly (now matching what was in Terminal).

I used Redo and Undo again, and the problem was quite consistent.  I "rolled-up" (shaded?) the LO window, and unrolled it, and that redrew the text correctly, though other parts of the window were drawn incorrectly.
I'll attach a couple of screenshots - it shows the several areas were not redrawn correctly when the window was "unrolled".  The word I was changing font was "smallest", also circled in red.  The large rectangle of gray is where the screen capture window popped up over the LO window.
In fact the problem is actually worse than it appears.  After taking the screenshot, I see that any operation that brings a window over the top of the LO window, messes up the LO window as it does not refresh correctly.
I could drag windows over it, leaving a "smear" of window frames over the LO window.  Currently, the window is just a solid gray with a blinking text cursor: I can click in different places and move the cursor.

Ah!  And the top menus became completely unresponsive again - see bug 95241 - but because it occurred while this awful redraw problem was happening, I finally thought to wonder whether the menus *were* working, but just not being drawn on screen.  So I clicked on the File menu, and clicked where I thought the menu would be, and then the "Save a copy" dialogue appeared.  So I think that bug - 95241 - is not genuine, and that is simply what *appears* to be a lack of response, because the menus are not being *drawn*.

The problem persisted in the two LO documents I had opened, until I exited from LO completely and re-opened both documents: refresh was working correctly once again.

I tried changing the font to Georgia and back again, but this time everything displayed and refreshed correctly.  So I'm not sure what got LO into such a horribly confused (and confusing!) state.

I suspect the redraw/refresh problem grew gradually worse, the longer it went.  I'm pretty sure I would have noticed the terrible problems at the end, if they ad been happening at the beginning.  I'm not 100% sure of that, but I think it likely that the refresh problem got worse over time.

Again, please note that I'm running Workrave, so it's not unusual for it to pop up a panel warning me to take a break, at any moment.  I wonder if the problem occurs when this happens at an inopportune moment for LO.
Comment 1 Buovjaga 2015-10-26 08:53:28 UTC
Do you have this enabled: Tools - Options - View - Use OpenGL for all rendering? Does the problem go away, if you disable it?
Comment 2 Luke Kendall 2015-10-26 09:40:41 UTC
No, Use OpenGL for all rendering is not checked.
Use hardware acceleration is checked, as is Use anti-aliasing.

I'd rather leave HW acceleration on if possible, in case you're about to suggest turning that off.  Thinking ahead, in case you do: if I change that setting if the problem recurs (i.e., while it is happening), will that take effect at that point?  If so, I'm more than happy to try that when it happens again...
Comment 3 Michael Meeks 2015-10-26 12:10:59 UTC
Interesting; what desktop environment are you using ? it is rather unusual in today's world to not have a backing-store for a window - which means we tend to not see any of these issues during normal use. Is this some 'twm' type thing ? =)
Comment 4 Michael Meeks 2015-10-26 12:11:43 UTC
Also - which distro, and which packages ? are you using gtk3 ? if you do:

pkill -9 -f soffice.bin
SAL_USE_VCLPLUGIN=gen soffice --writer

do you get the same result ? =

Thanks !
Comment 5 Luke Kendall 2015-10-26 14:08:01 UTC
I'm using Ubuntu 14.04 with Gnome, but with Unity turned off as far as possible (the classic UI mode instead). A dpkg -l | grep gtk3 | wc reports 64 packages, so I suppose I probably am using gtk3.  I have no idea why it might be running with no backing store.  Please note that LO normally works fine: it is just sometimes, since I started using LO 5.0, that the refresh suddenly breaks, and stays broken (or gets worse) until I exit LO and restart it.  So I don't know LO would suddenly be losing its backing store: it's only LO that it happens to, nothing else.


pkill -9 -f soffice.bin  appeared to kill -9 soffice.  I'm glad I had saved all my files before I tried that.  What was the purpose of asking me to do that?

Anyway, after naively following your request, i carried on and did what you next asked:

SAL_USE_VCLPLUGIN=gen /opt/libreoffice5.0/program/soffice.bin --writer

I'm not sure what result you're expecting, or why starting writer would be similar to what I'd get from killing it.  

Anyway, currently it's warning me:

/home/luke/.config/libreoffice/4/user/backup/WildThing-CS.odt_0.odt does not exist.
And also:
Object not accessible.
The object cannot be accessed due to insufficient user rights

I note that /home/luke/.config/libreoffice/4/user/backup/ is empty.

I got the same error for the 2nd document I had opened, though no errors reported for the 3rd.
For the 1st two documents, it said it recovered the original; the 3rd, was successfully recovered.
That seems strange.  Perhaps it's because the kill -9 left these lock files in my directory:

-rw-rw----  1 luke kendall  5289202 Oct 26 22:12 WildThing-CS.odt
drwxrwxr-x 34 luke kendall    20480 Oct 26 22:12 .
-rw-rw----  1 luke kendall       80 Oct 26 22:12 .~lock.WildThing-CS.odt#
-rw-rw----  1 luke kendall  3034909 Oct 26 22:11 WildThing-Bk1-Dave-delComms-1stHalf.odt
-rw-rw----  1 luke kendall       80 Oct 26 22:11 .~lock.WildThing-Bk1-Dave-delComms-1stHalf.odt#

But the 3rd file, which it said it recovered successfully, also has a lock file in its directory:

-rw-rw----  1 luke kendall        80 Oct 26 23:04 .~lock.tweets.odt#

Of course, after exiting from LO, all lock files are gone.

I rather suspect I've misunderstood what you were trying to get me to do, sorry.
Comment 6 Luke Kendall 2015-10-28 03:32:09 UTC
I don't know if it's relevant, but a couple of days later I noticed this output in the terminal window from which I'd started soffice:

W: Unknown node under /registry/extlang: deprecated
W: Unknown node under /registry/grandfathered: comments
W: Unknown node under /registry/grandfathered: comments
Comment 7 Maris Nartiss 2016-03-28 13:44:28 UTC
Created attachment 123903 [details]
LO consuming 100%CPU and failing to update menus, window content

I think I have been observing the same bug. I do not have a clear idea how to trigger it, but it is related to pasting content and then formatting fonts etc. via right-click menu.

Observed behaviour - LO starts to consume 100% CPU and fails to refresh window content. Resizing window helps a bit, still menus and dialogs come up blank, including right click menu. Text selection is not visible but works. Only way out is to restart LO. As I do not observe similar problems with other Gtk applications, it should be LO bug.

I was trying to get some reasonable backtrace, but it doesn't seem good to me:
#0  0x00007fffaf8d8c8e in gettimeofday ()
#1  0x00007f795b3e957e in tools::Time::GetSystemTicks() () from /opt/libreoffice5.1/program/libmergedlo.so
#2  0x00007f795b871e59 in Scheduler::ProcessTaskScheduling(bool) () from /opt/libreoffice5.1/program/libmergedlo.so
#3  0x00007f795b87f206 in Application::Yield() () from /opt/libreoffice5.1/program/libmergedlo.so
#4  0x00007f795b880d05 in Application::Execute() () from /opt/libreoffice5.1/program/libmergedlo.so
#5  0x00007f795a982d06 in desktop::Desktop::Main() () from /opt/libreoffice5.1/program/libmergedlo.so
#6  0x00007f795b884c09 in ImplSVMain() () from /opt/libreoffice5.1/program/libmergedlo.so
#7  0x00007f795b884c52 in SVMain() () from /opt/libreoffice5.1/program/libmergedlo.so
#8  0x00007f795a9a0302 in soffice_main () from /opt/libreoffice5.1/program/libmergedlo.so
#9  0x000000000040075b in sal_main () at /home/buildslave/source/libo-core/desktop/source/app/main.c:48
#10 main (argc=<optimized out>, argv=<optimized out>) at /home/buildslave/source/libo-core/desktop/source/app/main.c:47

Version: 5.1.1.1
Build ID: c43cb650e9c145b181321ea547d38296db70f36e
CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; 
Locale: lv-LV (lv_LV.utf8)
All "Graphic output" options are disabled (GL: disabled; HW acceleration: disabled; etc.)
Comment 8 Xisco Faulí 2017-08-03 16:24:49 UTC Comment hidden (obsolete)
Comment 9 Maris Nartiss 2018-01-17 20:51:10 UTC Comment hidden (obsolete)
Comment 10 Xisco Faulí 2018-01-17 22:44:23 UTC
Setting to RESOLVED WORKSFORME then. Feel free to reopen it if you reproduce it again