Archon::Utilities::FormatLibjpeg Struct Reference
Inheritance diagram for Archon::Utilities::FormatLibjpeg:
[legend]Collaboration diagram for Archon::Utilities::FormatLibjpeg:
[legend]List of all members.
Detailed Description
- Todo:
- We might be missing todo's in anonymous namespaces in other files.
An Image compatible frontend for libjpeg.
- See also:
- http://www.jpeg.org (ISO JPEG standards committee)
http://www.ijg.org (Independent JPEG Group)
Rewritten and tested against libjpeg version 6b.
- Todo:
- How do we handle progressive display during loading? The issue is that of preventing concurrent reading and writing of the pixel data in a single image.
It is trivial for applications that does not need to load several images concurrently, in this case we just read pixel data during the call to to the ProgressTracker. The reading operation could eg. be a texture creation function with the pixel buffer as input.
- Todo:
- Loading multiple images concurrently with progressive display needs more care.
With the right thread safe API we might still be able to succeed with only the ProgressTracker callback function. In most cases though, we will have to bother about concurrency and re-entrance. There are at least two different approaches one should considder. Either you would have each of the progreass tracker callbacks compete for a critical region in which the image data can be transfered safely to the destination buffer. This could be a call to an OpenGL texture creation function, and in this case the GLXContext would be the entity to protect.
- Todo:
- A different approach to displaying multiple concurrently loading images in a progressive manner is to have an extra thread that on regular intervals consults each image and transfers its pixel data onto the display device.
For this to work, we need a way to synchronize access to the pixel data, since the loader thread will need to access the pixel data too. An idea would be to add a way for the image loading process to query the ProgressTracker object for a mutex. The ProgressTracker object may report that there is no mutex, in which case the loading process should not bother with synchronization. On the other hand, if the ProgressTracker object does return a mutex reference, the loading process shall acquire a lock on that mutex before accessing the image data.
- Todo:
- This appraoch will fit well into the common paradigme of having a frame based rending thread with exclusive access to the rendering target (GLXContext).
- Todo:
- Considder adding the progressive flag to the Image API.
This goes for both loading and saving. In saving we have: If possible change the compression strategy/file-layout to improve the perceived progressiveness during the loading process potentally at the cost of system resources. For loading we have: If possible use extra resources to improve the perceived progressiveness of the loading process.
- Todo:
- Considder adding a prescaling setting to the image loading API.
This can often improve the quality of the resulting image compared to a generate first, then resize scenario. An elegant way of specifying the desired prescaling might be to simply ask the loading process to retaing the existing pixel buffer and only fill it with new contents. The drawback might be that it forces you to also prespecify a bit depth and a color model. But then again, somtimes this is just exactly the behavior that you need.
- Todo:
- What's the deal about abbreviated datastreams.
Notes on using setjump/longjump in C++:
Great care must be taken when using setjump/longjump in C++ context. The main problem is that stack objects will not have their destructors called during a long jump stack unwinding process.
In this case we set up the long jump handler in a C++ function and then call a number of C (not C++) functions, and it is only these C functions that can potentially issue a long jump. This fact makes things a bit easier to control.
We should be safe as long as we stick to the following rules:
-
Keep the setjump/longjump construction on the following canonical form:
if(!setjmp(jmpbuf)) // try
{
// code that may potentially issue a long jump (throw)
}
else // catch
{
// code that handles the long jump (exception)
}
-
Keep the try-scope completely free of declarations of variables whos type have either an explicit or an implied destructor.
-
For each C function call that may lead to a long jump make sure that the surrounding expression in the try-scope does not contain any temporary objects of a type that have either an explicit or an implied destructor.
-
If any of the C function calls that may lead to a long jump calls a C++ function (eg. as a call back function) then make sure that the called C++ function does not issue a long jump or lead to one being issued in a place where stack variables with destructors are "live".
-
Never long jump out of a C++ try block or catch block.
Definition at line 165 of file image_libjpeg.C.
Member Function Documentation
The documentation for this struct was generated from the following file:
Generated on Sun Jul 30 22:57:28 2006 for Archon by
1.4.4