[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 209591] New: Large, persistent X virtual memory usage
https://bugs.kde.org/show_bug.cgi?id=209591 Summary: Large, persistent X virtual memory usage Product: okular Version: unspecified Platform: Compiled Sources OS/Version: Linux Status: NEW Severity: normal Priority: NOR Component: general AssignedTo: okular-devel@kde.org ReportedBy: jacob.benoi...@gmail.com Version:(using Devel) Compiler: gcc 4.4 OS:Linux Installed from:Compiled sources Hi, I am not even sure that the following is a bug, but I thought that I'd report it to you, so you decide. Summary: I ran 'top' and monitored the VIRT column for X. I understand that this is a completely broken way to measure memory usage. However, by just using Okular to view a PDF file at 400% zoom level, I was able to make that number go from 328M to 1500M. At 100% zoom, I still got 750M. This is on a machine with 1G RAM + 1.5G swap. Is is normal that this VIRT column for X would show such a large number as 1500M ? The system did feel a bit slower, but didn't crawl. Quitting Okular resulted in intense swapping for a few seconds. To reproduce: * launch 'top' in a terminal, note the VIRT value for X * wget http://www.jmilne.org/math/CourseNotes/LEC.pdf * okular LEC.pdf * Zoom to 400%. That's not necessary, but makes the problem worse. * Hit next page every time it has finished rendering * Iterate over a few dozen pages * Check back in top the VIRT column for X. I got it as high as 1500M * Quit okular. The system swaps for a few seconds. The X memory usage stays the same. * If you kill X and restart with XPDF instead, the X memory usage doesn't seem to significantly increase. Assuming that this is indeed not wanted behavior, here's some further info: * It's not specific to PDF, I got the same with DVI * At a Zoom level of 100%, I obtained a X (VIRT) memory usage of 750M. At 200% zoom, I got 1100M. * In 'xrestop', the okular pixmap memory usage may climb up to 100-200M sometimes, but not more, and eventually falls back to a low value. So this means that this isn't a pixmap leak, right? -- 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 209592] New: Some random ideas for smoother, faster rendering
https://bugs.kde.org/show_bug.cgi?id=209592 Summary: Some random ideas for smoother, faster rendering Product: okular Version: unspecified Platform: Compiled Sources OS/Version: unspecified Status: NEW Severity: wishlist Priority: NOR Component: general AssignedTo: okular-devel@kde.org ReportedBy: jacob.benoi...@gmail.com Version:(using Devel) Installed from:Compiled sources Hi, Here are 3 directions to explore to make the user experience smoother, especially at high zoom levels. 1) Find out why it's slower than XPDF. The speed in rendering difference becomes more obvious at high zoom levels (try 400%). XPDF uses Poppler-Splash, like Okular, so i'm really puzzled that it is faster! However, I really tried carefully, and I'm sure that it is at least here on my system... I built everything with default options; anyway both XPDF and Okular are using the same poppler. In Callgrind, it does seem that both Okular and XPDF spend most time in Poppler-Splash rendering. - XPDF spends most of its time in Page::displaySlice in xpdf itself. - Okular spends most of its time Page::displaySlice in libpoppler. Just a wild idea: could it be the fact that Okular displays fuzzy previews and it's actually consuming more CPU than expected? 2) At high zoom levels, when adjusting the zoom level, Okular first draws a white page, erasing the previously rendered page, before rendering the actual result. This seems useless, and distracting. This is very strange: I'm at 200% zoom level. I zoom up to 250%. Good: no white page rendered. I zoom up to 300%. Good: no white page rendered. I zoom up to 350%. BAD: WHITE PAGE RENDERED I zoom down to 300%. BAD: WHITE PAGE RENDERED I zoom down to 250%. BAD: WHITE PAGE RENDERED I zoom down to 200%. Good: no white page rendered. 3) A useful cheat to give the user a great speed impression, is that as soon as he has changed the zoom level, you display an instant preview by just scaling the existing image (the currently displayed page). This doesn't take any significant time and has a surprising effect on the user experience. The user is willing to forgive the not-quite-good quality of the preview because he knows it's temporary and he doesn't have time to look at it carefully anyway. That is also useful as it allows to know right away where the text will appear (useful at high zoom level). I implemented that in the Mandelbrot wallpaper plugin, as you can check. The code (very generic actually) is there: http://websvn.kde.org/trunk/KDE/kdeplasma-addons/wallpapers/mandelbrot/mandelbrot.cpp?view=markup See the zoomView() method. If you want, and if you can show me where and how I plug that into Okular, I volunteer to implement that. -- 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 209592] Some random ideas for smoother, faster rendering
https://bugs.kde.org/show_bug.cgi?id=209592 --- Comment #1 from Benoît Jacob jacob benoit 1 gmail com 2009-10-06 04:45:52 --- Note: I did check that poppler (default build options) was built with -O2. -- 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 209592] Some random ideas for smoother, faster rendering
https://bugs.kde.org/show_bug.cgi?id=209592 --- Comment #2 from Benoît Jacob jacob benoit 1 gmail com 2009-10-06 04:48:17 --- Also the sentence both Okular and XPDF spend most time in Poppler-Splash rendering is obviously wrong in view of the information that I gave just below, instead one should say that they both spend most time in displaySlice but * in Okular's case, it's the displaySlice provided by poppler-Splash * in XPDF's case, it has its own displaySlice I am attaching callgrind outputs... -- 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 209592] Some random ideas for smoother, faster rendering
https://bugs.kde.org/show_bug.cgi?id=209592 --- Comment #3 from Benoît Jacob jacob benoit 1 gmail com 2009-10-06 04:52:37 --- Created an attachment (id=37393) -- (http://bugs.kde.org/attachment.cgi?id=37393) Callgrind run on 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 209592] Some random ideas for smoother, faster rendering
https://bugs.kde.org/show_bug.cgi?id=209592 --- Comment #4 from Benoît Jacob jacob benoit 1 gmail com 2009-10-06 04:53:38 --- Created an attachment (id=37394) -- (http://bugs.kde.org/attachment.cgi?id=37394) Callgrind run on xpdf -- 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 209591] Large, persistent X virtual memory usage
https://bugs.kde.org/show_bug.cgi?id=209591 --- Comment #2 from Benoît Jacob jacob benoit 1 gmail com 2009-10-06 14:09:28 --- Sure, I understand. As I said at the bottom, it really seems that Okular _IS_ freeing all the pixmaps that it uses. I was just wondering if Okular did anything wrong, to get X to use as much as 1500M memory. If it's just a X bug, so be it. Feel free to close as invalid. -- 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 209592] Some random ideas for smoother, faster rendering
https://bugs.kde.org/show_bug.cgi?id=209592 --- Comment #6 from Benoît Jacob jacob benoit 1 gmail com 2009-10-06 14:13:11 --- OK, I'm slicing it into 3 wishes/bugs. Feel free to close as... you decide. -- 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 209592] Some random ideas for smoother, faster rendering
https://bugs.kde.org/show_bug.cgi?id=209592 --- Comment #7 from Benoît Jacob jacob benoit 1 gmail com 2009-10-06 14:22:11 --- OK, forget about the performance issue, I'm pretty sure it was subjective now. What happens is that Okular and XPDF have a different notion of 100% Zoom . So what was 100% Zoom in XPDF was actually more like 66% Zoom in Okular. Because of that, I've been comparing Okular at a higher zoom level, i.e. at a disadvantage. Also, at very high zoom levels, XPDF is sluggish when scrolling, which compensates for the greater speed of initial rendering. -- 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 209630] New: White page rendered when zooming
https://bugs.kde.org/show_bug.cgi?id=209630 Summary: White page rendered when zooming Product: okular Version: unspecified Platform: Compiled Sources OS/Version: Linux Status: NEW Severity: normal Priority: NOR Component: general AssignedTo: okular-devel@kde.org ReportedBy: jacob.benoi...@gmail.com Version:(using Devel) OS:Linux Installed from:Compiled sources At high zoom levels, when adjusting the zoom level, Okular first draws a white page, erasing the previously rendered page, before rendering the actual result. This seems useless, and distracting. This is very strange: I'm at 200% zoom level. I zoom up to 250%. Good: no white page rendered. I zoom up to 300%. Good: no white page rendered. I zoom up to 350%. BAD: WHITE PAGE RENDERED I zoom down to 300%. BAD: WHITE PAGE RENDERED I zoom down to 250%. BAD: WHITE PAGE RENDERED I zoom down to 200%. Good: no white page rendered. Just a wild guess, does this per chance happen whenever Okular has to re-allocate a buffer? -- 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 209632] Instant previews by fast-scaling previous rendering
https://bugs.kde.org/show_bug.cgi?id=209632 --- Comment #1 from Benoît Jacob jacob benoit 1 gmail com 2009-10-06 14:32:40 --- I posted points 2) and 3) as issues #209630 and #209632. -- 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 209592] Some random ideas for smoother, faster rendering
https://bugs.kde.org/show_bug.cgi?id=209592 --- Comment #8 from Benoît Jacob jacob benoit 1 gmail com 2009-10-06 14:33:30 --- I posted points 2) and 3) as issues #209630 and #209632. -- 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 209632] New: Instant previews by fast-scaling previous rendering
https://bugs.kde.org/show_bug.cgi?id=209632 Summary: Instant previews by fast-scaling previous rendering Product: okular Version: unspecified Platform: Compiled Sources OS/Version: Linux Status: NEW Severity: wishlist Priority: NOR Component: general AssignedTo: okular-devel@kde.org ReportedBy: jacob.benoi...@gmail.com Version:(using Devel) OS:Linux Installed from:Compiled sources Note: this wish includes a proposal to scratch-my-own-itch if you'll just tell me where to start. A useful cheat to give the user a great speed impression, is that as soon as he has changed the zoom level, you display an instant preview by just fast-scaling the existing image (the currently displayed page). This doesn't take any significant time and has a surprising effect on the user experience. The user is willing to forgive the poor quality of the preview because he knows it's temporary and he doesn't have time to look at it carefully anyway. That is also useful as it allows to know right away where the text will appear (useful at high zoom level). I implemented that in the Mandelbrot wallpaper plugin, as you can check. The code (very generic actually) is there: http://websvn.kde.org/trunk/KDE/kdeplasma-addons/wallpapers/mandelbrot/mandelbrot.cpp?view=markup See the zoomView() method. If you want, and if you can show me where and how I plug that into Okular, I volunteer to implement that. -- 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 209592] Some random ideas for smoother, faster rendering
https://bugs.kde.org/show_bug.cgi?id=209592 --- Comment #10 from Benoît Jacob jacob benoit 1 gmail com 2009-10-06 17:20:47 --- (Also, why is such discussion being done on bugzilla, and not in ML?) Because when I wrote that, I didn't know that it would be as interesting as you suggest in #9, I thought that 2) was a plain simple bug in Okular and 3) was just a usual wishlist item. I didn't realize that Okular was so dependent on X's pixmap memory management. Naively one would think that X's memory management is only an internal thing that doesn't have to affect such visual aspects! So the naive question is this: why not just simply do all the rendering (of the current page / view) in, say, a QImage that X doesn't care about? Here I half expect my question to be stupid because I don't understand X client/server issues and what happens when people do e.g. X-over-a-network, but I'd honestly like to understand :) -- 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 209632] Instant previews by fast-scaling previous rendering
https://bugs.kde.org/show_bug.cgi?id=209632 --- Comment #4 from Benoît Jacob jacob benoit 1 gmail com 2009-10-06 19:44:58 --- I'm a bit puzzled that you say that you're already doing that. If that's the case, then when I click zoom in I should see an instant preview. But in practice, especially at high zoom levels, there can be 1 second between the time when i release the mouse button and the first appearance of any results. Either I'm hitting a bug, or we're not talking about the same thing 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 209632] Instant previews by fast-scaling previous rendering
https://bugs.kde.org/show_bug.cgi?id=209632 --- Comment #5 from Benoît Jacob jacob benoit 1 gmail com 2009-10-06 19:46:34 --- Ah wait, you say We already do that (reuse old pixmap until new one arrives), that I don't question at all. What I'm proposing here is a bit different: not only reuse, but _scale_ the old pixmap (huh. perhaps it'd be more efficient if that was an image instead of a pixmap). -- 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 209680] New: Okular hitting big latency issue in Qt/GLib event loop
https://bugs.kde.org/show_bug.cgi?id=209680
Summary: Okular hitting big latency issue in Qt/GLib event loop
Product: okular
Version: unspecified
Platform: Compiled Sources
OS/Version: Linux
Status: NEW
Severity: normal
Priority: NOR
Component: general
AssignedTo: okular-devel@kde.org
ReportedBy: jacob.benoi...@gmail.com
Version:(using Devel)
Compiler: GCC 4.4
OS:Linux
Installed from:Compiled sources
When you click Zoom In in the toolbar, you'd expect PageView::slotZoomIn() to
be called instantly.
To check, edit okular/ui/pageview.cpp and edit slotZoomIn to look like this,
void PageView::slotZoomIn()
{
cout slotZoomIn endl;
updateZoom( ZoomIn );
}
Now open any PDF document (doesn't seem doc-specific, but didn't try with
non-PDF).
Zoom to 150%.
Now hit Zoom In in the toolbar and check the console output. There's a
noticeable delay until slotZoomIn gets printed in the console.
This gets worse as the zoom factor increases, HOWEVER when the zoom factor is
big enough to trigger the blank white page rendered effect (see
https://bugs.kde.org/show_bug.cgi?id=209630), then suddenly the latency
disappears and slotZoomIn is called instantly!
During the latency, notice that the Qt UI is frozen. Indeed, with Oxygen style,
the glow on the Zoom In toolbar button stays glowing during this latency, it
doesn't get back to normal instantly as it should.
This is on openSUSE 11.2. Albert was able to confirm the latency on his
machine.
This doesn't seem to be affected by setting QT_NO_GLIB=1.
In a debugger, all I can see is normal event loop business with a lot of mutex
locking going around.
--
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 209592] Some random ideas for smoother, faster rendering
https://bugs.kde.org/show_bug.cgi?id=209592 --- Comment #12 from Benoît Jacob jacob benoit 1 gmail com 2009-10-06 22:48:06 --- Final comment on the performance issue, what I was experiencing was what is now described here: https://bugs.kde.org/show_bug.cgi?id=209680 -- 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 209632] Instant previews by fast-scaling previous rendering
https://bugs.kde.org/show_bug.cgi?id=209632 Benoît Jacob jacob.benoi...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #8 from Benoît Jacob jacob benoit 1 gmail com 2009-10-06 22:52:21 --- OK, Indeed you did this instant previews already! But the problem is that they are not actually instant because there's this big latency before the slotZoomIn() is even called, see this other new bug: https://bugs.kde.org/show_bug.cgi?id=209680 Anyway, closing this one as invalid. -- 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 177011] Rendering large PNG fails when zoom = 84%
http://bugs.kde.org/show_bug.cgi?id=177011 --- Comment #5 from Benoît Jacob jacob benoit 1 gmail com 2008-12-06 04:12:41 --- ok ok that's your call :) but in any case: if okular claims to be able to open image files, and it turns out that it can't open all of them at any zoom level, then user.isConfused(). So at least, a user-visible error message, or something like that. I then thought that, seeing this message, the next thing that the user would do, would be to open the same file with the default image viewer. So I thought, why not just allow him to do it in 1 click from the error msg. But that's just my 2 cents :) -- 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 177011] Rendering large PNG fails when zoom = 84%
http://bugs.kde.org/show_bug.cgi?id=177011 --- Comment #3 from Benoît Jacob jacob benoit 1 gmail com 2008-12-05 21:36:09 --- Heh. Either you support a feature or you don't. If you want to support PNG's but only small enough or at small enough zoom, then you need to do something else than just failing silently. Maybe an error message in the GUI explaining the situation and proposing instead to open the image in the default application for this mimetype (which I suppose would be Gwenview). -- 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
