Runar Jordhal does PNGs !! With translucency even.

There are some interesting problems with using alpha channels in VisualWorks though. I've recently posted one to the VW NC mailing list.

The problem lies with the FixedPalette object. FixedPalette wants to present itself as a Collection of sorts. You give it an index and it looks up a color for you. It has what I consider an "upside down" semantics in its at: behavior.

If you ask an (Array new: 5) at: 6, you get a subscript bounds error. It uses it's at:ifAbsent: method and raises an error in the ifAbsent: block. Not so if you ask a FixedPalette for a value at: something. As long as you feed it a any integer. It does so by using the ifAbsent: block to do the same thing that the at:ifAbsent: does when it does determine that the color is included. This seems like backwards to me. I like the at: behavior actually, I think that a FixedPalette does indeed posses the entire integer space. The presence of variables like "mask" seems to indicate that it can take the part of any index it wants and encode the correct color from it. Oh well, kind of screwy, but what does it really matter anyway?

When VisualWorks starts up, it interogates your OSes video layer and figures out what the standard color representation is. Regardless of changing this on the fly, VisualWorks keeps that same palette for the lifecycle of the application. On any modern true color Windows install, you're going to get a 32 bit FixedPalette with 24 bits of color, defined in XBGR format. On an X11 box, you'll get XRGB. And I forget what you get on OSX, but I once new.

When you "display:" anImage with VisualWorks, it checks to see if it's color palette matches what it has cached as the screen's default color palette. If it does, great, it just goes straight to primitive code. When it doesn't, things get interesting. It will create a temporary image to display which DOES match the Screen's color palette. It has got to be one of the most sub-optimal pieces of computation you can invoke in the Smalltalk class library. Especially when your images grow to appreciable size. Let's say your trying to display an XBGR image (fetched from a .bmp file) on an XRGB system. The starting point for this journey is convertForGraphicsDevice:

First of all, it enumerates the pixel indeces of the target image. And it fetches the value for each slot. In a 32 bpp image (what you get on any true color system), this means using at: 4 times. And then sending bitShift: and bitOr: 3 times each. And these things run so quick in Smalltalk. Once it's concocted that integer, it consults it's palette to get the related ColorValue object. Our FixedPalette then bit breaks it down into 3 components (more bitShits: and bitAnds:) and creates a ColorValue object, replete with 3 13bit Integers per component, scaled up from their 8 bit representation. This goes through the "paintTransferBlock" to convert it to a target color. There is a nil check which it'll visit every time to see if it can skip the activation price. Now it gets handed to the target palette to encode it as an integer value again. Scale the the values out of their 13bit space, bitAnd: them, bitShift: them, you end up with an integer representation from the new pallete. Now you get to tell the target image to at:put: that integer. Which means ripping it into 4 byte piece components, and using at:put: 4 times on the target byte array. It's a nice journey.

But hey. Cycles are cheap. Who cares? At least the thing works, right? Well, it does until you start putting alpha information in that X byte slot. Things go wrong then. That first step, where we create an integer from the source image. If your alpha channel has the top 2 bits set... you've just stepped into LargeInteger land, as much as 60x slower than SmallInteger on some of these apps. And thrashing for the collector. But even if you don't, an even more fundamental problem shows up. When you ask the Palette for the color that goes along with that integer, it uses the at:ifAbsent: method. This method assumes that the maximum value you might ask the palette for is the highest shifts highest bit, bitInverted. So every time, it has to shift all of its masks, or: them all together, invert that, and and: with the candidate value. Every time. And if your integer is doesn't and: 0 against that, it's assumed to not be there. Even though if you sent at: it would indeed come up with the right encoding. So any pixel with an alpha value greater than 0, will be found to be absent: in the target palette, and in that case, it decides to look up the encoding of ColorValue black. Leaving the end programmer wondering why in the heck his image is showing up all black

I've proposed a fix for this. It's called FixedPaletteFixes and is in the OpenRepository (I liked the name "FixedPaletteFixed" better, but a colleague who is trying to teach me that communication trumps cute, prevailed). In case it causes concern that this might break something fundamental, this fix is in CoolImage, and has been there since VW2.5. And no one's had any problems with it yet.