| Summary: | Suggestions about task "Preload next image" | ||
|---|---|---|---|
| Product: | [Applications] gwenview | Reporter: | Philipp Weissenbacher <philippweissenbacher> |
| Component: | general | Assignee: | Gwenview Bugs <gwenview-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | arthur, che, ibc, nate, pascal, postix |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Philipp Weissenbacher
2004-01-05 01:50:54 UTC
Preloading is definitely something I want to add to Gwenview, but I need to implement non-blocking image loading first. When this is done, it will be possible to preload images without the user noticing it, even if the image is big. It might be usefull to add a maxsize through, to avoid eating all memory. Sure. It was just an idea, and I wanted to post it to avoid forgetting it. *** Bug 99869 has been marked as a duplicate of this bug. *** CVS commit by lunakl: Make image loaders shared. Image preloading for the slideshow (preloading is not pre-rendering though). CCBUG: 71870 M +39 -19 gvdocumentloadingimpl.cpp 1.2 M +75 -14 gvimageloader.cpp 1.3 M +23 -15 gvimageloader.h 1.3 M +45 -1 gvslideshow.cpp 1.8 M +7 -2 gvslideshow.h 1.8 CVS commit by lunakl: Image preloading also for the next/previous toolbar buttons in the image KPart. CCBUG: 71870 M +47 -7 gvimagepart.cpp 1.34 M +9 -0 gvimagepart.h 1.18 I have 1.2.91 gwenview and preloading is buggy. When I view images with prev/next, images are not preloaded, I can see them loading. But, when I start a slideshow, images are preloaded. Then if I try to view images with pres/next, images are preloaded. So I have to start slideshow, stop it and than start viewing images normally with keys (and now they are preloaded). Preloading works only when pressing next. I think it should be intelligen enough to see that I am going back and preload the image before too (when going backwards). Not buggy, still unfinished. Can you see this feature being marked as done? Setting update time to 1 s and starting a slideshow will not work well on my computer. Sometimes the image does not even show up completely before being removed (best smoothing, do not show before done) Removing the smoothing option helps. But I think that ALL processing on a file should be done before showing it in slideshow view. (read, smoothed, rotated). This should be handled by preprocessing Computer AMD 3500+ 512 MB Ohh.. my JPEGs are 3,5 MB each... Every other file is a NEF (16MB) whose thumbnail is shown (these should not be shown. But that is another wish) Preloading in Gwenview 1.3.1 is still too slow. What I need (and I guess many other people who photograph a lot) is to be able to switch between two to four images *witout* delay to figure out which one is best. I do not need intelligent preloading: it would suffice if the picutre I just displayed can be brought back in zero time. But I have the impression that going back in gwenview takes even longer than going forward. When you try to directly compare a series of pictures, the 0.7sec black screen shown by gwenview is quite deadly [image size about 1.4Mb, Pentium M 1700, 1G, smoothing: None]. Maybe you could do something like KPDF, where you have a setting to enable "aggressive" memory usage that enables gwenview to keep a nice little history of images in memory. Or you could have a look at the code of kuickshow to find some inspiration (kuickshow has been very fast for years now, even on those sub-500Mb-RAM machines back in the elder days). I still think gwenview is superiour to kuickshow in many ways, but the core functionality of an image viewer still is viewing images. Fast. I agree that Gwenview 1.3.1 could (should?) be much faster when going to the next/previous image. Ideally, given enough time to prepare the next/previous image, there would be no noticeable black-screen time when changing images. (At least on a decent system such as 2GHz, 1GB RAM and with 3-5MB (8-10 Mpixel) jpg files.) An option to increase the pre-render/cache from a simple next/previous to a selectable buffer size would be ideal. How is the progress coming along? As the size of digital photos has become quite big, it's become almost a pain to watch more than one picture with gwenview. Don't misunderstand me, I love gwenview. It's a great application. However Apple image-viewers loads images much faster on the 400mhz iphone, than I do on my 2,0 ghz core duo. How do they do it? >However Apple image-viewers loads images much faster on the 400mhz iphone, than I do on my 2,0 ghz core duo. How do they do it?
Difficult to answer, since they do not provide source code access, or do they?
Anyway, I have plans to avoid loading the full image when the user wants to show the image in zoom-to-fit mode. This will hopefully be implemented in time for KDE 4.1.
You probably know this already, but perhaps you don't and it could help. I'm studying computer science on university of Copenhagen. According to one of my books "Fundementals of Multimedia", for JPEG, encoding in progressive mode is about making available the image in a small data-amount and loading more and more details into the image. While it's been a while since I've had this subject, I think it should be possible to use this techique even though the image is not encoded in progressive mode. The idea is first to only look at the most significant bit in the AC-component and then build/display a rough picture from those data, then enhance it by taking more and more bits until the picture is fully loaded. When using digital cameras and other slow units that display high-resolution pictures, you see exactly this form of loading. The picture starts being blurry, but quickly becomes clear as having been loaded sequentially. If you are going to implement this, you might want to think about doing it in parralel. We are going to have a LOT of in a matter of few years, however it might be easier and therefore more manageable to first implement it using one processor. I already knew about this, but thanks for the info anyway. The good news is Qt allows to "abstract" this to avoid writing JPEG specific code: in Qt4 it's possible to loaded a resized version of an image. Only the significant parts of the compressed image will be read if the image format supports it, as JPEG does. This is what I plan to use if I find the time to do so. Sounds good. Does it also load the full image as blurred and then sharpen in afterwards? I think that progressive loading should be preferred over sequential loading. //Pascal No, it's a bit different: if you have a large image (for example 3 times the size of the screen), it's possible to load a resized version of this image (for example 1.5 times the size of the screen). This way it's faster to load, and faster to scale down to fit the screen. No, it's a bit different: if you have a large image (for example 3 times the size of the screen), it's possible to load a resized version of this image (for example 1.5 times the size of the screen). This way it's faster to load, and faster to scale down to fit the screen. No, it's a bit different: if you have a large image (for example 3 times the size of the screen), it's possible to load a resized version of this image (for example 1.5 times the size of the screen). This way it's faster to load, and faster to scale down to fit the screen. Is this bug still relevant today in 2017 with a KF5 version of Gwenview? Jep. At least for network shares - E.g. try to view some images over webdav (e.g. an Owncloud/Nextcloud share). Each time you click next you have to wait for Gwenview to fetch the image from the server with a loading symbol. If Gwenview had already loaded the next file it would be instant unless you are flipping through faster than your disk/network access. Thanks for the info! |