On so 31. ledna 2009, Greg Troxel wrote: > Vladimir Nadvornik <nadvor...@suse.cz> writes: > > Thanks for your reply. Only quoting when I have something useful to say. > > > This looks more like a bug in GTK. Which GTK version do you have? > > (thumbnails are represented by the same pixbuf in both modes, the only > > difference is the rendering code, which is handled by a custom renderer > > in icon mode and by GTK in list mode) > > Interesting. gtk2+-2.14.7 >
Hm, I have no idea. It can be anything from diplay driver to GTK. > >> 7) I have long wanted gqview to cache more than a few images, letting > >> you set a max memory size for the cache. A 1-image cache doesn't keep > >> up, and is slow flipping among 3 or 4 images. > > > > This should work, the cache size can be set in advanced configuration, > > the default size is 128MB, that is 4 x 10MPix image. > > Or do you mean read ahead several images? > > Thanks; I see that and bumped it up to 256. > > I mean a few things: > > keep several images in cache (seems like that works great ) > > read ahead several images, perhaps 3, but might as well be > configurable. If I go to next after watcing an image a few seconds, > it's quick, but if I go forward twice the second one is slow. > > My own use case is that I want the last perhaps 4-5, and the next 3-4, > and wouldn't mind if it preferred prefetch if I'm doing next or previous > repeatedly and cache if I'm jumping around. But I have 2G of ram so 5 > each prefetch and cache would probably be peachy. The problem is that the interface between file list and image widget allows passing just one file for read ahead. Changing that would mean a lot of rewritting and IMHO there are more important tasks now. Of course, patches are welcome ;) > > Also, it seems the profile is reapplied rather than having the profile > be pre-applied. I guess cache may be jpg, not raw bits, but for read > ahead would be great to do this. Plus, would be nice to run a 2nd > thread (or OpenMP) to do the transforms. > the profile is applied after scaling the image. It is typically much faster than the other way when the images are bigger than the wiewport, but it needs to be reapplied after zoom. Ideal would be to combine both methods, but it is not trivial. > Split is awesome - thanks to whoever wrote that. I spend a lot of time > picking the best photos to keep and deleting the rest and that helps a > lot. It could be improved a bit, I think that id does not fit well with moving to the next image by single mouse click to the image window. Possible fixes are: a) ignore mouse clicks at all b) ignore mouse clicks in split mode c) enable or disable mouse clicks in configuration I think that b) is the best possibility. Vladimir ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
