Internet Explorer 8

[Simo Kinnunen]

Hi everyone,

As you may or may not know IE8 was released today. It's the final
version, there was no RC2. Unfortunately, despite their promises,
major VML performance issues still exist in the finished product. You
may not notice a thing if you're only replacing relatively small
amounts of text, but it gets pretty bad with even moderate amounts of
text.

The good news is that I've managed to find a workaround, but It'll
take a day or two to implement and test it. Naturally this issue gets
extremely high priority, which means that the finishing touches
of :hover are also delayed until IE8 is happy. As always, it will be a
fully backwards compatible drop-in replacement.

Hopefully this doesn't cause too much trouble for anyone.

Simo

[Michiel Sikma]

Hey Simo,

Great to hear you've found a workaround! I'm hugely disappointed with
the fact VML performance did not get improved for the final version.
Maybe they're still planning on fixing it later on. It still contains
a bunch of important bugs, after all. Microsoft wants to stay in the
browser race, so it's understandable that they'd release their browser
ahead of time.

Michiel

[MicroAngelo]

> Microsoft wants to stay in the browser race, so it's understandable that
> they'd release their browser ahead of time.

Stay in the race? I think you're being overly kind to the fat kid
wheezing along a couple of laps behind... ;o)

(and I'm only half joking...)

C.

On Mar 20, 8:31 am, Michiel Sikma <mich...@sikma.org> wrote:
> Hey Simo,
>
> Great to hear you've found a workaround! I'm hugely disappointed with  
> the fact VML performance did not get improved for the final version.  
> Maybe they're still planning on fixing it later on. It still contains  
> a bunch of important bugs, after all. Microsoft wants to stay in the  
> browser race, so it's understandable that they'd release their browser  

>

[Simo Kinnunen]

Progress so far: it's taken me the whole weekend (thanks IE8..), but
the work-around is now about 95% done. It turned out to be a lot more
difficult than expected, but fortunately enough there's only one more
bug left to deal with.

Simo

[Jonah Fox]

well done !
how does the work around work ?

[Michiel Sikma]

It works around.

Michiel

[weepy]

http://explorercanvas.blogspot.com/2009/03/new-explorer-canvas-release.html

[simo]

Hi again everyone,

I'm looking for a few beta-testers for the new version. I've uploaded
an uncompressed version to the Files section of the group (http://
groups.google.com/group/cufon/files). Some unrelated improvements were
made to the renderer, too, so most text should look now slightly
sharper in Internet Explorer. Obviously there may be some exceptions.
The new version might also be slightly faster in Internet Explorer
than the previous versions.

In case you were wondering what the issues were, these are the test I
sent to the IE team: http://cufon.shoqolate.com/tests/vml-ie8/

And here's a graph for the final version:
http://cufon.shoqolate.com/tests/vml-ie8/final/IE8_final.png

Not so pretty.

Simo

On Mar 23, 12:41 pm, weepy <jonah...@gmail.com> wrote:
> http://explorercanvas.blogspot.com/2009/03/new-explorer-canvas-releas...

[weepy]

works for me in FF and IE7

I added in 'text-stroke' :

~ line 900

var stroke = style.get("text-stroke");
if(stroke) {
stroke = stroke.split(" ")
shape.stroked = 't';
shape.strokeweight = parseInt(stroke[0]) + "px"
shape.strokecolor = stroke[1]
}
else {
shape.stroked = 'f';
}


~ line 730

var stroke = style.get("text-stroke");
if(stroke) {
stroke = stroke.split(" ")
g.strokeStyle = stroke[1]
g.lineWidth = size.convertFrom(parseFloat(stroke[0]))
g.stroke();
}

It looks pretty good - tho slightly different (IE doesn't appear to be
able to do strokes of < 1px )

[Simo Kinnunen]

The new IE8-friendlier version is now online. Like always, it's a drop-
in replacement and there's no need to regenerate any fonts.

Noteworthy things in this release:

- Full IE8 support
- Slightly improved the VML rendering engine, should make text appear
sharper

Also, if you're using very small font sizes, you might want to
regenerate the font *without* having Path Optimization enabled. You'll
get much better results. There's now a mention of this in the
generator, too.

Simo

[patte]

hi Simo,

thanks much for your work!

I have tested the new version now... I am sorry but the fonts are not
looking as good as before (version 19/3/09). I have some strange word
spacing in IE6 and the vertical strokes of some letters look very
ugly. I am still using the first a:hover enabled version with a much
better optical result in Internet Explorer.

I tried to regenerate any fonts not using path optimization but
without success regarding the not so good looking fonts in IE....
everything was great before the update - fortunately I can still use
the old scripts. By the way - I have tested them all with IE8 and they
work great including a:hover ...

patte

[Sorccu]

Hi patte,

That's weird. Could you send me a screenshot?

The IE8 fix was needed because of very poor performance with somewhat
large amounts of text.

Simo

[Sorccu]

Ok, I guess the sharpening wasn't such a good idea after all (or
having it enabled by default anyway). There will be a new version
later today that matches the old rendering more accurately. Can you
try the new version tomorrow?

Simo

[Patrick Ehrlich]

> later today that matches the old rendering more accurately. Can you
> try the new version tomorrow?

Sure!

patte ;-)



2009/3/25 Sorccu <sor...@gmail.com>:

[Simo Kinnunen]

Ok, the "new" version is now online. There may still be some subtle
differences, but it's now very close to what it used to be before the
IE8 changes.

Simo

[patte]

Hi Simo,

I like it ;-) Its nearly the same font rendering as before - some kind
of different letter spacing but i cannot say which version is the
better one.

Again, thank you very much for your great work!

patte

[Richard Fink]

Simo,

IE8 version working OK as far as I can see.
Looked at your test pages. Has the IE team responded in any way?
The performance difference being reported leaves me wondering what's
going on? big diff.
Overall javascript peformance in IE8 is much better than in IE7 -
makes me wonder where the problem lies.

> > >>>>>>>>>>>> Simo- Hide quoted text -
>
> - Show quoted text -

[weepy]

>> where the problem lies.

something esoteric in the VML engine (so not in Javascript)

[Simo Kinnunen]

Hi Richard, 

Yes, they responded very quickly and began investigating the issue. I asked what their progress was in the IE dev chat on Feb 24th:

Q: Any progress on getting IE8 VML performance on par with IE7?
A: thanks to a great test case submitted from the community, we've made some investments here after RC1. thanks!

Well, the fix just wasn't there in the final version. So I asked them again in the next dev chat (which was yesterday by the way):

Q: Just to confirm: am I doing something wrong if I still get terrible performance with absolutely positioned VML elements, or did you just not have enough time to fix it?
A: Simo-- I saw at least one checkin for the VML performance bug that you reported that brought us back into linear performance for this VML creation scenario. I'll follow up with the developer on this to see why you're not seeing the fix.

As of yet I haven't received any further information but it's only been a day, so we'll just have to wait and see.

Oh and by the way the bug is caused by absolutely positioned VML elements. Somehow they're just very slow, assuming they actually have left/top/etc set as well. VML uses absolute positioning a lot, for example all children of a VML group are absolutely positioned and this behavior cannot be changed. The group element also allowed many convenient things such as local coordinate space, but it had to go. Outside a VML group VML elements can only be positioned to full pixels, which just isn't accurate enough. So we ended up creating many VML shapes on top of each other and using the coordorigin attribute to achieve "fake" positioning. This resulted in practically no performance loss because VML - being a vector-based format - doesn't really care about the size of the canvas.

Simo

[Richard Fink]

Funny, I was at the chat, too. I remember your question but didn't put
2+2 together.
As I wrote about at Cameron Moll's site - depending upon the font,
using @font-face with the Microsoft Weft tool to create EOT files is a
scriptless solution that might make a lot more sense for IE.
Also, I'm seeing some strange behavior at Zoom levels larger than 100%
in IE and the new WebKit browsers - Safari 4B and Chrome 2B. The word
spacing is getting messed up.

rich

> ...
>
> read more »- Hide quoted text -

[Simo Kinnunen]

Hi Richard,

EOT fonts are not antialiased in Internet Explorer 6 (neither are they
in IE7 if you've turned ClearType off), which makes many typefaces
(especially calligraphic ones) nearly unreadable. This is usually not
good enough.

Thanks for letting me know about the zoom issue, I'll look into it.

Simo

[Richard Fink]

Yup. That's actually what I meant by "depending upon the font". Fonts
with lots of curves do poorly. Most san-serifs will look OK.
Serifs not as good and cursives probably poor.
However, on the plus side, EOT fonts will resize with IE's Text Size
menu - if font-size is set using ems or a style-switcher is used.
Incidentally and apropos, shortly I'll be releasing ZoomPerfect
(http://www.zoomperfect.com) which uses javascript to turn IE's Text
Size menu into a style-switcher. In this way, even text set in pixels
can be resized and so can the VML images, too.
If you need to determine Zoom levels to fix the issues, let me know.