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:

Features

• 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

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.

Performance

• 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:

• make

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_color_x

`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.

• `build_colors’

This feature invokes all the `c_color_x’ features. So it can fill whole image data into a memory pointer in single call.

• fill_memory

This feature can find the memory access pointer of our EV_PIXEL_BUFFER, then it invoke `build_colors’ to fill the image contents.

Future

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.