PiBox » pipics

I want to write a widget that displays an image. This can then be called to display the specified image, leaving selection of the image to the core.

1. startKiosk is a timer thread that is called at boot to initialize running the playback.
2. startKiosk calls playImages. playImages() loops to find the current image to draw, and then gets the next image. It then sets a timer to display the next image.
3. do_drawing handles the actual drawing. It will return and error if the image can't be found.
4. getNextImage (in db.c) sets the active image to the next image in the list of images, if any.
5. pipicsNext kills the timer on the current image display, gets the next image and then displays it.
6. pipicsPrev kills the timer on the current image display, gets the prev image and then displays it.

1. Thread that identifies up to 100 images to display in the list of images(fileList in db.c). Thread updates list asynchronously if it finds more images or if images disappear from their paths (like a usb stick was removed).
2. Thread that keeps up to 5 images in memory (or up to a given size of data). The middle image is the currently displayed image, unless there are <5 images.
3. do_drawing() moves to a widget. Widget displays image at path or does nothing if path doesn't exist. It could also display an error message if images can't be found.
4. getNextImage remains the same.
5. pipicsNext updates active image, calls playImages.
6. pipicsPrev updates active image, calls playImages.
7. playImages stops timer, calls widget API to display current image, restarts timer.
8. New timer function calls pipicsNext when it goes off.
9. startKiosk calls playImages and starts new timer function.

The goal is to more clearly differentiate selecting the active image and actually displaying it.

1. Get an EXIF loader: ExifLoader *l = exif_loader_new();
2. Load file into memory: exif_loader_write_file(l, char *path);
3. Read data from loader: ExifData *ed = exif_loader_get_data(l);
4. Get rid of the loader: exif_loader_unref(l);
5. Get the Orientation tag: ExifEntry *entry = exif_data_get_entry (ed, EXIF_TAG_ORIENTATION);
6. Get the value of the tag: char value²; exif_entry_get_value(entry, &value, 2);
7. Based on value, rotate image appropriately.
8. Possibly (might be handled by next step): exif_entry_unref(entry);
9. Free ExifData: exif_data_unref(ed);

Exif data is in JPEG, but not standardized in PNG.

I think orientation handling is already implemented with a call to gdk_pixbuf_apply_embedded_orientation() in the _paint() function of the widget.

I can verify that by extracting orientation information from some of the images in the sample data to see if they are being oriented correctly.

Verified. Images are properly rotated with gdk_pixbuf_apply_embedded_orientation(). No need to integrate EXIF data reading into the widget.

Last issue: caching pixbufs.

The first 10 pixbufs are loaded at boot time. This is okay except there is a delay before the default image is displayed. Loading filenames/pixbufs should be handled in a background task.

The background task/thread should:
1. Read all filenames as it does now.
2. Load only the first 10 pixbufs.
3. Schedule a background cache handler thread.

The GSList will need to be wrapped by a mutex for the initial background task, the cache handler and the getNext/getPrev functions.

This initial background task will be started where dbLoad() is currently called.
startKiosk() will sleep for 3 seconds after it loads the default image, then run as it normally does.
The secondary cache handler thread will keep at least 10 pixbufs. It looks at the offset of the activeFile and keeps at up to 5 behind and 5 ahead of it. If it appends one to the end, it unrefs one at the head. So the cache handler is a window into the full GSList of image files.
Every time the getNext or getPrev functions are called they must kick a semaphore to have the cache handler make it's updates.
Since getNext/getPrev can be faster than loading a pixbuf, the cache handler must load as many pixbufs as have been requested based on the window, the clear the semaphore.
It might be useful to limit the semaphore count to prevent the cache handler from being overloaded by user input.