-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
I just noticed some problematic processes which needs clarifying and
fix.
This is:
* Deletion of pictures from collections
-> might be very slow with many pictures
* Open a collection
-> Slow with many pictures
* Open of pictures in separate window (from a collection)
-> Errorfull do not get the right size
* Deletion of a picture from collection _in main window_
-> Do not advance to the next
* Moving of a picture with overlay visible
-> pollutes the picture with parts from overlay until the complete
window is redraw
I think the fix of the above is a good point to describe what happens.
To show what I think about I did analyse the problem three:
* [o] Start in img-view::real_view_window_new()
* central structure !ViewWindow *vw
* New toplevel window
* vw->imd := new image
* set profile, background and such values for vw->imd
* [X] Set drag-n-drop events img-view::view_window_dnd_init()
* [ ] ... and buttons (?) img-view::view_image_set_buttons()
* Set events for window
* If image from collection
* [ ] image::image_change_from_collection() (Indirection)
* [ ] image::image_change_real()
* Set internal values
* Stop real_time_monitor (?)
* [ ] image::image_change_complete() (?)
* image::image_update_util() -- Call callback function
vw->imd->func_update
* Set Title
* Set State for vw->imd to IMAGE_STATE_IMAGE
* Restart real_time_monitor (?)
* [ ] image::image_prebuffer_set() -- Set read ahead
* [ ] filecache::file_cache_get() -- Get file from cache if there
(?)
* [ ] image::image_read_ahead_set()
* [ ] image::image_read_ahead_start()
* [ ] image-load::image_loader_new()
* [ ] image-load::image_loader_delay_area_ready() (?)
* Set callbacks for error and done
* [ ] image-load::image_loader_start() (for read ahead)
* [ ] Important point for indirection, has to go deeper (!)
* If from list (What list?)
* [ ] image::image_change_fd() (Indirection)
* [ ] image::image_change_real()
* Set internal values
* Stop real_time_monitor (?)
* [ ] image::image_change_complete() (?)
* image::image_update_util() -- Call callback function
vw->imd->func_update
* Set Title
* Set State for vw->imd to IMAGE_STATE_IMAGE
* Restart real_time_monitor (?)
* [ ] image::image_prebuffer_set() -- Set read ahead
* [ ] filecache::file_cache_get() -- Get file from cache if there
(?)
* [ ] image::image_read_ahead_set()
* [ ] image::image_read_ahead_start()
* [ ] image-load::image_loader_new()
* [ ] image-load::image_loader_delay_area_ready() (?)
* Set callbacks for error and done
* [ ] image-load::image_loader_start() (for read ahead)
* [ ] Important point for indirection, has to go deeper (!)
* Single picture (From where?)
* [ ] image::image_change_fd() (Indirection)
* [ ] image::image_change_real()
* Set internal values
* Stop real_time_monitor (?)
* [ ] image::image_change_complete() (?)
* image::image_update_util() -- Call callback function
vw->imd->func_update
* Set Title
* Set State for vw->imd to IMAGE_STATE_IMAGE
* Restart real_time_monitor (?)
* [X] image::image_zoom_get() (Indirection)
* [X] pixbuf-renderer::pixbuf_renderer_zoom_get()
* If above == 0.0 (As I see this cannot happens ever (?))
* [ ] image::image_get_image_size() (Indirection)
* [ ] pixbuf-renderer::pixbuf_renderer_get_image_size()
* Will fail to get the correct size if the image is not in cache
or preloaded (!)
* else
* pixbuf-renderer::pixbuf_renderer_get_scaled_size() (Why direct in
this case (?))
* Will fail to get the correct size if the image is not in cache or
preloaded (!)
* Now set size (which is most often 0:0)
* Show the window
* Append to the list of view windows
* [ ] filedata::file_data_register_notify_func()
It is not complete but it unhides some other (minor) problems. If some
one can complete the picture above please do. However, to fix the
problem I have to go deeper into image-loader. I wonder why the signal
"size_prepared" is not connected until now.
A additional problem I find when using debug output is that the read
ahead image is finished before the main image is loaded. This makes the
read ahead a bid absurd.
Another problem I find here is that when the collection window has to do
thinks (like delete many pictures) the view is very slow (only a
rectangle of several pixels (100 or so) is viewed once by once).
So please, if you know the logical structure of the above processes,
describe them. That would help to fix the problems. My structure above
is also just a RFC. I think the best place for it would be in the code
as documentation (With the motivation why something is done this way and
not the other).
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.de/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <kl...@ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEVAwUBS+cy+5+OKpjRpO3lAQoA6gf/fHLwbuI2O4RPSXZgonGnojJrRmn+AZfV
z7PNN8l+a88GBvdlxlYP6Elon90qADWuxsq0U91PlW0UeuOtMsHzWSq9RDEurjaY
lq/LPaaDYTT7O/dB3s39FYiRRhMozNTGNc6QB6053EdAmnuGoQ+cUgagQWYER4Bx
rDRvocf6+Cq3L77QE+0+g7bIohX3GElBFj4uSezOeEvzGMLLOlAwxotfdz1Be4DG
u8ysuAM5ntnXGJmbL1VqHEI45fUEO1cCKZIXPbq2uV6ziDyfFG7Z+SZnxMWtFKsR
y/yG53re2K6xViCxB83I9yagOr1ZmwWte8swOmp+YMDpKv6MQe9Xsw==
=y2+S
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
_______________________________________________
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
