Hi...sorry for the delay...had to do some context switching :) "Christian Henning" <chhenning@gmail.com> wrote in message news:AANLkTimcmYfUXD=tXZLibfuMqdgmtg6X-p-Em81Th+83@mail.gmail.com...
In any event, you need to make sure you offer at the very least a way to simulate the old gil::io interface to avoid breaking code.
Of course, this is trivial to provide...
Um, to rewind things a little to make sure we are talking about the same thing. I was talking about reusing the backend library objects/instances (e.g. TIFF, jpeg_decompress_struct, ...), which IO2 supports and IO_new AFAICT does not.
You can reuse a TIFF* but not reuse a jpeg_decompress_struct. It might be a good idea to add these objects to the image_read_settings< jpeg_tag > structures.
Hmm...for this not to turn out akward/non-RAII-like you'd probably need to make your image_read_settings<> into a non-trivial class with proper initialisation and destruction...IOW your design would become more object-based (more io2-like)...which is what I'm proposing all along (and the way io2 is already designed ;)
Simply reusing the low level source object (like a FILE) will make little difference if, for every ROI you read, you have to recreate the backend library object which in turn implies rereading the whole image up to the requested ROI instead of just continuing where you left off...
Is this statement true when an std::ifstream object is used?
Well yes, the type of the input/source object does not matter...the problem is in the fact that the backend object (e.g. jpeg_decompress_struct) is destroyed and recreated (e.g. for each call to read_image()) which in turn requires/makes the backend library code reread the image from the beginning (to read the header, dimensions, format etc...)...
More advanced use cases might need such access to low level objects. I agree with you that my current implementation lacks support for some advanced use cases.
The problem (in this particular case) is not (primarily) in the implementation but in the interface/design of io_new... If we can agree on this and that io2 solves these problems better would you agree to switch to (an) io2(-like) interface so we can merge and join our efforts? I can write some preliminary documentation on the base formatted_image (that forms the backbone of io2) and the requirements that each xxx_image implementation class (libpng_image, wic_image...) must fulfil according to which you can try and port for example your GIF reader and then, through this experience, say your objections/what you think needs to be changed/improved, how to accommodate/fit into/work with other parts of your work (the toolbox, the properties system...)...
Also consider making friends with the disassembly window in release builds...
Any good tutorial on this somewhere?
You don't need one actually...you can pretty much google any unknown instructions and/or compiler/optimizer idiom you see ;) -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman