Interesting Windows IE/Firefox Applet Rendering Bug
A few days ago, a couple of developers stopped by to ask me if I'd seen a problem with the VantagePoint graph initialization when used in applets. Basically, an applet built using the VantagePoint graphs would initialize quickly (sub-second) when only one core was available to IE. Add a second core, and the initialization time stretched out. In fact, adding successive cores stretched out the time so much that at four cores the initialization time was measured in minutes. Clearly, there was a problem. Their initial assessment was that the locking and unlocking of the VantagePoint data tables was the culprit, but I told them that knowing the guys who built it, I doubted that - but I sent them an email just in case.
Today, one of the developers gave me an update and it turned out that it wasn't just IE. Firefox had the same behavior. The other developer had created simply HTML files that would show the problem. So I decided to get that file and see what I could see for myself.
Interesting problem.
It turns out that it's not the locking and unlocking, it's the redrawing that's done after the unlocking that's causing the problem. What was happening was that every additional data point added (parsed from the applet's param tags) was causing a redraw, and Windows was trying to slice things in between the redraws and that was causing the slowdown. Even after I put a lock around the entire data parsing, the delay simply moved to the parsing and setting of the graph's structure.
The solution was to hold-off on all redraws while parsing all the applet's param tags. Then, after it's all set-up and ready to go, unlock the graph and let it redraw the viewport once. This made the four core initialization faster than the old single core because no redraws were being done at all. Since this is a time that you really don't need to look at the intermediate results, it seems like a reasonable compromise.
What amazes me is that Windows isn't smarter about this. When multiple cores are available, Windows should improve performance not have it get worse. This might be as simple as upgrading the video drivers - who knows, but the fact that an applet in a browser is causing this kind of problem for Windows is amazing. Anyway... the code in BKit is fixed and the developers are back at it loading faster than ever.