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