Eiffel Image Embedder Tool
From SVN revision#70058, we have a tool to embed images in executables (e.g. exe for Windows). The name of the tool is
Image Eiffel Code' which stays in $EIFFEL_SRC/tools/image_eiffel_codeâ€™.
Snapshot of the tool:
- Image embed
The basic feature of the tools is embedding images in executables.
This is useful for libraries which need comes with a set of icons. All client programmers of the libraries don't have to providing a set of images since they are embedded already.
Of course, executables can use this tool too. End users of the executables will not care about the working directory. The executable folder will look clearer and professional since there are fewer files.
Smart Docking library use this tool to embed icons currently.
Multi-platform embed image solution. On different platforms, the tool has almost the same performance.
I have tested it on Windows XP 32/64bits and Ubuntu. Manu have tested it on SPARK Solaris.
- loading speed
The loading speed is a little bit faster than loading a png file directly (by GDI+ on Windows, by GTK on Linux). If the time of loading a png file directly is 100, the time of loading an embedded icon is about 80.
- final machine code size
Because the tool doesnâ€™t compress target image contents, so the image size of generated in executables is larger than original png file. But the embedded image size is only little bigger than a bmp size. It's about 1.3 times as large as original bmp's size.
How it works
The basic idea of the tool is generate an Eiffel class file which can represent original image file (maybe png, bmp, jpg or any other image format files.)
If you have seen generated image Eiffel class file, you will find:
This is the creation method of generated image Eiffel class. It can initialize an EV_PIXEL_BUFFER instance, the fill the memory contents of EV_PIXEL_BUFFER.
`c_colors_xâ€™ (x is an integer) is the features which can fill a memory pointer with data. The data come from original image file.
You may ask why we canâ€™t use only one
c_color_xâ€™ feature to store whole image data instead of separate c_color_xâ€™ features. The answer is in following `Futureâ€™ section.
You may also noticed that the C pre processor in the external feature. The reason is the different image data order between Windows and GTK. In Windows GDI+, the color bit order is
Alpha, Red, Green, Blueâ€™. But in Linux GTK, the order is Red, Green, Blue, Alphaâ€™.
The last trick in c externals is why using char to store image data, but not unsigned int  or others. The reason is compiled executables size. For gcc on Linux, it make no differences between char and int. But on Windows with Microsoft vc compiler, the compiled int array machine code size is about 3 times bigger than the compiled machine code size of char array. Because Microsoft vc compiler, generated machine code donâ€™t store int in a continuous sequence. Fortunately, the vc compiler store char in a continuous sequence which can save a lot of generated executables size.
This feature invokes all the `c_color_xâ€™ features. So it can fill whole image data into a memory pointer in single call.
This feature can find the memory access pointer of our EV_PIXEL_BUFFER, then it invoke `build_colorsâ€™ to fill the image contents.
Because the limitation of Eiffel manifest string size is about 32kb. The Eiffel c external features string is a kind of Eiffel manifest string which canâ€™t larger than 32kb. So the tool generated a lot of external features in the generated image Eiffel class. If the limitations removed in the future, the performance (loading speed and icons size) of the tool will improve.