Re: feature request: better caching

Frédéric <[email protected]> Wed, 4 Apr 2007 19:32:47 +0200
Newsgroups gmane.comp.gnome.apps.gqview.devel
Organization Home
Message-ID <[email protected]>
--===============2016595067==
Content-Type: multipart/signed; boundary="nextPart2944531.aQ4HMoveoo";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2944531.aQ4HMoveoo
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 04 April 2007 18:59, Greg Troxel wrote:

> 1) Instead of caching/prefetching 1 file, cache up to some limit,
>    perhaps on the order of 10, so that when flipping among 5 to choose
>    which to keep it's faster.

Instead of the number of pictures, it should be better to fix a memory=20
usage limit.

> 2) Perhaps for all files, remember exif orientation, or read orientation
>    first before starting display.  Currently, I get the image showing up
>    in file orientation, and then flipped to the right orientation.  It
>    would be really nice if this were drawn right from the start.

I agree. Same for color correction. I posted something about this on the=20
user list, some weeks ago:

"Great feature, but a little bit slow. I know that it needs a lot of=20
computation, and waiting for the end of color correction before displaying=
=20
the picture could be annoying, but why don't you apply the profile in=20
background when preloading the next picture? Even if I wait enough,=20
switching to the next picture display it without correction, and then=20
apply the profile.

I think you could first preload the next picture, and once it is done,=20
start to preload the color corrected one; if the user switch to that=20
picture after the end of the color correction computation, then display=20
the color corrected picture; if the user switch to the new picture before=20
the end of the computation, then display the 'raw' picture, then continue=20
the color correction, and switch to the color corrected as soon as it is=20
available.

This may improve the usability. It could also be interesting, in addition=20
of all this, to add an option to wait before the end of color correction=20
before displaying a new picture."

=2D-=20
   Fr=E9d=E9ric

   http://www.gbiloba.org

--nextPart2944531.aQ4HMoveoo
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGE+FGYSjuFMxF2CgRAn5oAKC1zKlrYDRpZlCAfUrB5oOHSTmd5gCfYcd4
8z2Nx6JTo5nDWF42wxAyuqQ=
=+H5f
-----END PGP SIGNATURE-----

--nextPart2944531.aQ4HMoveoo--


--===============2016595067==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--===============2016595067==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gqview-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gqview-devel

--===============2016595067==--