"smooth" playback / wait for image

[fire-eggs]

While viewing animation-frame collections in YacReader, it occurred to me that YAIV won't do "smooth" playback. In this case, YAIV won't support "flipbook" playback of animation-frames.

I.e. YAIV will attempt to display images as fast as possible (e.g. when holding down the "next image" key). This means skipping some image display and moving on as quickly as the system allows. [handle processing may interrupt the load-draw sequence]

ImageGlass and presumably YacReader will wait until the current image has fully displayed before processing the next command. There is no "skipping" of images.

To me, the downside of waiting before displaying the next image is when images are large or slow to load. If the user is trying to move quickly through images then they may want skipping, but if they actually want to see each image, they don't want to skip.

[fire-eggs]

Some examples.

4255571.zip
4260979.zip

[fire-eggs]

YACReader reads all / a bunch of the images from the archive ahead of time. So there is no "file load" time penalty moving from image to image. May need to consider reading images ahead in order to make this work.

[rageworx]

My little opinion is, thinking about pthread.
there's signal, condition and mutex in pthread, and you can set signal with any flag to running thread as like WaitSingleObject() to waiting HEVENT in Windows thread.
Some conditions may works these sequence...

• there's basically two threads, reading directory files and making cached data as like image type, resolution, thumbnail, and another is rendering image thread.
• rendering thread has 3 states, none(nothing, just display empty screen), reading ( shows progress something to user while reading and render image ..) and result ( shows cropped and zoomed image or error result )
• first thread reads files in current directory with dirent and dir in stdio ( it's maybe works for all OS, exceptionally Windows may need something wchar_t type ).
• file thread has own position queue for what file/dir in currently selected ( and UI manages this queue to decreased or increased by scrolling mouse or keyboard inputs )
• when queue changed, file thread send signal to render thread what file is currently selected.
• file render thread mutexed, there's three options when new signal incame: discrard current working ( reading or zooming whatever ), or let next job to working queue ( I don't recommend this ), or ignore current queue to return -1 or something different signal to file thread to do not move file queue because "I'm BUSY man !".

I believe it will be help to prevent "unresponsable program" while reading biiiiiig file.
Asynchronous UI architecture may helps user can recognize what happens to now by visual state.

Regards, Raph.

[fire-eggs]

All excellent points!

[rageworx]

Todays ... I'm little BIG busy for preparing new embedded model for USB-3.1-gen1 SS (SuperSpeed) desktop 3D scanner.
I'm working on only by me, there's no one to understand what POSIX or what Embedded Linux, even no MacOS developers for preparing new generation of system support.
I'll be come to here as I can do!

[fire-eggs]

I'm sorry if I implied any pressure on your participation! I definitely understand that work which "pays the bills" is much higher priority!!

Good luck!