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 Tamplin<j...@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
-~----------~----~----~----~------~----~------~--~---
