Ubuntu
evince package

Envice too slow handling large files

Bug #305491 reported by Craig73 on 2008-12-05

This bug report is a duplicate of: Bug #24630: Evince crashes when zooming PDF-File to 400%. Edit Remove

This bug affects 4 people

Affects		Status	Importance	Assigned to	Milestone
	evince (Ubuntu)	Invalid	Low	Ubuntu Desktop Bugs

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

Tags:

Revision history for this message

Craig73 (funrun73) wrote on 2008-12-05:

Dependencies.txt Edit (3.4 KiB, text/plain; charset="utf-8")
ProcMaps.txt Edit (24.1 KiB, text/plain; charset="utf-8")
ProcStatus.txt Edit (781 bytes, text/plain; charset="utf-8")

Revision history for this message

Pedro Villavicencio (pedro) wrote on 2008-12-05:

thanks for the report, could you attach the file to the report? i'm not able to access to it, thanks.

Changed in evince:
assignee:	nobody → desktop-bugs
importance:	Undecided → Low
status:	New → Incomplete

Revision history for this message

Craig73 (funrun73) wrote on 2008-12-05:

K-W 2009.pdf Edit (18.6 MiB, application/pdf)

PDF attached.

Dimitrios Symeonidis (azimout) on 2008-12-11

Changed in evince:
status:	Incomplete → New

Revision history for this message

Dimitrios Symeonidis (azimout) wrote on 2008-12-12:

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?

Revision history for this message

Craig73 (funrun73) wrote on 2008-12-12: Re: [Bug 305491] Re: Envice too slow handling large files

Download full text (3.2 KiB)

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 <email address hidden>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=...

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 <azimout@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
>

Revision history for this message

Sebastien Bacher (seb128) wrote on 2009-01-15:

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

Changed in evince:
status:	New → Invalid

Revision history for this message

Craig73 (funrun73) wrote on 2009-01-15:

How did this get invalidated? It does not seem like a duplicate to 24630 which is dealing with a 96KB file versus mine which is 18MB. The former is likely a bug causing excessive resources to be consumed, where as this one is about handling of large files.