The issue I was reporting was that it's slow, does that in it of itself not count as a bug?
I can appreciate that my analysis frames it as a design choice (assuming my assumptions are even correct), but perhaps there are other ways to solve it that don't change the underlying design. Perhaps adding clipping to the existing code to prioritize regions of the full render being done. CRAIG On Fri, Dec 12, 2008 at 8:14 AM, Dimitrios Symeonidis <azim...@gmail.com>wrote: > These seems like a design decision for evince (and libpoppler), much > more than a bug. I don't think this is the place to suggest something > like this. Maybe Ubuntu Brainstorm would be more adequate? > > -- > Envice too slow handling large files > https://bugs.launchpad.net/bugs/305491 > You received this bug notification because you are a direct subscriber > of the bug. > > Status in "evince" source package in Ubuntu: New > > Bug description: > Binary package hint: evince > > Envice is unusably slow with large files. I realize this is partly my > machine, but also partly rendering choices. When I zoom in or out on the > map (link below) it would appear Envice is trying to render the entire PDF > file at that zoom level, so I have to wait for it to complete (takes a few > moments). While that is going on, I can't scroll (because the scroll bars > are not changed and thus inaccurate until the rendering is completed, and > the scaled image tears a lot so I can't scroll to the part of the image I > want until rendering is done). > > I'm not sure why envice is trying to re-render the entire image immediately > [or at least that's what I assume it's doing]. While this does make > scrolling blazingly fast once the rendering is done, it holds me up when I > change zoom levels (as with large PDFs I will scroll and zoom in and out to > find areas of interest). Adobe's viewer seems to render in blocks and > layers so that you can still scroll around quite happily while it is > rendering finer details (although the rendering of those finer details is > quite fast as well... perhaps because they are rendering only the area I'm > viewing / or perhaps it just feels faster because it renders in layers and I > see results sooner / I suspect it's both) > > So a desirable end result would be > a) set scroll bars based on zoom level before rendering (so scrolling is > accurate) > b) render in layers so scrolling can be done immediately at the new zoom > level. > c) clip what is being rendered so it can render quickly. > d) render only what needs to be rendered (to save cycles). Cache the info > (or hints) at various levels/areas to speed future renders when the viewed > area and zoom level changes. > > PDF File > > (Sorry for the Lotus Domino ugly link... I can upload the PDF [19MB] if you > would prefer ;-) ) > > http://www.grt.ca/web/transit.nsf/5f22897663adffc585256e5a005c53df/57BFAAD12C0940D085256C21004D2EE7/$file/K-W%202009.pdf?openelement > > ProblemType: Bug > Architecture: i386 > DistroRelease: Ubuntu 8.10 > ExecutablePath: /usr/bin/evince > Package: evince 2.24.1-0ubuntu1 > ProcEnviron: > > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games > LANG=en_CA.UTF-8 > SHELL=/bin/bash > SourcePackage: evince > Uname: Linux 2.6.27-9-generic i686 > -- Envice too slow handling large files https://bugs.launchpad.net/bugs/305491 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
