Calligra-Words begins to experience severe / crippling slowdown upon creating or loading a document that exceed 60 pages in size (such as the one provided which was created in Calligra-Words 2.4.0). Noticable lag is detecting during typing and scrolling. Around the size of 100+ pages, this slowdown becomes almost freeze-like with unreasonable delays and at over 200 pages, Calligra-Words becomes unresponsive / hangs. People may think documents this size is unrealistic and not worth supporting but imagine people who'd like to use this for writing a novel or other large work - such a size no longer seems unreasonable. The test computer involved is an Acer AO532h netbook with 2GB RAM, Intel Atom "PineTrails" N450 1.66GHz 64-bit CPU and Intel N10 Family Intergrated Graphics Controller running Mageia 2 Cauldron Beta 2 (kernel-desktop 3.3.1 with KDE 4.8.2. This bug was experienced in Calligra-Words 2.4.0) 64-bit edition. Reproducible: Always Steps to Reproduce: 1. Load the test file enclosed in Calligra-Words or create a document exceeding 60 or more pages in size. For guaranteed results, 200 pages. 2. Attempt to edit or scroll through the document to notice crippling slowdown. Actual Results: Calligra-Words takes between 1 to 2 minutes to reflect any changes made. Calligra-Words sometimes becomes completely unresponsive based on the current length of the file. Expected Results: Calligra-Words should not experience any slowdown or delays in editting and viewing operations as applications such as LibreOffice and IBM Lotus Symphony do not exhibit any symptoms with equally large documents. The test computer involved is an Acer AO532h netbook with 2GB RAM, Intel Atom "PineTrails" N450 1.66GHz 64-bit CPU and Intel N10 Family Intergrated Graphics Controller running Mageia 2 Cauldron Beta 2 (kernel-desktop 3.3.1 with KDE 4.8.2. This bug was experienced in Calligra-Words 2.4.0) 64-bit edition.
Created attachment 70414 [details] Large size document - roughly 180 pages. Bug is observed upon loading or creating a document of this size
Comment on attachment 70414 [details] Large size document - roughly 180 pages. Bug is observed upon loading or creating a document of this size Load file in Calligra-Words and attempt to scroll through and edit the document to observe slowdown.
Will work on this bug in a couple of hours. Thanks for reporting
Ok fine you have a good qt, but did you actually set -DIHAVEPATCHEDQT it doesn't detect it automatically
oops wrong bug i commented on
You wouldn't happen to be able to build from git? I have some changes that might help a lot, but would like to be able to test it before actualy releasing it? I myself have a fast computer so can't really judge it, although I can see it does make a difference., just not if it is enough.
(In reply to comment #6) > You wouldn't happen to be able to build from git? > > I have some changes that might help a lot, but would like to be able to test > it before actualy releasing it? > > I myself have a fast computer so can't really judge it, although I can see > it does make a difference., just not if it is enough. Still getting my Linux feet wet here, if you can walk me through it, I can attempt it (as I am pretty tech savy plus am eager to learn so I can escape from M$ forever) but no promises. I know how to build and install from tarballs (to an extent) - not sure what prerequisites I'd need though. If you're able to send me a patch as an .rpm or something a bit more automated it'd be best.
Also would I need to uninstall the original version to do this or will doing whatever is needed of me simply patch / upgrade the existing version?
Yes, you would need to uninstall any other version and then follow our wiki http://community.kde.org/Calligra/Building And then to test my exact immprovements you would need some further info from me a tweking. However I'll just turn my computer speed down to something comparable to you. Thanks for the offer though. Then try both 2.4 version and the improvements I've made, and see how it performs. I'll get back with a status in a day or two
Downgrading to major, as it only affects large files. I have btw found the reason now and am investigating possible solutions. Note to self: When typing fast the line sometimes become invalid (no big surprise). This in turrns leads rootAreaForPosition to return 0, which means _all_ pages gets marked as dirty and thus layouted even for a trivial small change. So it doesn't matter where in the big document the change is made, as all pages will be layouted :( Possible solution 1: Cache last edited position+rootarea, and just mark that dirty. Caveat being that it may be incorrect (table syndrome). Possible solution 2: Cache the max and min text positions on each root area, but that would mean a very elaborate and error prone updating system. Possible solution 3: walk back to the previous block that has a valid line. Again the problem is the table syndrome which may lead to too little being layouted Possible solution 4: write some sort of iterator test that can tell if a position is on a root area - this might hold some promise
(In reply to comment #10) > I have btw found the reason now and am investigating possible solutions. > > Note to self: When typing fast the line sometimes become invalid Are you saying the bug is generated strictly by typing? If so, then how come it can trigger even upon loading a large document (without typing)? Even scrolling through a document of equal size created whether created from another word processor or not will show symptoms in Words. Also, when creating the test file from within Calligra Words, I only wrote the first three paragraphs followed by copy / pasting all 3 repeatedly for the length of the file. Not sure if any of that info helps.
uhm yes that is what i was saying. Well that and the fact we layout all in one which i'm also fixing. (should improve slow startup time) However scrolling should be fast. Maybe a gfx driver problem ? fyi, how you created the document doesn't matter
(In reply to comment #12) > However scrolling should be fast. Maybe a gfx driver problem ? Perhaps, I have experiences some weird issues with the KDE desktop itself as well with that computer but have disabled all desktop effects to help rule out possible outside interference. The gfx card is an Intel N10 Family Integrated Graphics Controller (Vendor ID: 0x8086, Device ID: 0xa011, Sub vender ID: 0x1025, Sub Device ID: 0x0349) running Module: Card:Intel 810 and later Scrolling is not fast... at all. It's painfully slow with huge delays and choppy movement of the scroll bar. On a sidenote, if it helps you any further, the following error was produced when running Words (still version 2.4 - as I'm still trying to figure out where to find and how to try your modified build) from terminal. words(7161)/koffice (lib kopageapp) KoOdfLoadingContext::KoOdfLoadingContext: could not parse manifest document When attempting to load the test file I created, the following additional errors appeared in Terminal: words(7161)/kotext KoTextLoader::loadBody: unhandled text: "sequence-decls" Enchant dict for "en_US" 0x2b3be80 Enchant dict for "en_US" 0x2b3be80 Enchant dict for "en_US" 0x2b3be80 Enchant dict for "en_US" 0x2b3be80 Enchant dict for "en_US" 0x2b3be80 Enchant dict for "en_US" 0x2b3be80 words(7161)/kdeui (KAction) KActionCollection::setComponentData: this does not work on a KActionCollection containing actions! QFont::setPointSizeF: Point size <= 0 (0.000000), must be greater than 0
Any luck? I can't test on my end given that you never provided me with your fixes (where they're located or how to apply them). If you can send me a link to a tarball of your version Words with your changes, I can try and build it.
It's not ready yet. It's a bit unstable for now, and I have a lot of other things to do as well. But it's already far along and will be in 2.5 for sure
Git commit 37ea9fb488e895da53704c76018b7845364caca3 by C. Boemann. Committed on 07/05/2012 at 18:37. Pushed by boemann into branch 'master'. Do layout too much. On big documents that can disasterous In fact it's annoying we have to layout for this at all. We should store this info in KoTextBlockData, and do our own drawing. It will be both more beautyful and be prepared for visualizing both spelling and grammar and similar. M +1 -1 plugins/textediting/spellcheck/SpellCheck.cpp http://commits.kde.org/calligra/37ea9fb488e895da53704c76018b7845364caca3
Git commit 46e832fdad372a8c56879df4da2c3f4806da00cc by C. Boemann. Committed on 07/05/2012 at 18:37. Pushed by boemann into branch 'calligra/2.4'. Do layout too much. On big documents that can disasterous In fact it's annoying we have to layout for this at all. We should store this info in KoTextBlockData, and do our own drawing. It will be both more beautyful and be prepared for visualizing both spelling and grammar and similar. M +1 -1 plugins/textediting/spellcheck/SpellCheck.cpp http://commits.kde.org/calligra/46e832fdad372a8c56879df4da2c3f4806da00cc
*** Bug 299919 has been marked as a duplicate of this bug. ***
Unfortunately it still not safe to release, so I doubt it will be in 2.5
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported and confirmed, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!