[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
Hi, As for the question on adding another permutations... I think that adding an ie7 permutation might be not necesarry. I posted a small example on how I handle ie6/7(or 8 in ie7 mode) in my application... it just means a small extra indirection but the cost is very low. It's not like we are creating ImageBundles in a tight loop in our applications (that is a bit against the whole idea of using them in the first place). Your remark just made me think to something. The problem with extra permutations is mainly compile time. When 2 permutations are very close to one another (a lot of deferred binding will lead to the same implementation for the 2 permutations), dynamic selection through indirection might not be that costly in performance. There is also a loss because of some optimization that will not take place, but one will have to accept that. Then GWT could have an option to say that such and such permutation must be separated at runtime instead of compile time. That will allow the compilation to be as quick as now, but the designers will still be able to use the deferred binding mechanism to handle ie6/ie7 (for example). Moreover, one can imagine an option to have all permutations separated at runtime for speeding up the compilation in development mode. Did I miss something obvious? -- Benjamin Lerman --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
On Fri, Aug 7, 2009 at 9:57 AM, Benjamin Lermangoogle+goo...@ambre.net wrote: Hi, As for the question on adding another permutations... I think that adding an ie7 permutation might be not necesarry. I posted a small example on how I handle ie6/7(or 8 in ie7 mode) in my application... it just means a small extra indirection but the cost is very low. It's not like we are creating ImageBundles in a tight loop in our applications (that is a bit against the whole idea of using them in the first place). Your remark just made me think to something. The problem with extra permutations is mainly compile time. When 2 permutations are very close to one another (a lot of deferred binding will lead to the same implementation for the 2 permutations), dynamic selection through indirection might not be that costly in performance. There is also a loss because of some optimization that will not take place, but one will have to accept that. Then GWT could have an option to say that such and such permutation must be separated at runtime instead of compile time. That will allow the compilation to be as quick as now, but the designers will still be able to use the deferred binding mechanism to handle ie6/ie7 (for example). Moreover, one can imagine an option to have all permutations separated at runtime for speeding up the compilation in development mode. Did I miss something obvious? Sounds like an interesting proposition, but is it really needed: I tend to limit the number of permutations in development. I'm not running multiple browsers at the same time. David --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
On Fri, Aug 7, 2009 at 3:57 AM, Benjamin Lerman google+goo...@ambre.netgoogle%2bgoo...@ambre.net wrote: When 2 permutations are very close to one another (a lot of deferred binding will lead to the same implementation for the 2 permutations), dynamic selection through indirection might not be that costly in performance. There is also a loss because of some optimization that will not take place, but one will have to accept that. We already do this for runtime locales. For example, look at the Showcase sample in trunk. It only has 5 compile time locales for 25 permutations, but you get country-specific number/date/time formats and currency information for far more locales than that. The generated code is smart about which locales are equivalent for pieces of this and produces code to choose between only the individual implementations that are possible in a given permutation at runtime. Note that this is only viable where you don't have different translations for the different runtime locales, though you could imagine extending this concept to handle a small number of differences efficiently, the same way the currency data/etc is handled now (if you had most of the translations different it wouldn't be useful because the strings can wind up taking a significant portion of the compiled output). Then GWT could have an option to say that such and such permutation must be separated at runtime instead of compile time. That will allow the compilation to be as quick as now, but the designers will still be able to use the deferred binding mechanism to handle ie6/ie7 (for example). Doing it in a general way is much more complicated, because it isn't just in the compiler but to get efficient results each generator has to do the work. Moreover, one can imagine an option to have all permutations separated at runtime for speeding up the compilation in development mode. For development, you should consider having a separate .gwt.xml file which limits the web compile to a single permutation. Also, most of your development should be done in hosted mode rather than doing web-mode compiles. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
I just updated issue 3588 with the results of this discussion. Thanks, everyone. On Thu, Aug 6, 2009 at 2:53 PM, Matt Mastracci matt...@mastracci.comwrote: On 6-Aug-09, at 12:04 PM, Joel Webber wrote: On Thu, Aug 6, 2009 at 1:47 PM, Joel Webber j...@google.com wrote: 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 :) NeuQuant was pretty fast in all of my experiements. For our build pipeline I actually ended up using pngquant instead of NeuQuant because of the difficulty getting NeuQuant to process transparency. I haven't tested the JAI version of it, but the NeuQuant version linked on that website completely ignores transparency. On top of that, I was having trouble getting Java to output IE-transparency-compatible PNG files. It also seemed like I had to construct PNG files by hand with a very specific set of chunks to get IE to recognize them, meaning I had to skip the convenience of ImageIO PNG output . The output quality is great, but the hoops I had to jump through to hook it into the pipeline forced me to drop it. Dither like it's 1999! --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
Sven,
I fully support the idea of fixing this issue one way or another, and I'm
pretty strongly in favor of providing an efficient-if-not-pretty
implementation on IE6 (which I believe is what you're proposing as well).
There are two separate issues we need to consider here. The first is exactly
*what* ImageResource should do on IE6. I see several options:
- The status quo: Keep using the DirectX filter and let it blow lots of
memory.
- (At the very least, make this *not* happen on IE7; c.f. issue 3588)
- Create opaque PNGs on IE6.
- Is the background color controllable?
- We could at least stick with GIF if all the input images are GIF.
- Note that this isn't perfect: You'll still get color space
quantization when you mix the GIF palettes.
- Coerce strips to GIFs, and deal with the ugly color space quantization.
- We could try and be sneaky, looking for transparency and segregating
transparent and opaque images into separate resources.
The second question is whether we should implement this by separating IE6
and IE7 into separate permutations, or whether we should do a runtime check.
All else being equal, I would favor creating separate permutations, because
it makes the code cleaner, and a little bit smaller/faster on IE7. All else
is not quite equal, though: creating a new permutation has a non-trivial
impact on compile times and output directory size, especially for apps with
a large number of locale permutations (as many at Google are). I'm leaning
towards runtime tests for this particular case, for the following reasons:
- IE7 is not going to evolve any further, so we know that the set of
differences between 6 and 7 are bounded.
- The relevant differences that I'm aware of are only these:
- PNG transparency bug.
- Peekaboo bug in divs overlapping select elements.
- CSS absolute-positioning fixes ({top:0; bottom:0;} works correctly on
IE7, but not IE6)
- The only other differences seem to be performance-related (such as
bumping up the GC thresholds).
*Not* creating an extra permutation for IE6 gives us a bit more latitude to
create another later (we're going to have to do something for mobile
browsers soon, I suspect).
What say you all?
joel.
On Wed, Aug 5, 2009 at 12:07 PM, Sven Brunken s...@extjs.com wrote:
The current implementation of the ImageResourceGenerator works very
well for most of the browsers. However in IE6 you have the problem
that it will convert everything to the PNG format (also if it was a
GIF before). In IE6 you will need to add a filter to display
transparent PNGs correctly. Theses filters consume a lot (too much)
memory. If you have a couple of them on your page, your page will be
unusable very fast. The ImageBundle support in older GWT versions also
has this problem. However this should be fixed.
There is a solution for this:
ImageResourceGenerator should not change the format to PNG if we have
a GIF. IE6 can display transparent GIFs very well. The problem is that
GWT handles IE6 and IE7 the same. IE7 can handle transparent PNGs. So
for the best output for this solution we would need to add another
deferred binding for IE7. The ResourceContext interface would get
another method supportsTransparentPNG (like supportsDataUrls).
IE7 could use the MhtmlResourceContentext and return true for that
method. IE6 would return false (we would have two
MhtmlResourceContentext which are almost the same). The
ImageResourceGenerator would than decide how to handle the image (like
it already checks now for support of data urls).
I really think this should be handled within GWT. For the current GWT
releases we have overrides in place to fix the memory usage at least
in IE7 as we can use PNGs there without filters. The normal
implementation of GWT sets up filters also in IE7.
I could do the changes and would contribute them back to you. What do
you think?
Sven Brunken
Ext GWT Core Developer
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
Hello Joel,
thanks for your answer. Yes another permutation has bad impact on
compile time. I only suggested that because than we could still use
the normal ImageResource support in IE7 and only IE6 would stay with
the GIF format if we had a GIF image before. If the user defined a PNG
image we would not convert them to a GIF but setup a filter for that
image. So PNG images could still be bundled. The
ImageResourceGenerator should only handle GIF images as if they would
be animated now (don’t change the image at all and don’t bundle them).
This would fix the issue without any big change (ClippedImageImplIE6
needs to be changed to only add filter for a PNG). If we don’t
introduce another deferred binding, than IE7 would also behave like
this, but IE7 could had handled it correctly.
The current implementation makes ImageResource/ImageBundle support
unusable for transparent images in IE6. If you have a desktop like
application, you will (for example) have many icons near the buttons
and all this icons would be displayed with the help of the filter and
an incredible amount of memory. This makes the application very slow
and the memory is never freed. It will be faster to load all this
icons separately instead of setting up a filter for each icon as it is
done now.
Sven
Ext GWT Core Developer
On 6 Aug., 16:02, Joel Webber j...@google.com wrote:
Sven,
I fully support the idea of fixing this issue one way or another, and I'm
pretty strongly in favor of providing an efficient-if-not-pretty
implementation on IE6 (which I believe is what you're proposing as well).
There are two separate issues we need to consider here. The first is exactly
*what* ImageResource should do on IE6. I see several options:
- The status quo: Keep using the DirectX filter and let it blow lots of
memory.
- (At the very least, make this *not* happen on IE7; c.f. issue 3588)
- Create opaque PNGs on IE6.
- Is the background color controllable?
- We could at least stick with GIF if all the input images are GIF.
- Note that this isn't perfect: You'll still get color space
quantization when you mix the GIF palettes.
- Coerce strips to GIFs, and deal with the ugly color space quantization.
- We could try and be sneaky, looking for transparency and segregating
transparent and opaque images into separate resources.
The second question is whether we should implement this by separating IE6
and IE7 into separate permutations, or whether we should do a runtime check.
All else being equal, I would favor creating separate permutations, because
it makes the code cleaner, and a little bit smaller/faster on IE7. All else
is not quite equal, though: creating a new permutation has a non-trivial
impact on compile times and output directory size, especially for apps with
a large number of locale permutations (as many at Google are). I'm leaning
towards runtime tests for this particular case, for the following reasons:
- IE7 is not going to evolve any further, so we know that the set of
differences between 6 and 7 are bounded.
- The relevant differences that I'm aware of are only these:
- PNG transparency bug.
- Peekaboo bug in divs overlapping select elements.
- CSS absolute-positioning fixes ({top:0; bottom:0;} works correctly on
IE7, but not IE6)
- The only other differences seem to be performance-related (such as
bumping up the GC thresholds).
*Not* creating an extra permutation for IE6 gives us a bit more latitude to
create another later (we're going to have to do something for mobile
browsers soon, I suspect).
What say you all?
joel.
On Wed, Aug 5, 2009 at 12:07 PM, Sven Brunken s...@extjs.com wrote:
The current implementation of the ImageResourceGenerator works very
well for most of the browsers. However in IE6 you have the problem
that it will convert everything to the PNG format (also if it was a
GIF before). In IE6 you will need to add a filter to display
transparent PNGs correctly. Theses filters consume a lot (too much)
memory. If you have a couple of them on your page, your page will be
unusable very fast. The ImageBundle support in older GWT versions also
has this problem. However this should be fixed.
There is a solution for this:
ImageResourceGenerator should not change the format to PNG if we have
a GIF. IE6 can display transparent GIFs very well. The problem is that
GWT handles IE6 and IE7 the same. IE7 can handle transparent PNGs. So
for the best output for this solution we would need to add another
deferred binding for IE7. The ResourceContext interface would get
another method supportsTransparentPNG (like supportsDataUrls).
IE7 could use the MhtmlResourceContentext and return true for that
method. IE6 would return false (we would have two
MhtmlResourceContentext which are almost the same). The
ImageResourceGenerator would than decide how to handle the image (like
it already checks now for support of data urls).
I really think
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
On Thu, Aug 6, 2009 at 10:02 AM, Joel Webber j...@google.com wrote:
I fully support the idea of fixing this issue one way or another, and I'm
pretty strongly in favor of providing an efficient-if-not-pretty
implementation on IE6 (which I believe is what you're proposing as well).
There are two separate issues we need to consider here. The first is
exactly *what* ImageResource should do on IE6. I see several options:
- The status quo: Keep using the DirectX filter and let it blow lots of
memory.
- (At the very least, make this *not* happen on IE7; c.f. issue 3588)
- Create opaque PNGs on IE6.
- Is the background color controllable?
- We could at least stick with GIF if all the input images are GIF.
- Note that this isn't perfect: You'll still get color space
quantization when you mix the GIF palettes.
Except in special cases where the combined pallette of all the GIFs still
fits in 8 bits, I think this is not acceptable -- personally, I would rather
have by transparent borders become non-transparent.
I think if you want to keep them as GIFs, you need to do it 1:1 -- ie, on
IE6 you simply don't get bundling. You could get fancy and combine them
where the GIFs don't use all their pallette, but I suspect the gain is not
worth the effort.
The second question is whether we should implement this by separating IE6
and IE7 into separate permutations, or whether we should do a runtime check.
All else being equal, I would favor creating separate permutations, because
it makes the code cleaner, and a little bit smaller/faster on IE7. All else
is not quite equal, though: creating a new permutation has a non-trivial
impact on compile times and output directory size, especially for apps with
a large number of locale permutations (as many at Google are). I'm leaning
towards runtime tests for this particular case, for the following reasons:
- IE7 is not going to evolve any further, so we know that the set of
differences between 6 and 7 are bounded.
- The relevant differences that I'm aware of are only these:
- PNG transparency bug.
- Peekaboo bug in divs overlapping select elements.
- CSS absolute-positioning fixes ({top:0; bottom:0;} works correctly on
IE7, but not IE6)
- The only other differences seem to be performance-related (such as
bumping up the GC thresholds).
Data seems to indicate that IE7 is being replaced with IE8 faster than IE6
is, so I think it is acceptable that the IE6/IE7 permutation have additional
runtime overhead of detecting which version is running and altering behavior
accordingly.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
Hi,
Since I was asking for some better IE7 support I might as well budge
in and give my opinion.
For me it is acceptable that the IE6 is slow and leaks memory -
everybody accepts that by now :-).
If the compiler could however detect if transparency is needed than
the whole DirectX filter could be avoided. But in reality, we use
transparency all over the place. Most of the transparency is just
binary so a GIF would be capable of handling this. The banding issues
are ofcourse a potential problem, but all our icons use the same color
palette - so I think that we won't notice.
Alternatively you could just decide to drop transparency support in
IE6. If you want transparency then upgrade the browser to something
newer. The icons will look bad, but developers who need transparency
in IE6 should maybe not use the ImageBundle ?
As for the question on adding another permutations... I think that
adding an ie7 permutation might be not necesarry. I posted a small
example on how I handle ie6/7(or 8 in ie7 mode) in my application...
it just means a small extra indirection but the cost is very low. It's
not like we are creating ImageBundles in a tight loop in our
applications (that is a bit against the whole idea of using them in
the first place).
And while on the subject of IE7: make sure that you also drop the
IFrame behind the PopupPanel! That has caused me lots of debugging
work. In our application using the IFrame adds 500ms to every dialog,
we need those cycles to build our dialogs faster! This happens when
the application is running on HTTPS.
David
On Thu, Aug 6, 2009 at 4:26 PM, John Tamplinj...@google.com wrote:
On Thu, Aug 6, 2009 at 10:02 AM, Joel Webber j...@google.com wrote:
I fully support the idea of fixing this issue one way or another, and I'm
pretty strongly in favor of providing an efficient-if-not-pretty
implementation on IE6 (which I believe is what you're proposing as well).
There are two separate issues we need to consider here. The first is
exactly *what* ImageResource should do on IE6. I see several options:
- The status quo: Keep using the DirectX filter and let it blow lots of
memory.
- (At the very least, make this *not* happen on IE7; c.f. issue 3588)
- Create opaque PNGs on IE6.
- Is the background color controllable?
- We could at least stick with GIF if all the input images are GIF.
- Note that this isn't perfect: You'll still get color space
quantization when you mix the GIF palettes.
Except in special cases where the combined pallette of all the GIFs still
fits in 8 bits, I think this is not acceptable -- personally, I would rather
have by transparent borders become non-transparent.
I think if you want to keep them as GIFs, you need to do it 1:1 -- ie, on
IE6 you simply don't get bundling. You could get fancy and combine them
where the GIFs don't use all their pallette, but I suspect the gain is not
worth the effort.
The second question is whether we should implement this by separating IE6
and IE7 into separate permutations, or whether we should do a runtime check.
All else being equal, I would favor creating separate permutations, because
it makes the code cleaner, and a little bit smaller/faster on IE7. All else
is not quite equal, though: creating a new permutation has a non-trivial
impact on compile times and output directory size, especially for apps with
a large number of locale permutations (as many at Google are). I'm leaning
towards runtime tests for this particular case, for the following reasons:
- IE7 is not going to evolve any further, so we know that the set of
differences between 6 and 7 are bounded.
- The relevant differences that I'm aware of are only these:
- PNG transparency bug.
- Peekaboo bug in divs overlapping select elements.
- CSS absolute-positioning fixes ({top:0; bottom:0;} works correctly on
IE7, but not IE6)
- The only other differences seem to be performance-related (such as
bumping up the GC thresholds).
Data seems to indicate that IE7 is being replaced with IE8 faster than IE6
is, so I think it is acceptable that the IE6/IE7 permutation have additional
runtime overhead of detecting which version is running and altering behavior
accordingly.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
Dropping transparency support in IE6 is a bad idea. Too many business
people just still use IE6. Also saying that developers that need
transparent images in IE6 should not use ImageBundle is that good.
When writing my app I don’t want to care where it is running after I
finished it. It should just run and fit well in that browser.
Adding good support for transparency in IE6 is not that big and should
really be considered.
Sven
Ext GWT Core Developer
On 6 Aug., 17:02, David david.no...@gmail.com wrote:
Hi,
Since I was asking for some better IE7 support I might as well budge
in and give my opinion.
For me it is acceptable that the IE6 is slow and leaks memory -
everybody accepts that by now :-).
If the compiler could however detect if transparency is needed than
the whole DirectX filter could be avoided. But in reality, we use
transparency all over the place. Most of the transparency is just
binary so a GIF would be capable of handling this. The banding issues
are ofcourse a potential problem, but all our icons use the same color
palette - so I think that we won't notice.
Alternatively you could just decide to drop transparency support in
IE6. If you want transparency then upgrade the browser to something
newer. The icons will look bad, but developers who need transparency
in IE6 should maybe not use the ImageBundle ?
As for the question on adding another permutations... I think that
adding an ie7 permutation might be not necesarry. I posted a small
example on how I handle ie6/7(or 8 in ie7 mode) in my application...
it just means a small extra indirection but the cost is very low. It's
not like we are creating ImageBundles in a tight loop in our
applications (that is a bit against the whole idea of using them in
the first place).
And while on the subject of IE7: make sure that you also drop the
IFrame behind the PopupPanel! That has caused me lots of debugging
work. In our application using the IFrame adds 500ms to every dialog,
we need those cycles to build our dialogs faster! This happens when
the application is running on HTTPS.
David
On Thu, Aug 6, 2009 at 4:26 PM, John Tamplinj...@google.com wrote:
On Thu, Aug 6, 2009 at 10:02 AM, Joel Webber j...@google.com wrote:
I fully support the idea of fixing this issue one way or another, and I'm
pretty strongly in favor of providing an efficient-if-not-pretty
implementation on IE6 (which I believe is what you're proposing as well).
There are two separate issues we need to consider here. The first is
exactly *what* ImageResource should do on IE6. I see several options:
- The status quo: Keep using the DirectX filter and let it blow lots of
memory.
- (At the very least, make this *not* happen on IE7; c.f. issue 3588)
- Create opaque PNGs on IE6.
- Is the background color controllable?
- We could at least stick with GIF if all the input images are GIF.
- Note that this isn't perfect: You'll still get color space
quantization when you mix the GIF palettes.
Except in special cases where the combined pallette of all the GIFs still
fits in 8 bits, I think this is not acceptable -- personally, I would rather
have by transparent borders become non-transparent.
I think if you want to keep them as GIFs, you need to do it 1:1 -- ie, on
IE6 you simply don't get bundling. You could get fancy and combine them
where the GIFs don't use all their pallette, but I suspect the gain is not
worth the effort.
The second question is whether we should implement this by separating IE6
and IE7 into separate permutations, or whether we should do a runtime
check.
All else being equal, I would favor creating separate permutations, because
it makes the code cleaner, and a little bit smaller/faster on IE7. All else
is not quite equal, though: creating a new permutation has a non-trivial
impact on compile times and output directory size, especially for apps with
a large number of locale permutations (as many at Google are). I'm leaning
towards runtime tests for this particular case, for the following reasons:
- IE7 is not going to evolve any further, so we know that the set of
differences between 6 and 7 are bounded.
- The relevant differences that I'm aware of are only these:
- PNG transparency bug.
- Peekaboo bug in divs overlapping select elements.
- CSS absolute-positioning fixes ({top:0; bottom:0;} works correctly on
IE7, but not IE6)
- The only other differences seem to be performance-related (such as
bumping up the GC thresholds).
Data seems to indicate that IE7 is being replaced with IE8 faster than IE6
is, so I think it is acceptable that the IE6/IE7 permutation have additional
runtime overhead of detecting which version is running and altering behavior
accordingly.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
On Thu, Aug 6, 2009 at 11:02 AM, David david.no...@gmail.com wrote: If the compiler could however detect if transparency is needed than the whole DirectX filter could be avoided. But in reality, we use transparency all over the place. Most of the transparency is just binary so a GIF would be capable of handling this. The banding issues are ofcourse a potential problem, but all our icons use the same color palette - so I think that we won't notice. If the transparency is just binary, then IE6 already supports PNG transparency, right? Aside from the hassle of detecting if a one-bit alpha channel will do, I think the J2D libraries we currently use won't generate one-bit alpha channels (I could be remembering incorrectly however), so we would have to find something else. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
On Thu, Aug 6, 2009 at 11:20 AM, Sven Brunken s...@extjs.com wrote: Dropping transparency support in IE6 is a bad idea. Too many business people just still use IE6. Also saying that developers that need transparent images in IE6 should not use ImageBundle is that good. When writing my app I don’t want to care where it is running after I finished it. It should just run and fit well in that browser. Would converting transparency to single-bit alpha for IE6 work for you? Ie, a pixel is either transparent or not, no gradation (and therefore no anti-aliasing). Adding good support for transparency in IE6 is not that big and should really be considered. When you say good support, what exactly do you mean? I think it is not practical to support image bundles with transparency in the same manner as all the other browsers on IE6. Various approaches that I know of: 1. *bundling everything into one PNG keeping alpha* doesn't work in the general case due to memory requirements of the alpha filter, runtime cost of not using filter on IE7 2. *bundling everything into one GIF* doesn't work in the general case because you only have an 8-bit palette to share between all the images 3. *detect images with transparency and bundle them separately* works, but defeats the point of image bundles (though the user code is unchanged and works properly on other platforms), runtime cost for IE6/7 permutation 4. *encode all transparency as single-bit alpha on IE6 *lose antialiasing, keep extra image bundles just for IE, runtime cost for IE6/IE7 permutation We are currently at #1, without runtime detection of IE7. Fixing that is relatively easy. #2 seems a non-starter, though it could be useful for specific cases where palettes are small -- still since it isn't a general solution it doesn't seem worthwhile. #3 seems straightforward and will continue to work but loses the benefit of image bundles on IE6. #4, assuming I am remembering correctly that IE6 does support single-bit alpha in PNGs, seems the best compromise but the most work. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
On 6-Aug-09, at 9:57 AM, John Tamplin wrote: If the transparency is just binary, then IE6 already supports PNG transparency, right? Aside from the hassle of detecting if a one- bit alpha channel will do, I think the J2D libraries we currently use won't generate one-bit alpha channels (I could be remembering incorrectly however), so we would have to find something else. John, That's correct: IE6 supports PNG with 1-bit alpha transparency. More specifically, IE6 supports PNG files with a palette and a 100% transparent color at index 0. Java doesn't generate PNG files with this property. We have a specific build step in our environment that post-processes all the PNG files to force this. Conditional comments serve IE6 the same CSS file, but from a subdirectory that contains the IE6-processed images instead. We end up with a lot of dithering on some of our output images, but it still works on IE6. Matt. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
On Thu, Aug 6, 2009 at 12:24 PM, Sven Brunken s...@extjs.com wrote: On 6 Aug., 18:07, John Tamplin j...@google.com wrote: When you say good support, what exactly do you mean? I think it is not practical to support image bundles with transparency in the same manner as all the other browsers on IE6. Various approaches that I know of: 1. *bundling everything into one PNG keeping alpha* doesn't work in the general case due to memory requirements of the alpha filter, runtime cost of not using filter on IE7 2. *bundling everything into one GIF* doesn't work in the general case because you only have an 8-bit palette to share between all the images 3. *detect images with transparency and bundle them separately* works, but defeats the point of image bundles (though the user code is unchanged and works properly on other platforms), runtime cost for IE6/7 permutation 4. *encode all transparency as single-bit alpha on IE6 *lose antialiasing, keep extra image bundles just for IE, runtime cost for IE6/IE7 permutation We are currently at #1, without runtime detection of IE7. Fixing that is relatively easy. #2 seems a non-starter, though it could be useful for specific cases where palettes are small -- still since it isn't a general solution it doesn't seem worthwhile. #3 seems straightforward and will continue to work but loses the benefit of image bundles on IE6. #4, assuming I am remembering correctly that IE6 does support single-bit alpha in PNGs, seems the best compromise but the most work. With good support I mean transparency support without consuming that much of memory for each image. Point 3 is what I thought of. If a user defines a GIF image as source, we don’t bundle it for IE6/7. We just handle it as we are handling the animated images. If the user however defines a PNG image or JPEG image than he would have the real bundle and needs to add the filters (only for PNG). The only change would be that if you have a GIF image it would not be transformed and bundled for the ie6 deferred binding. With this approach we don’t loose any quality of the original image. We would use the real imagebundle for everything that is not a GIF image. GIF images would be served as standalone image. But looking into the gain you get from this (memory usage and application speed) this is the way to go (in my opinion). 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]? - Bundle only those images without transparency into PNGs. - Stop using the DirectX filter altogether. Does anyone have any really strong objection to this approach? It will add some extra requests on IE6 under some circumstances, but that's got to be better than either (a) completely mangling bundled images, or (b) blowing massive amounts of memory. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
On Thu, Aug 6, 2009 at 1:29 PM, Joel Webber j...@google.com 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. Even those without transparency? - Turn PNGs with transparency into GIFs. - Open question: How should we clamp the [0, 255] alpha channel to [0, 1]? If we have to do that anyway, why not just make them 1-bit alpha PNGs? - Bundle only those images without transparency into PNGs. - Stop using the DirectX filter altogether. Does anyone have any really strong objection to this approach? It will add some extra requests on IE6 under some circumstances, but that's got to be better than either (a) completely mangling bundled images, or (b) blowing massive amounts of memory. If we leave all GIFs alone, I suspect that will remove image bundle benefits on IE6 in most instances. I am not sure why we need to leave them alone if they don't have transparency -- why not treat them as we do today? -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
On Thu, Aug 6, 2009 at 1:39 PM, John Tamplin j...@google.com wrote: On Thu, Aug 6, 2009 at 1:29 PM, Joel Webber j...@google.com 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. Even those without transparency? Sorry, I wasn't clear. I meant just those without transparency (see below). - Turn PNGs with transparency into GIFs. - Open question: How should we clamp the [0, 255] alpha channel to [0, 1]? If we have to do that anyway, why not just make them 1-bit alpha PNGs? I actually don't care. I just thought someone said that it was hard to get Java2D to spit out a 1-bit alpha PNG. - Bundle only those images without transparency into PNGs. - Stop using the DirectX filter altogether. Does anyone have any really strong objection to this approach? It will add some extra requests on IE6 under some circumstances, but that's got to be better than either (a) completely mangling bundled images, or (b) blowing massive amounts of memory. If we leave all GIFs alone, I suspect that will remove image bundle benefits on IE6 in most instances. I am not sure why we need to leave them alone if they don't have transparency -- why not treat them as we do today? By Bundle only those images without transparency into PNGs., I actually meant to address this. If they don't have transparency, bundle them as we always have. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
On Thu, Aug 6, 2009 at 1:40 PM, Matt Mastracci matt...@mastracci.comwrote: +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? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Better support of IE6 for ImageResourceGenerator
On Thu, Aug 6, 2009 at 1:47 PM, Joel Webber j...@google.com wrote: On Thu, Aug 6, 2009 at 1:40 PM, Matt Mastracci matt...@mastracci.comwrote: +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 -~--~~~~--~~--~--~---
