[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Jekyll Wu adap...@gmail.com changed: What|Removed |Added CC||adap...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 qxldd...@aon.at changed: What|Removed |Added CC||qxldd...@aon.at --- Comment #51 from qxlddwas aon at 2011-08-13 19:54:23 --- Description of okular behavior I see with Normal setting: - Scrolling in PDF files makes the X server grow very rapidly - This make the X server start swapping - This results in Okular displaying the file very slowly Description of okular behavior I see with Low memory setting: - Every page takes around 300 ms to be rendered Ultimately, for me the second setting (Low memory) results in a much faster scrolling experience for PDF documents. To me it seems that with modern processor performance, the tradeoff between using more memory or more cpu power clearly favors the latter. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Kevin Funk k...@electrostorm.net changed: What|Removed |Added CC||k...@electrostorm.net -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Dominik Haumann dh...@gmx.de changed: What|Removed |Added CC||dh...@gmx.de --- Comment #45 from Dominik Haumann dhdev gmx de 2011-07-05 14:38:37 --- I can reproduce this with a ps file, but not with a pdf file. In ps files, I can increase the memory to 1.5 GB RAM withing 1 second fast scrolling. The same file as pdf has only very few memory usage. Albert, Pino, are there differences with respect to memory allocations here? -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #46 from Albert Astals Cid tsdgeos terra es 2011-07-05 17:50:12 --- @Dominik: Should not be, so you are either seeing a bug in gs, in the libspectre code or in the okular-spectre code -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #47 from Benoît Jacob jacob benoit 1 gmail com 2011-07-05 18:00:58 --- May I suggest something that's working nicely for Firefox: we have a special about:memory page reporting on memory usage; it used to be of little use, but if you try current Nightly, it's been greatly expanded as a lot of code has been instrumented to report on all kinds of allocations. https://bugzilla.mozilla.org/show_bug.cgi?id=633653 It works great for stuff like the X pixmaps being discussed here, because while the system is not good at telling you where the allocations come from, the code sure knows what it's allocating so it's a good place to just instrument. Having this about:memory page allows us to get much more useful bug reports from users. So maybe you could do the same in KDE, e.g. a menu entry under Help or a button in Help-About. Good luck :) -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 aux...@yahoo.com changed: What|Removed |Added CC||aux...@yahoo.com --- Comment #48 from auxsvr yahoo com 2011-07-05 18:06:14 --- I've never seen high memory use using radeon, however using remote X apps with an intel card, I managed to hang the machine hard twice after browsing some PDF files. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #49 from auxsvr yahoo com 2011-07-05 18:24:54 --- Regarding comment 47, it is easy to find pixmap use with Ctrl-Esc Detailed memory information, or xrestop. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #50 from Dominik Haumann dhdev gmx de 2011-07-05 21:39:28 --- Using ctrl+esc Detailed memory Information: Pixmap was max 50 MB. Private goes up 1 GB, (only) when scrolling too fast. I'm able to reproduce it everytime. When running it in massif, it's too slow to show this issue... So unfortunately, massif doesn't help here. Other ideas? -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Zane Tu zan...@gmail.com changed: What|Removed |Added CC||zan...@gmail.com -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 rauchwo...@gmx.net changed: What|Removed |Added CC||rauchwo...@gmx.net -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Thomas bargh...@gmx.com changed: What|Removed |Added CC||bargh...@gmx.com --- Comment #41 from Thomas barghest gmx com 2010-11-13 15:44:08 --- Same config as #39 here and the same experiences. What makes it even worse is that using okular constantly fills my swap partition although there is plenty of free RAM. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #42 from Thomas barghest gmx com 2010-11-13 15:46:29 --- (In reply to comment #40) I'm in favor of blaming the drivers for that given comments from #37 and my own experience (works for me) Can those that have the problem see if running okular with --graphicssystem raster in the command line helps? This doesn't help here. Swap is filled up with this option, too. In addition: With our without this option memory isn't set free after closing okular. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #40 from Albert Astals Cid tsdgeos terra es 2010-11-11 09:50:13 --- I'm in favor of blaming the drivers for that given comments from #37 and my own experience (works for me) Can those that have the problem see if running okular with --graphicssystem raster in the command line helps? -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Andrew M quantumpha...@gmail.com changed: What|Removed |Added CC||quantumpha...@gmail.com --- Comment #39 from Andrew M quantumphazor gmail com 2010-11-11 06:03:56 --- Another Arch 64 user with Nvidia 260.19.12, Qt 4.7.1 Xorg-server 1.9.2-1 KDE 4.5.3 X takes up around 60 MB on login and will usually bloat to around 180 MB if I open a couple PDFs in Okular. Unfortunately it doesn't deflate much at all when I close Okular. Right now it was just 168 MB. I opened up a datasheet for the ATMega32 and page up/down through the whole thing on Overview mode and X bloats to 414 MB. Closing it brought it down to 156 MB. Okular's memory option is at Low. As you scroll up and down it increases memory consumption almost like it has forgotten that it already had pixmaps stored in X and is adding redundant ones. I'm in favour of the compile time option mentioned in #35 if posible and let the distros decide. Else a hidden option that can be put in the okularrc config file. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #36 from Pasi Rehtonen prehto81 gmail com 2010-09-02 11:47:48 --- I have been doing some digging and managed to get Firefox not to store pixmaps in X11, and removed comic strip plasmoid because it seemed to store those pixmaps in X11 too. So now when I open two okular sessions and scroll through over 600 page pdfs one after another and then close them, there's a little lag before the X11 RES goes back to normal (from 1500mb to 89mb (was 56mb before the test) but still a far cry from 1500mb :) but still it does free 'em. This when using the 'Normal' memory usage setting :) in okular. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Waldo Cancino wcanc...@gmail.com changed: What|Removed |Added CC||wcanc...@gmail.com --- Comment #37 from Waldo Cancino wcancino gmail com 2010-09-02 13:30:26 --- This problem happens to me only using proprietary fglrx driver. No high memory consumption with oss radeon. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #38 from Pasi Rehtonen prehto81 gmail com 2010-09-02 20:18:44 --- Sorry forgot to mention my specs: Arch 64-bit, Qt 4.6.3, Xorg-server 1.81.902, KDE 4.5.1, Nvidia binary blob 256.53 -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Kai Kasurinen kai.kasuri...@uninea.fi changed: What|Removed |Added CC||kai.kasuri...@uninea.fi -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #34 from Fest fest in gmail com 2010-03-30 18:01:12 --- MemoryLevel option Low draining memory too. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Szymon Stefanek pra...@kvirc.net changed: What|Removed |Added CC||pra...@kvirc.net --- Comment #33 from Szymon Stefanek pragma kvirc net 2010-03-26 16:05:16 --- +1 vote for making the MemoryLevel option Low by default :) -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Fest fest...@gmail.com changed: What|Removed |Added CC||fest...@gmail.com --- Comment #20 from Fest fest in gmail com 2010-03-17 11:30:24 --- Gentoo amd64, KDE 4.4.1, Xorg-server 1.7.5. Left yesterday Okular open. For a night X memory consumption grown from 50 to 800 Mb. Closing Okular freed 50 Mb from X, so something like 700 Mb of leaked memory. Nice. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #21 from Albert Astals Cid tsdgeos terra es 2010-03-17 12:05:05 --- And the evidence that Okular is the one at fault is where? Because i've run valgrind over and over and never could find any memory leak. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #22 from Fest fest in gmail com 2010-03-17 12:19:49 --- (In reply to comment #21) And the evidence that Okular is the one at fault is where? Because i've run valgrind over and over and never could find any memory leak. Xrestop is good enough ? Before closing okular, it showed that most memory amount was used by okular. Can you tell me what to do with valgrind, and i'll give output. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #23 from Albert Astals Cid tsdgeos terra es 2010-03-17 12:45:36 --- xrestop will be of use if you can prove that okular memory usage raises while doing nothing with it. for valgrind it's easy, do valgrind --leak-check=full okular and then look at the figures it gives at the end. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #24 from Fest fest in gmail com 2010-03-17 13:09:34 --- I didn't tell that okular memory usage raises while doing nothing with it. I told that okular used X for caching(?) 700 mb, and after closing okular memory (700 mb) is not free. And xrestop shows that X already not storing okular pixmaps. Ok. I'm installing valgrind. I'll post here if it show something. Although as i understood from discussion above, it's problem with X freeing pixmaps. I'm not programmer, i have no idea who's mistake is that: bug in X or wrong usage of X cache by okular. All i know okular usage is draining memory. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #25 from Oscar Fuentes ofv wanadoo es 2010-03-17 13:13:34 --- (In reply to comment #21) And the evidence that Okular is the one at fault is where? Because i've run valgrind over and over and never could find any memory leak. How is valgrind relevant here? This bug is not about a memory leak in okular, but about okular allocating hundreds of MBs of pixmaps on the X server. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #26 from Albert Astals Cid tsdgeos terra es 2010-03-17 16:33:00 --- #25 to me it's fairly obvious, each time you allocate a X pixmap in the server side you get a handle in your process, if you don't free the local handle there is a local leak, if you do not leak it, it means you freed the X pixmap too. But as it seems you have a better idea i'm open to your suggestions. And well, if the bug is about okular allocating X memory we can close it altogether because that is not a bug at all. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #27 from Fest fest in gmail com 2010-03-17 16:53:39 --- (In reply to comment #26) And well, if the bug is about okular allocating X memory we can close it altogether because that is not a bug at all. Yeah. It's not bug, it's feature. Just need to add to changelog: now okular not only open pdf, but also help you to get rid out of your memory. Seriously, even if okular doing everything right, at the end we have memory leak. It's bug. If guys from X don't want to patch, so okular team need to create workaround . Cause right now after using okular people have to restart. If it's not bug for you guys, i don't know what can be. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #28 from Albert Astals Cid tsdgeos terra es 2010-03-17 17:43:55 --- #27 Being sarcastic is not going to make people help you so spare ourselves that comments everyone will be happier. It being a bug i agree, but we still have to find whose fault it is before we can fix it. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #29 from Oscar Fuentes ofv wanadoo es 2010-03-17 19:45:25 --- (In reply to comment #26) #25 to me it's fairly obvious, each time you allocate a X pixmap in the server side you get a handle in your process, if you don't free the local handle there is a local leak, if you do not leak it, it means you freed the X pixmap too. But as it seems you have a better idea i'm open to your suggestions. And well, if the bug is about okular allocating X memory we can close it altogether because that is not a bug at all. This was discussed on the past. The X server (all X servers I know) are not so smart managing resources that they can cope with the usage pattern okular does. Even if okular frees all handles, the X server sometimes does not give back to the OS all the allocated memory, and then fragmentation can prevent reusing that memory on another okular session. This is not a problem with most X applications, because the amount of allocated X resources is low (compared with okular). As mentioned on the past too, I did some informal benchmarks and perceived no speed difference on page rendering after changing Okular's memory usage setting, nor I perceive differences with other pdf viewers (xpdf, for instance). What I observe is performance degradation when X ends having gigabytes of allocated memory after heavy use of okular with the normal memory usage setting. This is a critical issue when the X server is a machine wiht 1 GB of RAM and the X client has 8 GB: after browsing a few hundred pages the X server starts paginating and finally crashes due to lack of memory. So, it is not a bug on okular itself, but a QoI (quality of implementation) issue. The X server is not as smart is we would like it to be; okular is abusing the X server when it allocates hundreds of MBs of pixmaps; sometimes this usage pattern ends on serious performance degradation or crashes. So, why don't you set the default setting to low memory usage? You claimed on the past that the current setting was chosen due to the performance improvement that it provides. My experience shows that there is no such improvement. Perhaps you can show a case that justifies the huge memory usage? -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #30 from Pino Toscano pino kde org 2010-03-17 19:52:54 --- (In reply to comment #29) As mentioned on the past too, I did some informal benchmarks and perceived no speed difference on page rendering after changing Okular's memory usage setting, nor I perceive differences with other pdf viewers (xpdf, for instance). Your personal benchmarks are not our personal benchmarks nor other people's benchmarks. This is a critical issue when the X server is a machine wiht 1 GB of RAM and the X client has 8 GB: after browsing a few hundred pages the X server starts paginating and finally crashes due to lack of memory. This is another issue, unrelated to this one. Please keep it separate. So, why don't you set the default setting to low memory usage? You claimed on the past that the current setting was chosen due to the performance improvement that it provides. My experience shows that there is no such improvement. See first phrase above. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #31 from Oscar Fuentes ofv wanadoo es 2010-03-17 20:23:04 --- (In reply to comment #30) (In reply to comment #29) As mentioned on the past too, I did some informal benchmarks and perceived no speed difference on page rendering after changing Okular's memory usage setting, nor I perceive differences with other pdf viewers (xpdf, for instance). Your personal benchmarks are not our personal benchmarks nor other people's benchmarks. Thanks for making this a constructive discussion. :-/ This is a critical issue when the X server is a machine wiht 1 GB of RAM and the X client has 8 GB: after browsing a few hundred pages the X server starts paginating and finally crashes due to lack of memory. This is another issue, unrelated to this one. Please keep it separate. Well, if you don't see the relation, I give up. It is obvious that you are too proud of the genial idea of using the X server as a cache for Okular and are not willing to admit that it has some serious drawbacks. As far as I'm concerned, do with this bug report whatever you please. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #32 from Pino Toscano pino kde org 2010-03-17 20:53:27 --- (In reply to comment #31) (In reply to comment #30) (In reply to comment #29) As mentioned on the past too, I did some informal benchmarks and perceived no speed difference on page rendering after changing Okular's memory usage setting, nor I perceive differences with other pdf viewers (xpdf, for instance). Your personal benchmarks are not our personal benchmarks nor other people's benchmarks. Thanks for making this a constructive discussion. :-/ Right, because claiming I did some generic benchmarks so change the behaviour is constructive? This is a critical issue when the X server is a machine wiht 1 GB of RAM and the X client has 8 GB: after browsing a few hundred pages the X server starts paginating and finally crashes due to lack of memory. This is another issue, unrelated to this one. Please keep it separate. Well, if you don't see the relation, I give up. Right, I don't see the relation. The issue you mentioned could be fixed even still with Okular using X. It is obvious that you are too proud of the genial idea of using the X server as a cache for Okular and are not willing to admit that it has some serious drawbacks. Don't be ridicolous and put words in our mouths or ideas in our minds which are *not* ours. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Iago López Galeiras iag...@gmail.com changed: What|Removed |Added CC||iag...@gmail.com -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Salvatore tores...@gmail.com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #19 from Salvatore toresoft gmail com 2009-11-15 23:03:27 --- *** This bug has been confirmed by popular vote. *** -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Pino Toscano p...@kde.org changed: What|Removed |Added CC||jacob.benoi...@gmail.com --- Comment #18 from Pino Toscano pino kde org 2009-10-06 16:52:48 --- *** Bug 209591 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Albert Astals Cid tsdg...@terra.es changed: What|Removed |Added CC||mies...@zabrze.zigzag.pl --- Comment #17 from Albert Astals Cid tsdgeos terra es 2009-08-27 00:49:08 --- *** Bug 193675 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Sergei Danilov sergeidani...@gmail.com changed: What|Removed |Added CC||sergeidani...@gmail.com --- Comment #16 from Sergei Danilov sergeidanilov gmail com 2009-08-10 20:38:21 --- Are there any activity in this issue? I can confirn that okular still uses makes X to use 2GB of memory.And this memory does not become free after closing okular. it's happen on okular 0.9 in kde4.3 and xorg-server-1.6.3 -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 Mark Whitis whi...@freelabs.com changed: What|Removed |Added CC||whi...@freelabs.com --- Comment #14 from Mark Whitis whitis freelabs com 2009-05-25 06:50:12 --- This is not true, Okular does not share the pixmaps of an open document with any other open document. Furthermore, all the (still cached) pixmaps of a document are freed when that document is closed. The behavior of okular is not consistent with either of your assertions. - X server memory increases by 160MB whether you are running one instance of okular or multiple instances. If it did not share, it would grow by 160MB * number of instances. Unless you send a signal to other instances to reduce memory usage before allocating more. - In some circumstances, those pixmaps clearly are not freed. Perhaps okular tries but there are some circumstances where it is omitted.It is more likely that an application forgets to request that the memory is freed than that the X server fails to actually release it without reporting an error. This is common due to exceptions, assert(), more than one exit(), signals, alternate code paths, etc. What makes you so sure they are ALWAYS freed on exit? Which alternate code paths have you taken into account? Have you actually checked that the algorithm for freeing doesn't have bugs? If your assertions are actually true, then you need to provide an alternate explaination as to why the application behaves in the manner which suggests that they are false. You need to explain: - Why memory usage is capped across instances - How okular allocates its X server side pixmaps. What functions does it call, from which functions in which source files. - When and how okular deallocates its pixmaps. What functions does it call, from which functions in which source files. - What the limits are for number of cached pixmaps or total size of cached pixmaps. - Why memory isn't freed when the application exits. Something a little more concrete than just saying it is an X server bug. At least try to narrow the scope a little. Why is it that your memory isn't freed on exit when other application's server memory seems to be. What is unusual about your use of pixmaps compared to other apps. Do you know of any other apps that use pixmaps in a similar fashion that we can try? This applies specifically to the pixmaps used to store the pages. The amount of memory used seems to be more consistent with rendered pages than icons, etc. And it applies specifically to the pixmaps stored on the server, not on the client. The shared pixmaps hypothesis at least explains the observed phenomenon. Your denial explains nothing. 160MB as a trigger point for garbage collection (with total X memory not being released until then) doesn't seem to be consistent with the fact that once a leak has occurred, X server size continues to grow. Note that evince doesn't seem to have this problem. Give me something specific to go on and I will see if I can get a chance to look at the source. But I am not going to dig for hours just to find out where your application uses the pixmaps. Gotta go. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #15 from Mark Whitis whitis freelabs com 2009-05-25 08:29:17 --- I can certainly appreciate that X pixmap storage on the server could significantly improve performance in many cases.Indeed, okular seemed a bit faster than evince at first, which was largely why a switched.But in the long range memory consumption ultimately causes it, and the rest of the system, to be slower. This would not be the case on a system with ample ram. And the sharing pixmap cache feature, if it actually exists, or an equivalent mechanism with the same effect would be a very good thing in terms of keeping the ram cache reasonable by caching just the document the user is currently paging through. And I care about the performance because I skim documents at very high speed to find what is relevant. Often as fast as the viewer can rasterize the pages. I regularly use huge documents, often many at the same time. Albert: having a (non-hidden) setting to disable pixmap cache on the server could help, in the situations it is needed for.You would simply reuse one or two pixmaps to render either the visible area or the page or two that occupies it. Since only one or two pages would be cached on the server, each instance would use little memory there.If you have 10 instances, you only have 10 or 20 pages stored on the server (still a lot if you use 24bit mode) If that pixmap doesn't get freed, it takes a lot longer for the system to become unstable. You reuse those pixmaps. But this ends up being very close to just setting cache_size=2, if the cache is made of non-sharable pixmaps. I.E. the degeneration case of the cache would more or less do what you would do if you weren't caching. The real minimum X server memory usage case is when you bitblt the bottom portion of the top page and the top portion of the bottom page (assuming a typical case where part of two pages is visable) from a client side pixmap directly to the framebuffer and scroll by using a bitblt to move the memory up (or down) and then a small bitblt to fill in the missing piece.Things get more complicated, though, when part of the window is obscured. And applications sometimes have subtle errors in the update code. Or you can bitblt into the back buffer, then let X copy to the window. Easier because you don't have to worry about obscuring windows (which may even move on you) in either the draw or the scroll operations. But it may be easier, and ultimately more beneficial, to carefully check for bugs in the cache handling than to write new code which could result in the old set of bugs plus a new set. The statement that okular reduces its cache use based on available system memory might explain why the usage caps at 160MB on my machine. Yet free memory is a nebulous concept on a system which uses virtual memory and fills any unused memory with disk buffers. And there is the timing of exactly when this reduction of cache occurs. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #7 from Mark Whitis whitis freelabs com 2009-05-24 19:36:06 --- The situation is much worse than described in this bug report. - X server resident usage climbs to 500MB and virtual memory usage to about 1.3MB on my system. - The X server memory is NOT consistently freed when okular exits. This results in serious thrashing. This appears to be related to okular sharing its pixmap cache among separate okular instances, such that the total memory used by all okular instances is capped at 160MB (until things go wrong) using some sort of X server shared memory. Given that okular appears to share pixmaps between instances, this does not appear to be just an X server issue. Shared memory mechanisms tend to have semantics that allow resource consumption to persist after a process exits. This is an X bug AND an okular bug. Okular performance is set to normal. Ironically, the resource consumption appears to be related to an attempt to limit resource consumption across instances. If you weren't sharing pixmaps, running multiple instances of okular would result in huge consumption but it would be consistently released when all instances were closed. More details here (in the many comments by me at the end): https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/98783 ii okular 4:4.2.2-0ubunt document viewer for KDE 4 Distributor ID:Ubuntu Description:Ubuntu 9.04 Release:9.04 Codename:jaunty -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #9 from Oscar Fuentes ofv wanadoo es 2009-05-24 22:11:38 --- (In reply to comment #8) (In reply to comment #7) - The X server memory is NOT consistently freed when okular exits. This is an Xorg bug. It is a QoI (qualitiy of implementation) issue on the X server, not necessarily a bug. Nevertheless, it is affecting okular users. Other pdf/djvu viewers are not affected by this problem. This diminishes the value of okular compared against those other viewers. The problem is very serious when you are using okular on a remote X server with low memory while okular runs on a machine with lots of RAM: my case when reading docs on a 1 GB X server with okular running on a 8 MB machine. Eventually, the X server starts swapping and becomes very slow. Which lead us to the crux of the issue: okular developers explained to me that the agressive usage of X server pixmaps is geared towards fast perfomance showing pages. After months using okular with the Low memory setting, I've never experienced slowness. Actually, either with the Low memory setting or with the Normal setting it feels as fast as xpdf, for instance, which does not use the pixmap trick at all. This experience includes remote X sessions over slow wifi networks. So, unless someone can justify the superiority of the pixmap approach on terms of improved reading experience (not just raw displayed-pages-per-minute, we are talking about displaying a static image for reading) I humbly suggest to use the Low memory setting as the default or, better, do not use the pixmap trick at all. The memory used by the X server grows with the Low memory setting too, although much less than the Normal setting, where is no rare to see the X server's memory reaching gigabyte levels after some days of light usage. You can argue that it is an Xorg problem (it really is an Xorg problem that you are storing 1 GB of pixmaps on the X server?) but okular users will perceive it as a okular problem. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #11 from Oscar Fuentes ofv wanadoo es 2009-05-25 00:49:53 --- (In reply to comment #10) No arguing at all, if we free the pixmaps and that memory is not freed, it's not *our* bug, so put the strain on people causing the problem, not on us. OSes, libraries, services, all have bugs. If a bug on a third-party piece of software is causing problems to the users of my application, and I cannot directly fix it, I'm interested on implementing a workaround. Not doing so is bad for my users. OTOH, putting hundreds of megabytes of pixmaps on the X server looks like abusing it. We can say that okular is the most memory hungry document viewer out there (at least on Normal memory setting). The fact that the memory is used by the X server is irrelevant: you can cause a huge memory consumption by just advancing page by page on a large document. It's true that the X server may not return the memory to the OS, but it's true too that at some point an instance of okular may be using more than 500 MB of memory (I've seen this). This is not right by any means. Hence my request for setting the Low memory setting as the default one, or throwing out the pixmap usage. Of course your experience of using remote X sessions over slow wifi networks. is not comparable at all with people running a local X server, for those people using pixmaps is visibly faster. The fact is that they are two totally different use cases and probably one can't do a program that will make both kind of users happy, I'm both kind of users. I'm trying to say that, right now, I've not found a circunstance where okular is faster than other document viewers. Faster enough to notice so that it makes a difference when looking at the document, not when just seeing how the screen flashes while the pages change. people running local X servers want eye candy, speed at all costs, etc. People running remote/shared X servers want the less use of resources possible. I don't really see us changing this as it works fine for most of our users (you'll agree that people using remote X sessions over slow wifi networks. is not a majority) Most of my okular usage is on a local machine, so there is no need to paint me as a corner case. OTOH, I recall that on irc you precisely explained that pixmaps are useful for limiting bandwith usage, as once a page is on the X server, viewing it again would not cause an image transfer. So now pixmaps are intended for fast local viewing? Well, maybe you can point me to a document which display is annoyingly slow on xpdf or evince and fast enough on okular thanks to the pixmap trick on okular. but i am not sure if *i* (not the okular maintainer) would opose to a clean patch implementing non pixmap usage Last time I offered to create such patch the maintainer answered with a resounding NO. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
https://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #13 from Albert Astals Cid tsdgeos terra es 2009-05-25 01:22:37 --- Okular is not the most memory hungry document viewer out there, at least it's at the same level of kpdf ;-) It's fast for local viewing because to paint anything on X, it must be a X pixmap, if you already have a X pixmap you just have to paint it, if you have something else, you have to create one and then paint it. And creating X pixmaps is not a negligible time. And it's not about page rendering (that is creating the image that represents the page) speed it's about drawing speed (that is putting that image in front of the user), it's different, page rendering speed is going to be the same as that's all done in the CPU it's drawing speed of a rendered page that is much snappier. And probably you got a NO because you weren't attacking the problem from the correct point, if you suggest removing page caching or not using X pixmaps by default obviously you get a no, if you suggest having a hidden setting that disallows the use of non local memory, that would different. But now that i think i'm not sure it makes sense, because once you've disallowed any X pixmap caching even if you don't explicitely use X pixmaps for rendering you are going to use them implicetely because it's the only thing that can be rendered, so you won't gain anything at the end, it'll have the same remote memory usage at the end. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
http://bugs.kde.org/show_bug.cgi?id=177213 Franz Berger fr4nk is a geek gmail com changed: What|Removed |Added CC||fr4nk.is.a.g...@gmail.com --- Comment #6 from Franz Berger fr4nk is a geek gmail com 2009-02-06 14:34:04 --- I can reproduce this bug using KDE 4.2.0 on gentoo amd64. I can easily make X use over 600MiB just by scrolling for a minute or two. Setting Memory Usage to Low seems to help it, though. -- Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
http://bugs.kde.org/show_bug.cgi?id=177213 Pino Toscano pino kde org changed: What|Removed |Added Severity|crash |normal -- Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
http://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #5 from Oscar Fuentes ofv wanadoo es 2008-12-09 18:17:44 --- Asking on the X.org mailing list [1] yield this information: The X server does nothing fancy when resources such as pixmaps are deallocated. Is up to the C library function free() to return memory to the OS. Heap fragmentation can happen, thus preventing free() from returning memory to the OS. So using the X server for caching pages can indeed cause an unbounded growth of the amount of memory asigned to the X server process. [1]: http://thread.gmane.org/gmane.comp.freedesktop.xorg/34751 -- Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
http://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #1 from Albert Astals Cid tsdgeos terra es 2008-12-08 19:52:05 --- Can you attach or send me a large document where you were able to reproduce this problem? -- Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
http://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #2 from Oscar Fuentes ofv wanadoo es 2008-12-08 21:18:50 --- The problem, as it seems, is not restricted to the djvu backend. A large pdf shows it too: Open a large pdf document, such as http://open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2588.pdf Press the PageDown key and keep it pressed. Keep an eye on `top` or other memory reporting tool, looking at the Xorg process. On the Kubuntu machine, the memory skyrockets after reaching around page 500, but the X process already was using 700 MB of RES memory, so maybe some empty buffers were filled before requesting new memory. This high memory usage of X is something I'm investigating and it's the way I found the problem with Okular. I've observed that sometimes not all the memory used by X is freed after Okular closes, so this memory can be a remannt from previous Okular sessions. To make less plausible the hypothesis of a bug on the X server distributed with Kubuntu 8.10, tried another X server: xming 6.9.0.23 running on Windows 2000. Okular was ran on the Kubuntu machine as okular --display ahost:0 thedoc.pdf The memory consumption was evident: starting at 23MB when Okular is executed, it reaches 200 MB after scrolling 70 pages. xpdf, with the same document, does not change the memory used by the X server no matter how much pages are displayed. -- Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
http://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #3 from Pino Toscano pino kde org 2008-12-08 21:42:16 --- The memory consumption was evident: starting at 23MB when Okular is executed, it reaches 200 MB after scrolling 70 pages. Okular keeps a cache of the browser pages, so it is quite obvious the memory grows (especially when your system has much memory available). If you want to reduce the cache used, you can set it in the configuration: Settings - Configure Okular - Performance. Furthermore, Okular frees all the memory used when being closed, even X pixmaps: thus, if your X server has more memory used when closing Okular, then this is an X issue. -- Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 177213] High X server memory consumption
http://bugs.kde.org/show_bug.cgi?id=177213 --- Comment #4 from Albert Astals Cid tsdgeos terra es 2008-12-08 21:50:25 --- We cache the pixmaps but we should never reach level of eating all the memory. Which platform are you using? -- Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
