Created attachment 100099 [details] Useful for viewing the bug Steps to reproduce: 1. With any spreadsheet with lots of data on rows and files, it happens. Take an example with the file attached. 2. Open the file attached. 3. Scroll down with the mouse (or with the arrow keys). Current behavior: - VERY slow rendering. - Random parts of spreadsheets shows on the down side when scrolling. Imagine it with colours... - That happens too if you scroll up. The random parts of spreadsheets appears upside. Expected behavior: - Normal rendering. - No artifacts / random parts of spreadsheets during the scrolling. More info: - That doesn't happen on Libreoffice 4.1 branch. It's brand new of the 4.2 version. - I've a NVIDIA computer, AMD computer and Intel computer. In the three PCs Calc is affected by this bug.
Sorry, I see that the attachment must be text plain... The file is : http://mpan.pl/pub/archreport-39474-sample.ods
Confirmed in Linux Mint in 4.2.4 and 4.3 beta. It scrolls fine in 3.3.0, 3.6.7, and 4.0.6. It starts slowing down alittle in 4.1.6, but isnt as bad as 4.2.4 and above.
I can't reproduce it in any of the following versions: - Version: 4.2.3.3 Build ID: 420m0 - Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e - Version: 4.4.0.0.alpha0+ Build ID: 6b4c596b01039324cfe78f38c4e3ffb9080bcd34 in Ubuntu 14.04 LTS x86_64 running on Virtualbox.
My PC Specs: Linux Mint 32-bit, Dual Core Intel Pentium 4 3.20GHz with 4GB RAM
Well i did a screencast so people can see how it is for me. You will see in the 4.3 test that scrolling isnt smooth, lots of cells are not being redrawn fast enough when scrolling up and down, resulting in cell content appearing to be still in its previous locations. https://drive.google.com/file/d/0B6qJrVIa0SAlOVBaRDNaQUFOV2M/edit?usp=sharing This reminds me of the slow performance mentioned in bug 78254, which i tested, and that one also mentions the deterioration in 4.2 and above when compared to 4.1.
I'm not sure if this information will be useful: On Debian Testing GNOME, XFCE and LXDE desktops, the bug appears. On Debian Testing KDE not. Today, on Testing we have the 4.2.5.2 release. Same thing: on GNOME, XFCE and LXDE the bug appears. On KDE desktop not... I don't know if I should change the version on the bug report...
Just confirmed in on Ubuntu 14.04 with LibO 4.2.3, though on this tested pc, the lag wasnt as bad as its has a faster processor and was run on 64-bit.
21be8eddb95a12408b74f43d3effb9dc9821e99e is the first bad commit commit 21be8eddb95a12408b74f43d3effb9dc9821e99e Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Fri Oct 18 04:23:31 2013 +0000 source-hash-bcc51fb2ebdf77a1cc089857775fd742085b45b6 commit bcc51fb2ebdf77a1cc089857775fd742085b45b6 Author: Noel Power <noel.power@suse.com> AuthorDate: Thu Aug 29 17:15:33 2013 +0100 Commit: Noel Power <noel.power@suse.com> CommitDate: Thu Aug 29 21:42:05 2013 +0100 add support for in-place style preview selecting a style in the styles dialog ( without double clicking ) will apply the style to the currently selected cell(s) You can with the keys navigate to other styles and they in turn will also be applied. Preview will end when you click back onto the document. *FIXME* - the styles dialog isn't really suitable for previewing, a new dialog ( possibly in the toolbar ) might be nicer ( see Excel ) *FIXME* - when there is a multiple selection the highlight colour (applied as a transparent overlay) is most annoying ( and is mixed with any background colour applied if part of a style ) see ( ScGridWindow::UpdateSelectionOverlay() ) However my puny attempts to make the selection use a transparent colour made all the borders of the selected cells dissappear. I guess maybe a box/border around each selected cell ( or group of cells ) would also work but I didn't try that Change-Id: I0950e79085ffb75f60ee961835665df0c230172f :100644 100644 8fab1fdadbd439deb64a4f714bff2f9526411bf3 835fff1805e8dc39bfd7bd7d6cc135aeb3b3c181 M autogen.log :100644 100644 e26e2b8c270cd824114091d167dae2b14e9dc10c fd07dfa379a8bec1d8edcff2f495ba575f1ab416 M ccache.log :100644 100644 116323b70a7bf25f0a07e0534405af3833e28d4d 23a5b8b538220c7ff6416642ade815a875518df9 M commitmsg :100644 100644 eb158bbc099f5743ae6479d555bb6b76ba00ac72 4210b173f74258372c2837a9bef262ab02db4653 M dev-install.log :100644 100644 80d286b683b673d2a90e0ea3d07b47a728e6a0de 54e4b02174c8ab14e3f07c184475efc9604ca4ce M make.log :040000 040000 b98420146279e9da46dc037c56e55b12c36101e1 8e95f2d5dd47c365d05e430f6f5a6cd8656e4488 M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574 # bad: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b git bisect bad 4850941efe43ae800be5c76e1102ab80ac2c085d # skip: [a043626b542eb8314218d7439534dce2fc325304] source-hash-9379a922c07df3cdb7d567cc88dfaaa39ead3681 git bisect skip a043626b542eb8314218d7439534dce2fc325304 # skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6 # bad: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930 git bisect bad c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31 # bad: [1d4980621741d3050a5fe61b247c157d769988f2] source-hash-89d01a7d8028ddb765e02c116d202a2435894217 git bisect bad 1d4980621741d3050a5fe61b247c157d769988f2 # good: [ba096f438393091574da98fe7b8e6b05182a8971] source-hash-8499e78ca03c792f4fa2650e02b519094ba0baa8 git bisect good ba096f438393091574da98fe7b8e6b05182a8971 # good: [e75547cbd2d9d480ba13e119a8df8098c9d3a0a3] source-hash-69f686774cfeb803fdd63ed1ef07ff70550930de git bisect good e75547cbd2d9d480ba13e119a8df8098c9d3a0a3 # good: [bac2489ff3b644bd046102e379bff5a6c6c469d9] source-hash-621c1e491e56db5416da1c763aaff862e8ede67a git bisect good bac2489ff3b644bd046102e379bff5a6c6c469d9 # good: [0b24b35122b1aec8721035679954b10f82a23540] source-hash-cdab3d619ca0389d4c14e3b50fb66bbadcf5c52f git bisect good 0b24b35122b1aec8721035679954b10f82a23540 # bad: [21be8eddb95a12408b74f43d3effb9dc9821e99e] source-hash-bcc51fb2ebdf77a1cc089857775fd742085b45b6 git bisect bad 21be8eddb95a12408b74f43d3effb9dc9821e99e # good: [f47efc54c1f3916052ffda455e5ea179f6aa400a] source-hash-511354504cfc2c8f002752775d5bb336b01bd6ab git bisect good f47efc54c1f3916052ffda455e5ea179f6aa400a # first bad commit: [21be8eddb95a12408b74f43d3effb9dc9821e99e] source-hash-bcc51fb2ebdf77a1cc089857775fd742085b45b6
I can reproduce the original issue from the bibisect repository. However, on current releases: 4.3.5.2 isn't visually perfect while scrolling, but catches up immediately after. 4.4.0.2 looks perfect to me and the performance seems acceptable. Closing this as RESOLVED WORKSFORME
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]