package gv
retitle 400023 gv: should not always load the full page image into X server
severity 400023
tags 400023 + confirmed upstream help
thanks
* Richard Atterer <[EMAIL PROTECTED]> [070729 21:23]:
> On Sun, Jul 29, 2007 at 08:58:54PM +0200, Bernhard R. Link wrote:
> > Here the file just needs a bit of time and then causes the X server to
> > consume around 400MB more. (which is not that much considering a
> > 10000x10000 pixel image of the whole page is loaded into it).
> >
> > What kind of machine do you see this behaviour on? Would the X server
> > taking 400MB more be likely to cause that kind of swapping?
>
> Yes, most likely - I only have 512 MB on that machine (a Centrino
> notebook), and IIRC a couple of other applications were loaded at the time.
Thanks for your reply.
> So technically speaking, this may not be a bug and you could argue that I
> should use "ulimit -d" to prevent this kind of problem.
I'm not sure ulimit would help here, at least not when it only affects
gv and not the X server. (AFAIK gv just tells gs to store it in the X
server and then tells the X server which part of it to display in its
window).
> But it is very
> unexpected that a simple PDF file, which displays fine in other programs,
> will cause the machine to grind to a halt when I use gv. :-/
I'll keep this bug open as a wishlist request (as protection against too large
images is definitly at least an missing feature), but I don't thing either of
the two parts contributing to this can be solved easily:
1) Gv is using gs to produce the image if the page, directly into the X
server and then just scrolls that image. Producing only part of the
image would need some tricky integration with gs (or some deep
postscript magic that might as easily fail) and will severly slow down
scrolling around complex images or remote connections. (The point xpdf
and acroread can do this is that the pdf code itself is more limited[1] and
thus cannot be that hard, while postscript code is more powerfull. And
as gv does not use the pdf code but lets gs translate it into ps (most
likely even partly by running postscript code to interpret it)
everything gets a bit harder. Perhaps if someone implements this there
could be some switch to change between the two ways, but autoselecting
one would also be hard, which is also the other problem:
2) To detect when this would happen to show a warning before or things
like that, gv would need to know how big images its X server can be
given before it starts to swap (or even swaps in a way the system is no
longer useable). As the X server might run everywhere, checking local
memory is not enough, even if one assumes the X server is doing no funny
things and internally stores this image in a uncompressed but tightly
packed way. I haven't searched for it, but I've yet not met any way to
ask the X server how large images it could handle nicely and I'm not
that optimistic there might be a way to get that information.
Hochachtungsvoll,
Bernhard R. Link
[1] I've heard claims that pdf is not even Turing-complete. Never looked
into it, though.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
