please upload a sample .odt file with such an embedded .png image where you reproduce the scrolling slowdown.

I wasn't able to reproduce it with LiO 4.3.5.2 under Win8

moreover exactly define what to you do to "embed" the file (from "insert/image" menu of copying and paste it from image editor) and how the scrolling issue happens (using arrowkeys, mousewheel or both).

also consider upgrading to 4.3.5

set status to NEEDINFO. revert it to UNCONFIRMED when you provide these infos

very same problem here with kubuntu 14.04 (32 bit) and libreoffice 4.7.2:

1) Design a diagramm with 2 boxes in libreoffice draw
2) Export it one time 
3) See how crap the default parameters are
*** this bug is already reported****
4) Export it a second time in 600 pixel/cm to have decent resolution
5) Obtain the picture (it is only 600 kB)
6) Import it into a 8 pages long document
7) Crop it because Draw can not easily export only the part you want

8) Buy Windows and Microsoft Office to type the rest of your document, because your system is now unresponsive


Making sample files with a few pages of text, a few pngs etc, is PART OF THE NORMAL TESTING CAMPAIGN that should occur BEFORE EACH RELEASE..

Also I am convinced that such files were already produced by the developer/tester who gave the go for release (were'nt they?)
In case you need it, just ask them  ;) 

Best regards...

Sorry for the long pause in delivery. But I was totally stressed throughout the "holiday" break with writing / checking a publication. Not even time for family. I'll put something up soon. Just give me a few moments since it is from an unpublished (yet) scientific paper.

Could it also be related to some video acceleration problem? (note me if you need HW details) Even typing became extremely slow. I have other parts of the sci.paper (different ODT file) with pictures where nothing unusual happens. Also, if the picture is totally off screen (and thus not rendered) things speed back up to normal.

By the way, opening the images (as PNG) in e.g. kolourpaint or gwenview does not slow down. And even higher res. pictures are scrollable (in kolourpaint). I tried to see if it was jsut related to colour depth but that did not seem to be the case.

I'll try to prepare a file and another one where the issues does not occur (e.g. this PNG vs. the same as JPEG).

And happy new year everyone.

PS: I also updated libreoffice and xorg-server over the last night (Gentoo compiling, you know...), have to see if something changed.

Created attachment 111972 [details]
an example file

first of two example files
Very slow scrolling (and general response e.g. letter typed, > 1 sec, appears on screen) when PNG image is embedded.
"Same" image as JPEG (same resol.) does not lead to visible problems. 

Does Libreoffice (Writer) use other techniques to bring the images to display? Or is the culprit hidden somewhere else? (GPU driver?) 

Always: As soon as the image is off screen scrolling/response is back to normal. 

I also have a second file with different images but bringing up the same problem. (PNG vs. JPEG) Also there are PNG files which do not slow down writer (at least not noticeably), regardless if they are true colour, 8 bit color or greyshade. Sadly I have a lot of these files and must put a lot of them in long documents...

Created attachment 111973 [details]
second example file

second file
scrolling is slow, regardless if used mouse wheel, scrollbar, cursor keys or Pg UP/DN (okay, the latter is faster since it moves in larger steps)

(In reply to renn0xtek9 from comment #2)
> Making sample files with a few pages of text, a few pngs etc, is PART OF THE
> NORMAL TESTING CAMPAIGN that should occur BEFORE EACH RELEASE..
> 
> Also I am convinced that such files were already produced by the
> developer/tester who gave the go for release (were'nt they?)
> In case you need it, just ask them  ;) 

There's always more than enough work to go 'round in QA, and we're quite happy to welcome new volunteers to the team.

If you have some suggestions about how we can improve our processes, please join the QA mailing list and pitch-in with triage and testing:
https://wiki.documentfoundation.org/QA/Mailing_List

We've also got an IRC Channel on Freenode: #libreoffice-qa

Best,
--R

TESTING with LO 4.4.0.2 + Ubuntu 14.04

(In reply to just-me from comment #4)
> first of two example files: attachment 111972 [details]
> Very slow scrolling (and general response e.g. letter typed, > 1 sec,
> appears on screen) when PNG image is embedded.

NOREPRO: Scrolling with mouse/trackpad/etc... is very responsive, and window has no problem keeping up with my touch-typing at all.

> "Same" image as JPEG (same resol.) does not lead to visible problems. 

Do you have a (separate) sample document for that?

Also: Do you have a separate system on which you can test? It would be great to confirm whether you see the problem on a separate machine/OS.

You also mentioned that you have a Windows machine (or dual boot?) that would be a great additional test, especially if it's on the same hardware.

(In reply to just-me from comment #4)
> Created attachment 111972 [details]
> an example file
> 
> first of two example files
> Very slow scrolling (and general response e.g. letter typed, > 1 sec,
> appears on screen) when PNG image is embedded.
> "Same" image as JPEG (same resol.) does not lead to visible problems. 

No repro.

For some reason I get this debug output, when typing stuff:

warn:legacy.tools:5365:12:linguistic/source/gciterator.cxx:165: lcl_SkipWhiteSpaces: illegal arguments

Ubuntu 14.10 64-bit Version: 4.5.0.0.alpha0+
Build ID: 7201fa0dddd7dd0352f69fd2b2b64efcb361ccad
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-01-11_23:28:55

Hello

Sorry for my slow response, but science can be an extreme time hogger.

On the document: Yes, of course. I just recode the image to JPEG and embed the jpeg instead of a PNG in a fresh or the old file and things get better.

On the machine(s): Yes. Of course I should have done that earlier. But it was partially up to 16 h work some days so I couldn't even look straight anymore.

Current is 5350 APU, latest mesa etc. and LibO 4.3.5.2 (compiled one).

I could check this on
* VIA C7 (x86_32, Gentoo, openchrome on CN700) with some binary release of LibO
* AMD Geode LX 800 (x86_32, Gentoo, xf86-video-geode on the Geode GPU) with some binary release of LibO
* AMD E-350 (amd64, Gentoo, free stack on E-350 GPU part) with latest and greatest unstable LibO from portage ("self" compiled but
* AMD Athlon II X4 (amd64, Gentoo, free stack on a HD 5670) with latest and greatest unstable LibO ...
* AMD Athlon II X4  (same box, Windows XP 32 bit, AMD Catalyst blob) binary Windows release of LibO
* some old laptop I got rented (intel P3 or P4 era?) with. XP 32 but iirc also some AMD/ATI mobile GPU and blob driver, binary LibO
* an ancient ARM build of... oh, wait, that was still Openoffice :) on my semi defunct AI Touchbook
* and some ancient boxes and loose mainboards without an OS currently. :)

Honestly I wonder what causes the behaviour. I suspect a mix of GPU driver on the Kabini and LibO doing something different with the PNG to send it to the screen than it does with the JPEG.
Still, other programs display them without visible problems (I might try to install abiword or calligra to check with that)

I found that some binary applications do use emul-linux-x86-xxxxx (these are Gentoo's 32 bit precompiled libs for compatibility in 64 bit systems).
However, they contain libs from Gentoo stable (maybe not as old as Debian stable, but you get the point). Thus e.g. the emul-linux-x86-opengl contains a mesa that is not even aware of the existance of Southern/Sea Islands GPUs used in the Kabini chips. Of course rendering then is a horror. But then, LibreOffice doesn't make use of them (32 bit compat. libs), does it?


If there is any trace or something I should run during runtime while scrolling, just tell me what to do. 


MS-Windows test: Sorry, I only have DOS/W3.11 rotting somewhere, DOS/W9x and XP but the XP is not on the Kabini. I mean, if it was as easy with licensing and installation as a Linux distribution I might just have tossed it on some external HDD/flash and booted it via USB from the same machine. But even then the GPU driver would have been different (among a lot of other things, of course).

I'll test tomorrow on some of the boxes with the problematic files and see what happens.

(In reply to just-me from comment #9)
> If there is any trace or something I should run during runtime while
> scrolling, just tell me what to do. 

Sure! Here are the instructions:
https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace

https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg

Hello

Not yet run the trace but I checked it on 2 other machines already. Okay, yes, it can't confirm this on other machines. 
big Athlon w. HD 5670
MS-W XP 32 LibreOffice binary: no problems, slight slowdown maybe on the large pictures but nothing extraordinary
smae box w. Gentoo + self compiled LibO.: same here, no real slowdown
AMD E-350, Gentoo, self comp.: smooth as a knife through hot butter. 
Will test the C7 and Geode soon but apparently it seems to be machine / video driver related. 
I already feel ashamed for wasting people's time with a bug report. 

Still, there is the PNG / JPEG difference issue on the main machine where I write the papers and PhD. I might suspect that something in the whole chain of LibreOffice and dependencies that might call a 32bit library. Especially I think of something video accel. related, some 32bit lib that is not able to support the relatively new GPU. 

Currently I tried to rebuild the whole system overnight, making it a multilib system (in Gentoo's terms this is multilib without external precompiled libs). So I now already should have e.g. a bleeding edge mesa but also for 32bit programs that call 32bit libraries. The system's transition is not yet complete but I just got everything booted, the browser runs and I'll just dare it and test.

(In reply to just-me from comment #11)
> I already feel ashamed for wasting people's time with a bug report. 

Hey, don't be :) Everyone does that sometimes and we don't really see it as wasted time. Besides, you might still find something related to this report.

You are welcome to join the QA IRC channel to discuss anytime: http://webchat.freenode.net/?channels=libreoffice-qa
.. and we will give a few bugs for you to test when you least expect it ;)

Small update: 
After a lot of (re)compiling I should have > 95% of all libs on my system multilib, supporting 32/64 x86 ABIs. 
A lot of things improved, e.g. Aquaria and Shadowrun Returns Dragonfall went from 0.5 fps to fluid, also some improvements on chemistry drawing programs and I still have to test programs running in WINE. So the performance of a lot of binary things that used 32bit libs before improved a lot.

Sadly, I still see the same problem with LibreOffice. Also the three versions of libpng 1.2.52, 1.5.21 and 1.6.16 support both ABIs now. But no visible improvement. Especially when zoomed in or just at page width (1920x1200 screen or 90° rotated pivot) things still slow down. 

I will do the suggested tracing today and also make the comparison file with the same image as JPEG. Still strange that even similar systems don't show this behaviour.

> .. and we will give a few bugs for you to test when you least expect it ;)
Hehe, yeah, once I am though with this PhD stuff I might actually have the time. For now I just donated some money to the Germany based TDF around xmas for bugfix and maintenance releases. :)

Here is soffice --backtrace output

# cat ./gdbtrace.log 

warning: Currently logging to gdbtrace.log.  Turn the logging off and on to make the new setting effective.
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffec0e7700 (LWP 6223)]
[New Thread 0x7fffddc00700 (LWP 6224)]
[New Thread 0x7fffdd3ff700 (LWP 6225)]
[New Thread 0x7fffd716c700 (LWP 6226)]
[New Thread 0x7fffd5bd1700 (LWP 6227)]
[Thread 0x7fffddc00700 (LWP 6224) exited]
[New Thread 0x7fffddc00700 (LWP 6230)]
[New Thread 0x7fffc92a1700 (LWP 6231)]
[Thread 0x7fffc92a1700 (LWP 6231) exited]
[Thread 0x7fffddc00700 (LWP 6230) exited]
[New Thread 0x7fffddc00700 (LWP 6232)]
[Thread 0x7fffddc00700 (LWP 6232) exited]
[New Thread 0x7fffddc00700 (LWP 6279)]
[Thread 0x7fffddc00700 (LWP 6279) exited]
[New Thread 0x7fffddc00700 (LWP 6281)]
[New Thread 0x7fffc92a1700 (LWP 6282)]
[Thread 0x7fffc92a1700 (LWP 6282) exited]
[Thread 0x7fffddc00700 (LWP 6281) exited]
[New Thread 0x7fffddc00700 (LWP 6324)]
[Thread 0x7fffd5bd1700 (LWP 6227) exited]
[Thread 0x7fffddc00700 (LWP 6324) exited]
[Thread 0x7fffdd3ff700 (LWP 6225) exited]
[Thread 0x7fffd716c700 (LWP 6226) exited]
[Thread 0x7fffec0e7700 (LWP 6223) exited]
[Inferior 1 (process 6218) exited normally]
/usr/lib64/libreoffice/program/gdbtrace:9: Error in sourced command file:
No stack.
Quit

[EOF]

Had to emerge gdb first. Should I enable vDSO options in kernel config?
Not really much output but if that helps...


Also attached 2 odt files (JPEG_one.odt and PNG_one.odt), one with one of the images as JPEG, perfect scrolling, and one with PNG which slows down, especially at zoom so far that also menus (context, file menu etc.) become slow in responsiveness. 

Is there any other way of tracing the behaviour of LibO? I remember that cairo-trace could follow some renderings happening in LibO.


Will emerge and check w. strace next.

Created attachment 112538 [details]
file with the embedded picture in JPEG, no slowdown

Created attachment 112539 [details]
file with the embedded picture in PNG, heavy slowdown

Created attachment 112541 [details]
strace log of the problem

Okay, here is the strace, and it's kind of huge (in my non-developer eyes) and contains unsanitized output.
So just opening a file in question (quite the same as given, just containing more pictures on the following pages), scrolling, setting zoom to 200% (screen wide), now even slower, clicking a context menu, slow response, then closing the file and exiting LibO. 
All that created uncompressed 9 MB of data. Impressive. :)
gzipped for your convenience.

I asked the devs on IRC (#libreoffice-dev @ Freenode) and they said a callgrind could be the best fit, if you are willing to do it.

http://valgrind.org/docs/manual/cl-manual.html

You can use a debug build from here:
http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@46-TDF-dbg/

Note: huge size unpacked.
Can be run from the program subfolder.

Sorry for the long silence but there was paper stress (it always comes in waves), public offices asking me for a lot of money all out of a sudden and also the move to the bugzilla on TDF's own servers so ... 
I remember that I already pulled in Valgrind so I might try to get a trace with this. By the way libreoffice v 4.4.0.3 still seems to show this issue. Not on all images though, or not as nasty as before. I also updated the whole GPU driver stack meanwhile (rolling release).

I'll try to get to that Valgrinde trace asap.

Would this be a duplicate of bug 78529?

Might also be a duplicate of bug 80659.

> bug 78529

Not sure. Seems similar but the reporter wrote about a 750 KB image. Mine are partially less than 30 KB. That was also what I described: some images work, some slow down a bit but some (small, 256 color PNG files and the like) slow down extremely. It seem similar but not necessarily the same.

is issue still present with LibO 4.4.3?

Sorry for the long silence but PhD is hell, and hell+ when you get travel around an then get sick.
I'm on 4.4.3.2 now. 
I still have some slowdown on a (rotated screen) with some embedded scalable vector graphics (inkscape -> svg), I'll try the PNG ones later this week. Also the valgrind report is still to be done, even though I installed valgrind more than a month ago for the purpose. 
Sorry, again, but my workload distracts me very much from anything else. 
I'll note this on my (seemingly endless) to do list ;) and hopefully will get to this at the end of this week.

I am working about daily with LibO and the problem... well, sometimes seems to persist. Or it is not so expressed anymore. I sometimes get a slowdown, so typing / erasing text is delayed and scrolling is jerky. Not as expressed as before. But I noticed it also happens with SVG files, too. (And SVG handling in LibO is also a different topic.)
Generally I'd say things have improved, though I can't really trace if those improvements were inherited from LibO updates or updates in the AMD free driver stack. Or even a libpng update meanwhile. (Besides I am now on 8 GB memory but that shouldn't change things that much, I hope.)

Still, most JPEGs were nice but low bpp colour depth PNGs were strangely a problem, and now some SVGs. Hence my original suspicion that LibO was handling things somehow differently with PNGs and full colour JPEGs.


Valgrind didn't show overly much in the log (without -v there was basically 0 error and no leaks as a result). I can attach a -v log if you want.

I am a bit confused trying to reproduce things. For one it seems to have improved, but sometimes, in the middle of writing I get a few slowdowns here and there. On the other hand these are then kind of uncontrolled environments, means, I also do have a lot of PDFs open in okular (KDE's pdf reader frontend), often a browser with several tabs and music running. The browser and pdfs could be a resource hog so it's a real world test but not suitable for proper reconstruction of bug behaviour. :/
I'll still have a lot of pictures to insert into text and will also - as far as time allows - try to change colour depth, image format and picture size and see if I find something again that show this behaviour again.

In the light of improvements it would be interesting to know if somebody touched LibO's code that handles images / rendering.

And yes,
#78529
#80659
seem to describe a very similar (the same?) problem.

Update: Few problems with PNG noted. But SVG, 2 page-wide images per page causes extreme slowdowns again. The SVGs are b/w (transparent) only, just lines (NMR spectra, looks a bit like a garden fence) and some font text. They do have several vertex points, though (SVG file size 80 ... 200 KB). Scrolling and text editing becomes unbearable often. As soon as these are off screen things become better. Messing with the memory reserved per graphic object settings didn't seem to help (yet). Also closing browsers (might block 2d accel resources??) on other virtual desktops didn't change things.
Any suggestions for possible traces to run during such a work? 
(current LibO 4.4.3.2; will compile 4.4.4.3 probably this night, AMD FOSS driver stack ist quite up to date)

(In reply to just-me from comment #26)
> Update: Few problems with PNG noted. But SVG, 2 page-wide images per page
> causes extreme slowdowns again. 
> ...

if the PNG issue looks solved or considerably improved from the original report I suggest to close this one as RESOLVED WORKSFORME and open a new clean report about the SVG issue (after searching for duplicates in bugzilla)

I confirm this bug, very annoying: I usually make scans of document and use Libre-office to create a PDF from them.. It is not anymore possible cause of that.
I would put high priority to this issue.

Sorry for the long silence but this is a life-suffocating 24/7 job here.

I confirm for LibO 5.0.2.2 - I recently put some thermogravimetric measurements together and especially the 256 colour PNG files (the true colour not so much) result in jerky and slow scrolling / slow response from LibO, even more when zoomed in. As soon as they are off screen scrolling etc. goes back to normal.
The slowdown is not as intense as earlier - the system doesn't feel "frozen" but a slowdown is still noticeable.

Tested on 1200x1920x24bpp (Pivot) screen; mesa 10.6.8 (radeonsi), libdrm 2.4.64, kernel 4.2.3 and xorg-server 1.17.2 with xf86-video-ati 7.5.0 (glamor = 1). The libpng slots are 1.2.52; 1.5.21 and 1.6.18.
The PNG images are of size about 2000 x ~ 1370 pixels, DIN A4 page size in LibO writer.

I also noticed some of that during a scan project similar to the one mentioned above by Adrian Maire (since the public office insisted on a PDF document and said they could not print PNG files (sic!)).

I still have no clue if this is related to an issue directly with LibO or if the culprit lies in the interaction of LibO with the free AMD driver stack.

Is there any change, if you enable/disable Tools - Options - LibreOffice - View - Use OpenGL for all rendering?

(In reply to Beluga from comment #30)
> Is there any change, if you enable/disable Tools - Options - LibreOffice -
> View - Use OpenGL for all rendering?

While I was proofreading a draft for a paper I notied a slowdown again (MSO DOC 97 file, some embedded graphics), and this time it was with libreoffice-bin (the official binary for Linux in Gentoo v4.4.4.2) on an E-350 APU (somewhat different HW but similar driver stack).
Here OpenGL was off, just use HW accel and anti aliasing = 1. (force OpenGL = 0)
The slowdown was quite hard.
Picture was from different authors (cooperative paper) and might haven been embedded als OLE object (they all seem to use MSO...). 

I'll check on that one, also for my own documents on my travel laptop with the E-350 if OpenGL 1 or 0 changes anything.

OpenGL ON / OFF
It did not seem to change much on the Kabini system either. With or without OpenGL enabled, there was slowdown. It seemed slightly slower overall without OpenGL (but that might be a subjective impression). Also typing near such an image was relatively slow.

Kabini setup. Updated LibO recently overnight.
Libreoffice = 5.0.3.2; Accel = 1; OpenGL = 1; edge smoothing = 1; 256 M for graphics mem for LibO; 6 M per object
Mesa = 10.6.8; libdrm = 2.4.64; llvm = 3.6.2; xf86-video-ati = 7.6.1; xorg-server = 1.17.4
CFLAGS="-O2 -mtune=btver2 -march=btver1 -mfpmath=sse -O2 -pipe -mpopcnt -maes -mavx -mmmx -msse -msse2 -msse3 -mssse3 -msse4a -msse4.1 -msse4.2 -mmovbe"
gcc used is x86_64-pc-linux-gnu-4.9.3
USE flags were branding cups dbus jemalloc kde
python_targets python2_7 python3_4 and single_target python2_7
jemalloc is 3.6.0

Still slowdown whenever a larger (pixels x pixles, not necc. content-wise) SVG is on screen. Input / backspace deleting of text noticeably slowed down (delayed reaction). (E.g. delete some text, release backspace key, it still keeps deleting several chars until it stops.)

Scroll the content up or down until the SVG is off screen -> things are back to normal.
I'm writing thesis 12 h / day, so little time for exclusive testing. I'll hit the part with the many PNG files again the next week(s), I'll check there also.

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

Created attachment 128867 [details]
A Screencast of Embedded PNGs slowing the scroll

I've been using the GTK3 version of LibreOffice under Wayland and Xorg for a while (Fedora 25) but I think it doesn't really matter what version I use.

This issue really bugs me because I use a lot of Embedded PNG images in my work (writing user guides for software).

I use touchpad scrolling all the time, so it's like hell to me to scroll through images with it.

In the attached video, I start scrolling by dragging the scrollbar, then I scroll using a mouse scrolling wheel, at the end I use the touchpad 2-finger-scrolling gesture. You'll notice the difference.

The video had been recorded under Wayland, but the same effect happens under X11.

Forgot to add that my laptop has quite good specs with Core i7 Haswell, 16 GBs of RAM, and Intel Iris Pro 5200 128MB DRAM.

I've just tried the same document under KDE4 VCL Backend and it works flawlessly!

It's GTK3 to blame then, maybe GTK2 too (I can't run GTK2 on F25 right now, I don't know why).

Under 5.3 Alpha GTK2, the document work flawlessly too. I couldn't test with GTK3 of this version because testing RPMS are built without GTK3 support, and I need time to build one from source code.

(In reply to Joel Madero from comment #34)
> *** Bug 103076 has been marked as a duplicate of this bug. ***

hence status is NEW

I confirm the slow scroll issue with the attached file on LO 5.2.5 + GTK3 (no issue with GTK2). I tested on Linux Mint 18.1 cinnamon and LO 5.2 PPA. The package "libreoffice-gtk3" is not installed by default and the scrolling is normal. You can toggle the issue on/off by installing/removing this package.

(In reply to bruno.binet from comment #39)
> is normal. You can toggle the issue on/off by installing/removing this
> package.

Note that you can also toggle by running from the command line:
SAL_USE_VCLPLUGIN=gtk libreoffice
SAL_USE_VCLPLUGIN=gtk3 libreoffice
SAL_USE_VCLPLUGIN=gen libreoffice
SAL_USE_VCLPLUGIN=kde4 libreoffice

(In reply to Buovjaga from comment #40)
> (In reply to bruno.binet from comment #39)
> > is normal. You can toggle the issue on/off by installing/removing this
> > package.
> 
> Note that you can also toggle by running from the command line:
> SAL_USE_VCLPLUGIN=gtk libreoffice
> SAL_USE_VCLPLUGIN=gtk3 libreoffice
> SAL_USE_VCLPLUGIN=gen libreoffice
> SAL_USE_VCLPLUGIN=kde4 libreoffice

Yeah, this is what I used to test here.

GTK3 is the only one affected for me.

I wonder if this is now a duplicate of bug #103174 if it is then this should be ok in 5-4 and there's a backport at https://gerrit.libreoffice.org/#/c/37913/ for 5-3

Everything looks ok in

Version: 6.0.0.0.alpha0+
Build ID: 6e3e4cd38b56d432c48cd7217885974e3f0519fd
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

Closing as RESOLVED WORKSFORME

Please re-open, I can reproduce this with the official 6.0.3 build running on Fedora Linux.

Scrolling is extremly laggy, and I experience the same issue with other documents as well.

(In reply to Clemens Eisserer from comment #44)
> Please re-open, I can reproduce this with the official 6.0.3 build running
> on Fedora Linux.
> 
> Scrolling is extremly laggy, and I experience the same issue with other
> documents as well.

You tested with attachment 112539 [details]?

v6.0.1.1

I added pages before and after the image of that document. Scrolling with free mouse wheel spin (a Logitech mouse wheel thing) over the whole document then slowed down for the time when the image was visible. It was quite noticeable, especially when watching the ruler. You see the ruler jumping in my attached screen cast.

Created attachment 139767 [details]
Stuttering scroll action with v.6.0.1.1-Flatpak

// By the way: Is there already a bug for those annoying lines existing, that you also see in the screen cast?

I've experienced the slowdown described in this bug report for many real-world documents and it always made me suffer editing or reading such documents.

I tested this (PNG_one.odt) on two systems (same SSD swapped - so no software differences):

1. Intel Core i5 640M (laptop, 1st gen Intel Core):
Very pronounced stuttering (despite only 1280x800 screen), editing or working with such documenbts is a real pain: https://youtu.be/V8Sr_OHeyyI

2. AMD Kaveri A8-7650k @ 4Ghz: Scrolling is ok even on 1920x1280 screen, although it is slower while the image is visible. Good enough to edit the document.

On both systems tested I see a lot of CPU cycles spent in Xorg in fbBltOne, which is some kind of software fallback. The AMD system seems to be faster when reading VRAM into system memory, so the fallback is less noticeable.
I'll try to investigate further...

(In reply to Buovjaga from comment #45)
> You tested with attachment 112539 [details]?

Ok, it's true that with GTK3, the scrolling is choppy and I see about 10 percentage units more CPU being used.

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: c6a23023150c164a19236139fa413d43006ce21c
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on February 11th 2018

Created attachment 139778 [details]
Callgrind output from master when scrolling with scrollbar, GTK3

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: c6a23023150c164a19236139fa413d43006ce21c
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on February 11th 2018

the hot functions causing this slowness are not running inside the LibreOffice process, but rather inside XOrg - caused by suboptimal drawing commands generated by LibreOffice.

I did some digging, and although I am far from a solution (even a stop-gap one), these are my findings:

- the gtk3 vcl plugin seems to render to a software surface, toms of cycles are wasted scaling the input bitmap over and over in pixman library routines:

SvpSalGraphics::drawAlphaBitmap -> composite_boxes -> general_composite_rect

- the gtk and x11 vcl plugins seem to render to a native surface (which is usually a lot better), however both are doing stupid stuff (extracting the alpha values again and again) - therefore reading back image data from the XServer using XGetImage (no-go for good performance):

drawinglayer::impBufferDevice::paint -> AlphaMask::AlphaMask -> Bitmap::Convert -> ... ->  X11SalBitmap::ImplCreateDIB -> XGetImage

Maybe I can find howto switch gtk3 to using a native XRender surface (these days XRender is rather capable, layered above OpenGL (glamor) anyway) and then work on the second issue...

It's a known issue that rendering of (bigger) images is not fast in LO in all of the backends for many reasons (swap-in / swap-out, separate alpha channels in LO, non-optimized scaling algorithm which don't use SSE or AVX or don't use native surface scaling, ...). 

This particular issue was that gtk3 was rendering even slower and was solved. I would really suggest to open a new bug about this (all the old talk is distracting and non-relevant) and make sure that it really is gtk3 only that has the problem, otherwise there are other bugs that already cover this.

I wonder if we should limit the time how long a solved bug can be reopened.

> This particular issue was that gtk3 was rendering even slower and was solved.

Who did state it was solved?

to the contrary:

Buovjaga 2018-02-11 10:31:38 UTC:
Ok, it's true that with GTK3, the scrolling is choppy and I see about 10 percentage units more CPU being used.

Fair enough, I created bug 115702 for Clemens's investigations

Just as a side-note: My screencast was done in Wayland, so no X11…

Hi,
I too am having this issue. 

If i have inserted a PNG graphic the scrolling is delayed and then is slow, and when typing with the graphic on the screen (in view) there is a 1 to 2 seconds delay before the text appears, and this issue repeats when typing as if the entire text is buffered until you stop typing. 

I check the processes running, and Xorg is at 50%+ CPU usage when this occurs. I have checked multiple times, and this always occurs. 

Does not happen for jpeg graphics inserted. 

I am using Fedora 31, LO 6.3.6.2

Regards,
Shadders.

(In reply to Shadders from comment #58)
> Hi,
> I too am having this issue. 
> 
> If i have inserted a PNG graphic the scrolling is delayed and then is slow,
> and when typing with the graphic on the screen (in view) there is a 1 to 2
> seconds delay before the text appears, and this issue repeats when typing as
> if the entire text is buffered until you stop typing. 
> 
> I check the processes running, and Xorg is at 50%+ CPU usage when this
> occurs. I have checked multiple times, and this always occurs. 
> 
> Does not happen for jpeg graphics inserted. 
> 
> I am using Fedora 31, LO 6.3.6.2

As mentioned in comment 54, please do not attempt to reuse this old report. Open a new one instead. In your case, please test with a master build first https://wiki.documentfoundation.org/Installing_in_parallel/Linux

I was about to comment on this, which is the top Google search result for "libreoffice writer slow image scroll" and thought it would be the go-to place for my eternal slow scrolling issue, but saw that it is recommended to open new issues instead; so if anyone here is interested, I've built a simple test case document for this in the newly created bug #139068.