Created attachment 63606 [details] rpg character sheet Version: 2.4-snapshots (using KDE 4.6.5) OS: Linux There is a three or four second delay with ANY input. The doc is somewhat heavy on graphics, but works fine in other major office suites. Reproducible: Always Steps to Reproduce: launch one of my rpg character sheets (I know its geeky, but hey - I like linux too) Actual Results: calligra tables becomes too slow to use Expected Results: work normally OS: Linux (i686) release 2.6.38-11-generic Compiler: gcc
commit c2e4835367d optimizes the background-color code-path which was one of the reasons for the slow down. The remaining reason is the RTree<T>::NonLeafNode::intersectingPairs codepath which is used in CellStorage.cpp for d->fusionStorage->containedPair. We should maybe cache those calls too.
Commit 63d6ce0b15c34 improves the performance while scrolling around the attached document even more. So now it's acceptable (but still not perfect) on my i7.
Running the risk of sounding like a jerk, I thought I had better mention that the document is still too slow to use. I have noticed an improvement, but not to the point where it is usable (no i7s here =]). I delayed on writing this because I was not sure that I was using the current version. As I have just been updated to the RC2, I believe that I am. At any rate, I appreciate the work you have done on this. I am frankly contemplating rewriting the document with calligra because I absolutely love the entire suite. I believe that it would be fine if it was native to calligra (correct me if I am wrong). The equations of course all work correctly, it would simply be a matter of recreating the look (no small task).
Yes, we/me are aware that there still is a huge problem with that particular document. That's why the bugreport is still open and not closed. The reason is that there are *lot* of cells in the visible area. In fact it's so much that our CellView-cache is completely failing cause there are more cell's visible then our CellView-cache caches. Beside the CellView-cache there are some other QCache's which have the same problem what is why the document is so horrible slow. The imho correct solution would be to not create the uctually used cell-style on demand when the CellView is created (and remove it again when the CellView is destroyed cause it falls out of the cache). Instead we should keep all current style's forever and modify them if a cell is modified. Unfortunately that would mean an increase in the mem-usage. We would need to keep 2 cell-style's per cell. There is already logic to proper share the cell-style if neighboor-cells have the same style but imho all of the row-repeat logic is flawed by design cause as soon as the same styles are used in cell's that are not neighboors we do not proper share them. Instead we should do like MSOffice does and use the concept of "shared content/styles/formattings" way more rather then row-/column-repeats but then we cannot cause ODF does only know about repeated and not shared content :-/ To make a long story short; I did not give up on that yet. It's one of my top-priorities but then this days my free time is very very limited so it will take time till I am able to work on that again and present a patch that addresses this common problem.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.