Hi everybody, this is my first official Boost review so <insert the usual disclaimer> ;) I'm glad to see that at last more people have joined the discussion... In case some have not noticed, there was a very recent 'pre-discussion' about io_new titled "[gil] New IO release" and can be found here: http://lists.boost.org/Archives/boost/2010/10/index.php http://lists.boost.org/Archives/boost/2010/10/171450.php ...where I've already written (about) my thoughts and objections in detail: http://lists.boost.org/Archives/boost/2010/10/171732.php For the sake of brevity (and tight time management :) I will not repeat all the details here, rather try to reiterate through them briefly (omitting tests, examples and/or detailed argumentation) while perhaps adding some new thoughts... Mateusz, can you please confirm whether this approach (to assume that the "[gil] New IO release" notes and conclusions are part of the final review discussion) is OK or should I somehow repack that discussion into the new one..? ------ What is your evaluation of the design? ------ While the design can be considered an improvement from GIL.IO I nonetheless consider it lacking. As the new interface already constitutes a breaking change, this opportunity could have been used to provide a much more powerful and flexible interface (while still maintaining ease of use). A brief reiteration from "[gil] New IO release", the free function interface is inflexible/weak because it: - makes it difficult or practically impossible to reuse underlying backend instances across calls which, for example, has serious performance implications for ROI based access or when you want to read the image info/metadata before reading the image... - (as is done now) couples the choice of the backend with the choice of the image format (i.e. it makes it much more difficult to use/add alternate backend implementations for various image formats, for example if one wants/has to use LodePNG or GDI+ or ... as a backend) - does not allow access to the underlying backend which is necessary both for faster/easier solving of real world problems (either later found deficiencies in the interface or more complex/unconventional/corner use cases) and a more future-proof design (that can be more easily extended without breaking changes and/or introduction of additional overheads) ------ What is your evaluation of the implementation? ------ Considering that the GIL.IO implementation already has an inefficient implementation (which was even hinted by the "this will be simplified" comments in the code) I would hope io_new to provide a step forward in this regard...unfortunately it turns out it is a big step backward, both in terms of code bloat and code speed (as demonstrated by the tests and in-depth analysis in the "[gil] New IO release" thread)... In fact, the mentioned test practically demonstrates a 'theoretical' effect: on an Intel i5 CPU, with a relatively large cache, io and io2 benefit from being compiled/optimized for speed (as opposed for size) while io_new actually executes slower when compiled for speed (probably because the inherent code size increase/excessive inlining which overflows even a large CPU cache)...this effect was not demonstrated when the same test was run a much weaker Via C7-M CPU (with a much smaller cache)... In addition to efficiency concerns, the io_new implementation (or 'internal design') is also inflexible in certain areas where it causes duplication/repetitive code between different backend wrappers (thus not making it easier to extend with new backends). ------ What is your evaluation of the documentation? ------ Did not build it... ------ What is your evaluation of the potential usefulness of the extensions? ------ A makeover for GIL.IO is long over due and the general ideas that Christian put in io_new are mostly very welcome even though I have serious objections as to how those ideas were actually put in practice... ------ Did you try to use the extensions? ------ Yes, but only JPEG, PNG and TIFF IO extensions (did not try the opencv, sdl and toolbox extensions)... ------ With what compiler? ------ MSVC++ 10.0 ------ Did you have any problems? ------ Yes, for example the broken TIFF reading-with-conversion, Christian did fix it later but the fix seems more like a patch as it demonstrates an inherent inflexibility (mentioned at the end of the implementation section) in the io_new design that requires the backend-wrapper maintainer to provide the (possibly very long) conversion switch cases for each backend... ------ How much effort did you put into your evaluation? ------ As mentioned, I dug only through the core IO extension (and specifically through the LibJPEG, LibPNG and LibTIFF backend wrappers) but the areas I did investigate I examined relatively thoroughly (and over a longer period of time...in parallel, over the many months of development of io2)... ------ Are you knowledgeable about the problem domain? ------ My main use case consists of simple image loading on application startup (for the application skin) and only minor adjustments (like PC to Mac gamma fixup). However, as I was unsatisfied with existing solutions (including the direction in which io_new went) I decided to roll my own solution and for this to get accepted I had to look into and cover all reasonably possible use cases (which included going through the GIL.IO documentation as well as old/previous GIL.IO related discussions). ------ Do you think the extensions should be accepted as a part of Boost.GIL library? ------ (To make it clear) The way they are now - no. However, as mentioned earlier, a makeover of GIL.IO is undoubtedly needed and the work Christian has done so far is truly massive. For example, the properties system could prove to be quite useful (as a C++ abstraction for the various options and metadata specific to each image format) if done right (if not coupled to a particular backend, so that, for example, the PNG properties can equally be used, if supported, with LibPNG, LodePNG, GDI+, WIC ....)... Actually, IMO some of the extensions (like new GIL image/pixel formats) should maybe enter GIL itself, not merely as extensions (this would possibly even make it easier to implement the more complex IO backends/formats, like TIFF, that support those types of images)... -- "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