Topic awaiting preservation: IE 5.x+ "slow" :hover performance (Page 1 of 1)

Maybe it's just my computer (I would hope not), but on some CSS-heavy sites I've noticed that menus using :hover pseudoclasses redraw (change state) very slowly - taking 0.5 seconds when it should be practically instantaneous.

A block-level link with a border, small non-repeating background image and background color change on :hover seems to be slow in IE on my dev machine (a Celeron 433), when the same code is fine in Mozilla or Opera. Faster computers are fine, but I do notice a CPU spike if you mouse over a bunch of items quickly.

I suspect the background image, not sure though. Has anyone looked into this kind of behavior before?

(Doing a simple test, I have found the background image makes a big difference. It seems nested elements also appear to affect performance.)

Thinking this over, this may be better in the CSS area

[This message has been edited by Scott (edited 02-02-2004).]

I haven't noticed a huge problem with css on it's own - but I know that css (especially in IE) has quite a large knock on effect on javascript functions - I have been fiddling with image scrollers for about year now and I have noticed that their responsiveness, smoothness and speed are hammered if a lot of css effects are happenin or if if I'm trying to scroll elements with css applied on them. I would agree that background image is a big cpu drainer, however I've never noticed a large problem with css borders.

I also pointed out to you before (via email) that your panorama doobree works nice and smooth until the css / custom cursor loads in and then the things slows right up (for me at least).

At the end of the day IE is shite - but then we already knew that didn't we...

<A HREF="http://www.cryokinesis.co.uk" TARGET=_blank>visit

IE has a bug where it reloads background images on elements when you do certain things with css/script, that's what makes it slow. For instance, moving an absolutely positioned element around, showing/hiding elements (or toggling display between block/none). I suspect that about anything will reload the images. Maybe if you use the images as list-style-image that they might stay put... haven't tried that yet.

peterned

Ah-ha, good points from both of you.

smonkey, I suspect my panoramic image thing is related to either CSS or the loading of those cursor images (they are actually .cur files defined by CSS, and switched out by javascript on the fly if I remember correctly.) Nonetheless, a problem. It might be that it's reassigning the .cur every "frame" of animation, maybe a bug - haven't looked. Seems to be OK on my celeron 433 though (my baseline for dev), so I haven't really investigated. May be related to this strange performance issue.

I'll see if a list-style-image rule may help. It's possible - It looks like the number of nested elements and background images are the main culprits from what I have tried so far. Unfortunately the nav in the site I'm working on is quite slow - the test stuff I've extracted isn't much faster unless I remove the background images and nested elements, and even then it's still somewhat "iffy". An annoyance.

I think also (speaking to peterned's point), IE has a caching bug when set to something other than "automatic(ally)", ie "every visit to the page" when DHTML or CSS causes anything containing an image or background image to change - it reloads instead of pulling from the cache.

I would think "every visit" means each "session", eg. once the image has loaded for that particular viewing of the page it should be cached - but apparently not. Stuff like my DHTML Arkanoid project is pretty much unplayable with that setting.

My browser doesn't seem to have issues with caching, when I have it set to "automatic", although I do notice a slight flicker on occasion and the cursor changing to an hourglass very quickly when background images are being swapped out.

Thinking out-loud here, it's possible that just moving the background image out of the way may solve part of the performance issue (rather than swapping it out to "nothing" entirely) - kind of like what the guy at pixy.cz did for swapping images without loading a different image.. adjust the coordinates of it instead.

Anyhow.. Sounds like there isn't any solid pattern to this performance-related behavior.. any other guesses?


[This message has been edited by Scott (edited 02-03-2004).]