+ * TODO:
+ *
+ * - Resizing the window makes everything go black forevermore. No idea why.
+ *
+ *
+ * - When a new image is loaded, there is a glitch: animation pauses during
+ * the period when we're loading the image-to-fade-in. On fast (2GHz)
+ * machines, this stutter is short but noticable (usually less than half a
+ * second.) On slower machines, it can be much more pronounced.
+ *
+ * In xscreensaver 4.17, I added the new functions fork_load_random_image()
+ * and fork_screen_to_ximage() to make it possible to do image loading in
+ * the background, in an attempt to solve this (the idea being to only swap
+ * in the new image once it has been loaded.) Using those routines, we
+ * continue animating while the file system is being searched for an image
+ * file; while that image data is read, parsed, and decompressed; while that
+ * data is placed on a Pixmap in the X server.
+ *
+ * However, two things still happen in the "parent" (glslideshow) process:
+ * converting that server-side Pixmap to a client-side XImage (XGetImage);
+ * and converting that XImage to an OpenGL texture (gluBuild2DMipmaps).
+ * It's possible that some new code would allow us to do the Pixmap-to-XImage
+ * conversion in the forked process (feed it back upstream through a pipe or
+ * SHM segment or something); however, it turns out that significant
+ * parent-process image-loading time is being spent in gluBuild2DMipmaps().
+ *
+ * So, the next step would be to figure out some way to create a texture on
+ * the other end of the fork that would be usable by the parent process. Is
+ * that even possible? Is it possible to use a single GLX context in a
+ * multithreaded way like that? (Or use a second GLX context, but allow the
+ * two contexts to share data?)
+ *
+ * Another question remains: is the stalling happening in the GL/GLX
+ * libraries, or are we actually seeing a stall on the graphics pipeline?
+ * If the latter, then no amount of threading would help, because the
+ * bottleneck is pushing the bits from system memory to the graphics card.
+ *
+ * How does Apple do this with their MacOSX slideshow screen saver? Perhaps
+ * it's easier for them because their OpenGL libraries have thread support
+ * at a lower level?
+ *
+ *
+ * - Even if the glitch was solved, there's still a bug in the background
+ * loading of images: as soon as the image comes in, we slap it into place
+ * in the target quad. This can lead to an image being changed while it is
+ * still being drawn, if that quad happens to be visible already. Instead,
+ * when the callback goes off, we should make sure to load it into the
+ * invisible quad, or if both are visible, we should wait until one goes
+ * invisible and then load it there (in other words, wait for the next
+ * fade-out to end.)