[boost] [GIL] new IO extension review

Subject: [boost] [GIL] new IO extension review
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2010-12-07 11:47:50

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