kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 8/23/2011 2: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.

If I'm reading this correctly, I think Windows does support PNGs via wxImage.
In the first paragraph it states "Note that missing or partially-implemented
formats are automatically supplemented by the wxImage to load the data, and
then converting it to wxBitmap form.".  When I build wxWidgets on Windows, it
finds libpng.a or uses it's own internal version.  There may be some
performance hit when converting from the PNG to wxBitmap but that should only
happen at load time.

Wayne

> 
> 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.
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>