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
-~----------~----~----~----~------~----~------~--~---
