Re: Patch to get the pixbuf backend to compile, maybe even works properly

[David Malcolm <dmalcolm redhat com>]

On Fri, 2005-04-01 at 14:34 -0500, David Malcolm wrote:
> On Fri, 2005-04-01 at 14:26 -0500, Jonathan Blandford wrote:
> > David Malcolm <dmalcolm redhat com> writes:
> > 
> > > CVS evince wouldn't compile for me; the shell/Makefile.am want to links
> > > against the pixbuf subdirectory.
> > > 
> > > The attached patch fixed the pixbuf backend for me; though I haven't
> > > looked into the details of the new API, so I may doing something subtly
> > > wrong.
> > 
> > Looks mostly right, though you need to scale this pixbuf to
> > document->scale in render().
> 
> Do I?  Zooming in and out seems to work OK as is; I'm guessing that
> evince is scaling this pixbuf up and down for me soemwhere else...

I added the scaling (tried HYPER but seemed too slow to me, so I went
down to BILINEAR).

The pixbuf backend now has the nice two-stage zoom you see in eog, where
it does a coarse quick zoom as you manipulate things (scaling done by
the evince shell), and a higher-quality slower zoom a short time later
(done by the backend).

I committed this (jrb approved the patch verbally).

However, I think there should be some kind of limit imposed on scaling;
if I hit zoom too many times, it will try to create a huge pixbuf, which
will push the machine deeply into swap (maybe we've got memory leaks
somewhere too?) and bring evince to its knees.

So perhaps we should attempt to calculate the rough memory consumption
of the scaled pixbuf and limit the scale so that it can only occupy a
certain percentage of the RAM of the machine?  (if this is obtainable in
a crossplatform way).  I'm assuming that evince threading handles the
excess of CPU load that this kind of abuse creates.

Or should backends have some way of informing the shell about the limits
of zoom they impose (if any)?

Alternatively, perhaps a tile-based approach, so that we only scale up
the regions of the image that are visible (or close to being visible)
within the viewer window?

Or maybe this stuff is better placed in eog; dealing with huge image
files (bitmap and vector) is maybe more of an "image viewer" problem
than a "page-based document" problem.

Dave