https://bugs.documentfoundation.org/show_bug.cgi?id=142585
--- Comment #8 from Adalbert Hanßen <[email protected]> --- Created attachment 179857 --> https://bugs.documentfoundation.org/attachment.cgi?id=179857&action=edit An example which shows the bug (the text in it describes another bug) For sometime now I've noticed that large parts of my LibreOffice Writer window occasionally flicker. I first noticed this with very large files. However, I had also an example of a one page document (but then the flickering frequency seems to be less than with large files). The flickering occurs when there is at least the Navigator or Style window open next to the actual text box. When flickering happens, it happens more often that keystrokes arrive out of sequence in the editor window. To avoid this, I have to type very slowly. I have indicators on the taskbar that constantly show me the CPU and memory usage. They show me that both are not the cause of the problem. When composing an example for #148755 the flickering became extremely bad when I wrote the last example in it. After I inserted the last image into the table, it became catastrophic. I could hardly continue writing. Then after patiently adding more and more text, it got much better. But the flickering is still there. The concurrency of the processes in LibreOffice might be insufficiently organized. Can this problem be improved by waiting to update the screen items for Styles, Navigator and the items in the Toolbox that control paragraph format, font size, and other formatting properties and the search box at the bottom until a writing pause of more than 1/10 of a second has passed? Could the contents of these screen areas just be calculated for now and not rolled out continuously? Another possibility would be to provide an order for updating the concurrent screen pieces: Always those of the categories first, then lower its priority behind that of the other pieces until those are finished. Of course, the text edit window should always be served immediately. I would even consider it acceptable if the areas other than the actual text edit window would update only during writing pauses, e.g. one or even two seconds after the last keystroke! The actual background work - e.g. searching, which position in the heading hierarchy is currently affected etc., can be done continuously in the background and discarded if necessary, if "dramatic changes" have happened in the editor window, like insert, PageUp, PageDown change of style sheet or at all more than a certain number of keystrokes since the last update of the concurrent screen areas. (For GUI programmers my explanations may sound a bit amateurish: In the second half of the 1980s I solved a similar problem in an 8086 controlled device this way – that one ran completely without operating system - ). -- You are receiving this mail because: You are the assignee for the bug.
