libpng dependency issue

Steven Edwards winehacker at
Thu Feb 4 23:34:19 CST 2010


On Thu, Feb 4, 2010 at 7:08 PM, Luca Bennati <lucak3 at> wrote:
>> Technically, winemenubuilder should be using windowscodecs for its png
>> support, like the rest of wine. I believe Steven Edwards has done some
>> work on this.
> Don't know about this. What i know is that currently winemenubuilder shows
> this
> problem and it's needed to be worked out if you want to support builds on
> libpng

I was looking in to the overall architectural issues but have not had
the time to really hack on it recently. As far as I understand, the
current png support in wine's windowscodecs does not support creation
of a 32bpp image with transparency, unless I missed some commit
messages or totally misunderstood our discussions. I believe from my
reading native does support doing the conversions, saving the alpha
channel information, applying the masking, etc.

I was working on a patch for winemenubuilder so we would at least have
that part part done, even if it only spit out 24bpp images without
transparency but never got very far with it. If I recall correctly,
the current code parses the raw ico bitmapinfo, passes that to libpng,
applies the mask and generates the resulting image. I tried a few
different ways, using WIC to open a stream to the icon that was then
parsed by the icon decoder feeding the png encoder to generate the
image. I also tried using the existing parsing system, feeding that to
the bitmap decoder then the png encoder and never could get it to work
quite right. With the patch I had, the resulting png image was corrupt
possibly due to some RGB/BGR issue, I seem to recall Vincent
mentioning something about that as well.

Also I don't understand all of the magic involved in these operations
so I got kind of stalled on it until I am motivated to try to merge my
MacOS Application Bundle patch for OS X again. For my own education I
want to try to write a test for Windows that calls GdiAlphaBlend on a
bitmap image, applies the mask and then uses WIC do the same operation
and compare do a comparison. Something could be done based on existing
WIC tests.

If someone with better understanding feels motivated to do the legwork
in WIC, winemenubuilder can be fixed in pretty short order. There is
some redundancy in the code because there is an old code path for XPM
generation if libpng fails. I don't know if Alexandre really cares
about the XPM case, I'd just like to remove it. He did agree that
using WIC was the way to go.

Just about everything that supports xpm supports png these days. I
wasted a lot of time going through mental cycles thinking about how to
abstract the icon creation since on OS X (at least on leopard) the
icon format used by application bundles is icns not png, so we would
either need to have a special case for OS X anyway. I don't think
making a generic interface for corner cases like this should be a show
stopper. From what I gathered, WIC has this concept of user defined
image codecs. I suspect if we suddenly found people bitching at the
lack of XPM fallback support, we COULD go through the trouble of being
purists and writing a WIC decoder for these non-standard formats but
then again, this app is not meant to run on Windows ever anyway so
what's the point of being purists?

If we want to keep a XPM fallback using the old method, it would be
simple enough. As far as the icns case goes on OS X, it would also
take a lot less code to just call sips on the resulting png to have it
do the conversion to icns for us. I am not even sure if this step is
even really required on Snow Leopard, it may actually support using
png's for appbundles. When I last looked at the Application Bundle
documentation it implied that PNG was a supported format but was not
clear if it was limited to the iphone OS. Since my last round of RFCs,
submissions and groveling for comment on the direction I was going
with Application bundles was met with general silence, I've lost
interest again for a while. I'll pick it up again at some point and

So again, since this entire email has most likely exceeded the total
LOC in required, the simple answer is, I think, even if we fix
winemenubuilder to use WIC now, it would result in reduced quality
icons until WIC is enhanced due to lack of 32bpp with alpha channel
for transparency.

Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

More information about the wine-devel mailing list