[okular] [Bug 375211] New: Table Select tool fails on large table
https://bugs.kde.org/show_bug.cgi?id=375211 Bug ID: 375211 Summary: Table Select tool fails on large table Product: okular Version: 0.20.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: okular-devel@kde.org Reporter: mark.whi...@gmail.com Target Milestone: --- Table select tool fails to automatically identify rows and columns on a simple table layout with large amounts of data. http://www.qsl.net/sterling/VA_QSO_Party/2016_VQP/2016_VQP_MetaData.pdf approx 22 columns approx 180 rows per page approx 414 total rows 3 pages This requires over 500 near pixel accurate mouse clicks to convert. This site has similar files for each year. The following file is a bit more difficult as it is missing lines except on the column heads on the first page. okular finds the rows ok but not the columns. http://www.qsl.net/sterling/VA_QSO_Party/2009_VQP/2009_VQP_MetaData.pdf This is the latest version of okular packaged for this long term support release of ubuntu. Qt: 4.8.6 KDE Development Platform: 4.13.3 Okular: 0.19.3 Distributor ID: Ubuntu Description:Ubuntu 14.04.4 LTS Release:14.04 Codename: trusty -- You are receiving this mail because: You are the assignee for the bug.
[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
