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==--