kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/23/2011 01:02 AM, Dick Hollenbeck wrote:
> http://docs.wxwidgets.org/stable/wx_wxbitmap.html
>
> says PNG format is not supported on Windows version of wxWidgets, but I would
> not walk away without consulting the sources.
>
> More below.
>
>> PNG can be in the flow of information as an intermediate (man in the middle)
>> technology.  But I would like to treat it as almost a *.o file in a build
>> process.  Our real source file should be the *.svg file.  So I would like to see
>> us find a cross platform tool, and I think you have found that already, which
>> can be run from the command line to build the *.png files from the *.svg files.
>>
>> I propose that we agree never to post edit the PNG files, and that they must
>> come from the *.SVG files.  I suggest we have a separate CMakeLists.txt file to
>> build the *.PNG files from the *.SVG files automatically, but perhaps not make
>> it a mandatory part of the build process, on the theory that some builders will
>> not want to have the tool which converts from *.SVG to *.PNG installed.
>>
>> *.SVG -> *.PNG
>>
>>
>> Therefore this means distributing both the *.PNG and the *.SVG files as part of
>> the source tree.  That is, unless you want to burden every builder with the need
>> to have this tool installed.
>>
>>
>> Then we have to decide on how to load the PNG files into the programs, and there
>> seem to be at least two ways to do this:
>>
>>
>> A) read the *.PNG files into memory from disk at program start time.
>>
>> B) convert the *.PNG files into a BYTE array which is compiled into the
>> respective program.  But the byte array is definitely a PNG format, meaning we
>> get the advantage of the alpha channel support, which we do not currently have.
>>
>>
>> If B) is the chosen path.  This entails yet another step that we need to add to
>> the build path, meaning it needs to go into a CMakeLists.txt file and needs to
>> be able to happen from a commandline tool.
>>
>> *.PNG -> *.cpp
> http://www.libpng.org/pub/png/book/chapter09.html
>
> Although we are going with larger ICONs, I believe there may be no real memory
> penalty since the PNG byte array is essentially be the PNG file in RAM, and it
> is in a compressed format already. 
>
> So I think sticking with a BYTE array is the best path, because it will lead to
> faster loading and we can continue to maintain the bitmap collection as a
> library, and applications can continue to link against that.  I'm just proposing
> that we put some of the build paths into a well documented CMakeLists.txt file,
> one that does not necessarily run all the time as part of the normal compilation
> process.

And if you are really paying attention, you recognize that the "byte array
containing" *.cpp files for the bitmaps would also need to be distributed as
part of the source tree also.


> Then we simply have to do some global PNG setup before using the wxBitmap
> constructors, etc.  Perhaps instead of putting simply the byte arrays into the
> library, we can also put named global wxBitmaps which are instantiated one per
> bitmap library source file.  This way we hide in the library, some of the
> details of the bitmap construction also.  It looks like this is possible, that
> we can construct a wxBitmap  well in advance of any window it is to be used in.
>
> We have to visit the wxWidgets sources to see if we can trick the windows build
> of it, into using PNG format.  It it likely a behind the scenes library is
> needed, and that that library normally is not build or present on windows.  It
> is late now, otherwise I'd continue with the research.
>
>
> Dick
>
>
>