Problem description: Can't move smoothly between cells using keyboard arrows and input data (no more than 8 letters or numbers per cell). Simple spreadheet acts as on very slow computer. The same spreadsheet works fine under MS Excel 2000. I did reinstallation of LibreOffice recently and remove user profile folder due to problems with copy/paste simple data into Calc. Steps to reproduce: 1. Moving between cells using keyboard's arrows. or 2. Entering simple numbers and move to next cell using Enter key Current behavior: Very slow move of active cell. Expected behavior: Smooth move of active cell on spreadsheet using keyboard. System: Win XP Pro PL ThinkPad X300 Intel Core2 Duo L7100 @1,2GHz RAM 2GB LibreOffice memory settings: number of steps: 30 cache 256MB memory per object 16MB remove after 10 min number of objects 32 Operating System: Windows XP Version: 4.0.2.2 release
Did you try 3.6.6.2 release?
I don't remember. Probably yes, because last OpenOffice I used was 3.4.4-1. Shall I downgrade LibreOffice version?
I have the same problem. Yes, I have tried older versions.
hm, well seems quite serious, getting an expert involved. CC'ing two in fact :) Michael and/or Cedric - hoping one of you can help us get the info needed to actually triage this. We have two users confirming the behavior but not really enough information to confirm - any advice? One thing: can one of you try turning off hardware acceleration? Tools -> Options -> View -> Uncheck "Use hardware acceleration" if that doesn't work also try unticking "Use Anti-Aliasing"
My system configuration: Celeron 2.66Ghz / 1 GB RAM / XPSP3 The issues are: 1. When I scroll through a file using a continuous press of the arrow key, the cursor does not move the way it should. It gets stuck on filled cells and seems to jumps cells. But I can see it's actually moving as the row/column number bar is highlighted by the movement. The run through blank cells is okay. 2. After working for a while on any file, even the simplest one, the data-entry mode cannot keep up with the speed of typing. I have to wait for the characters I type to appear one by one. 3. I find the same issue in Oo 3.4.1 as well but works just fine in MSO. 4. This happens with every sheet I open or create; As suggested by Joel, I tried turning off hardware acceleration; it didn't work; I also tried turning off Anti-Aliasing; it still does not work. Some interesting observations: a) I set the memory to 30Steps/256MB/16MB/00:10hh:mm/32Objects as suggested in the Oo forum. It works for Oo but not for Libre. b) The issue comes up only if some data is entered. A saved file opened and scrolled is okay as long as there is no change.
The H/W acceleration check-box almost certainly does nothing in this case, that would only affect the choice of canvas: VCL or Cairo, neither of which is used in calc IIRC [ it's all raw VCL ]. > 4. This happens with every sheet I open or create; If this occurs with a blank sheet; then I suspect it is some annoying priority issue whereby the repaint is of a lower priority than the keystroke; I imagine another (arrow key) stroke comes in before we can re-render the new location - which further defers re-rendering. On the other hand, we would have to be doing something ~amazingly slow on arrow-key-press in order to take any significant time; unless your typematic rate is set to some bazillion repeats per second ;-) of course, it is entirely possible that we do do something amazingly slow but ... Naturally I can't reproduce the problem here; can you confirm you see this for empty sheets ? [ if not, having some rough outline of the type of data (if you can't attach the sheet) that you have in the current sheet would be great ]. Thanks !
(In reply to comment #6) > The H/W acceleration check-box almost certainly does nothing in this case, > that would only affect the choice of canvas: VCL or Cairo, neither of which > is used in calc IIRC [ it's all raw VCL ]. > > > 4. This happens with every sheet I open or create; > > If this occurs with a blank sheet; then I suspect it is some annoying > priority issue whereby the repaint is of a lower priority than the > keystroke; I imagine another (arrow key) stroke comes in before we can > re-render the new location - which further defers re-rendering. > > On the other hand, we would have to be doing something ~amazingly slow on > arrow-key-press in order to take any significant time; unless your typematic > rate is set to some bazillion repeats per second ;-) of course, it is > entirely possible that we do do something amazingly slow but ... > > Naturally I can't reproduce the problem here; can you confirm you see this > for empty sheets ? [ if not, having some rough outline of the type of data > (if you can't attach the sheet) that you have in the current sheet would be > great ]. > > Thanks ! Michael, Thank you for the prompt response! I checked the typematic rate and found it's okay; in any case even if this had not been set as desired, you might wish to think as to why it should be not be an issue in MS Office. Also, please consider the below points that I posted in my earlier comment: 3. I find the same issue in Oo 3.4.1 as well but works just fine in MSO. a) I set the memory to 30Steps/256MB/16MB/00:10hh:mm/32Objects as suggested in the Oo forum. This works for Oo but not for Libre. 4. This happens with every sheet I open or create; b) The issue comes up only if some data is entered. A saved file opened and scrolled is okay as long as there is no change. Can think of anything else that might be causing this?
I have had an issued, with 4.0, I do not is was the same, with a specific large file (external links csv+ods, arrays, pivot tables, not conditional format), it was going slower to enter data and calculate with elapsed time from open it. But seems solved in: Win7x64Ultimate Version 4.0.3.1 (Build ID: a67943cd4d125208f4ea7fa29439551825cfb39)
> you might wish to think as to why it should be not be an issue in MS Office. That is a totally different piece of software designed in a completely different way, so no useful technical benefit from such a comparison at the code level here. > a) I set the memory to 30Steps/256MB/16MB/00:10hh:mm/32Objects > as suggested in the Oo forum. This works for Oo but not for Libre. That is just superstition, those settings are unlikely to do anything. > b) The issue comes up only if some data is entered. A saved file > opened and scrolled is okay as long as there is no change. Can you attach a sample sheet with some sample data in it that reproduces this for you ? "some data" is not so helpful :-) can you also be specific about what ranges you scroll between ? > I checked the typematic rate and found it's okay; in any case even if this > had not been set as desired, you might wish to think as to why it should > be not be an issue in MS Office. MS Office as I've said is a totally different code-base; I don't dispute that you found a bug and that we should fix it; what I'm trying to do is make it repeatable on my machine :-) Thanks.
I think that strange behavior of Calc is connected with system clipboard. My problems with very slow work of Calc starts together with Ctl+C/Ctrl+V problems. It was described here as well as Libreoffice freezing or problems with copy/paste function.
> I think that strange behavior of Calc is connected with system clipboard. My > problems with very slow work of Calc starts together with Ctl+C/Ctrl+V > problems. It was described here as well as Libreoffice freezing or problems > with copy/paste function. (In reply to comment #10) Please can you attach a sample file?, at least to discard as source of the problem. Have you tried to see if there is any difference with the portable version?: http://www.libreoffice.org/download
Created attachment 79787 [details] Example spreadsheet
I did upload sample spreadsheet. I was unable to enter data (using keyboard) smoothly between Q11 and Q42 for instance. It doesn't depend on filetype or filesize in my case. I'll try portable version. I'm working using old Excel 2000 now.
I can not reproduce with sample file, in 3.6.6, 4.0.3 or beta 4.1
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
removed myself from cc
LibreOffice 4.2 has substantially re-written spreadsheet core, as such lets assume this is fixed there :-)
*** Bug 74719 has been marked as a duplicate of this bug. ***