On Thu, Aug 6, 2009 at 1:47 PM, Joel Webber <[email protected]> wrote: > On Thu, Aug 6, 2009 at 1:40 PM, Matt Mastracci <[email protected]>wrote: > >> +1 This works well for us and I'd love to remove the complexity from our >> build process. We've dropped the transparency loader for some time now and >> it's solved a lot of our IE6 bugginess (including random hard browser >> lockups!). >> > > Excellent. That's as good an existence proof as I need. > > On 6-Aug-09, at 11:29 AM, Joel Webber wrote: >> >> >> If we want to support IE6 fully (which I hate having to do, but it's hard >> to argue with the fact that it still account for ~20% of the market, >> depending upon whose stats you use), then I think this is basically the only >> approach that will work. We all agree that the DirectX filter is far too >> memory hungry, especially on the old machines that are often still running >> IE6. Bundling images with disparate palettes into a single 8-bit image is >> far too unpredictable, which seems pretty unacceptable to me. So I will >> argue that we should, on IE6: >> - Leave GIFs alone. >> >> - Turn PNGs with transparency into GIFs. >> - Open question: How should we clamp the [0, 255] alpha channel to [0, >> 1]? >> >> >> In our experience, every transparency clamping preset will result in >> artifacts in IE6 for some subset of images. To simplify things, I'd suggest >> mapping alpha of 0 to transparent, and alpha of 1-255 -> opaque. If the >> developer needs more control, they can convert the image to a GIF by >> hand. Alternatively, it might be useful to allow a developer to specify a >> fallback IE6-only image. >> >> For quantization of partially transparent PNG to GIF, I highly recommend >> the algorithm behind this tool: >> http://members.ozemail.com.au/~dekker/NEUQUANT.HTML There's already a >> Java version of the code available. >> > > Looks like it's being used in javax.media.jai. If that's available to us > reliably, then we should probably use it. > > Side note: God, I thought I would never have to think about this problem > again after everybody finally dropped their old VGA cards, and we could at > least just deal with 5-5-5 vs. 5-6-5 16-bit color modes in all our assembly > code. Wait, did I just date myself pretty badly? >
Side side note: Holy crap, I just realized that NeuQuant uses a Kohonen network to iteratively converge on a palette. No wonder it works so much better. But does it end up taking a really long time to converge? I'd hate to make the build take forever because it's waiting on a neural network to converge :) --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
