IE7 / IE8 emulation mode very slow table 1000 rows qTip from function

[Dotnetshadow]

Hi there,

Firstly excellent plugin, keep up the great work. I am currently using the latest trunk release as of 27th May

Currently I have a table that has 1000 rows spanning about 5 columns. On one of the columns I need to add the qtip tooltip. To optimize the process I decided to create the tooltip via a function so the tooltip only gets created when you mouseover instead of binding 1000 qtips on document.ready.

This seems to work perfectly in Firefox 3, IE8 with the qTip showing up instantly but in IE7 or IE8 with IE emulation mode it takes more than 5 seconds for the tooltip to appear, even longer as you move down the table. It's as if it's looping through the elements to find where the tooltip needs to be displayed.

I also did further tests by removing some columns from the table so I was left with only 1 column and this seemed to speed up the qTip creation. Just wondering why it would be so slow?

I have been using the following code:

HTML - column in a row

JS Code

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" /> <-- IE8 emulation mode
 
<div class="user" o<strong></strong>nmouseover="ShowUserInfo(this, '<%# Eval("Username").ToString() %>');">ABC</div>

Qtip code:

JS Code

function ShowUserInfo(item, username) {
 
            $(item).qtip(
            {
                content: username,
                show: {
                    solo: true,
                    when: 'mouseover',
                    effect: { type: 'slide', length: 0 },
                    ready: true                   
                },
                hide: {
                    when: 'mouseout',
                    effect: { type: 'fade', length: 0 },
                    fixed: true
                },
                position: {
                    corner: {
                        target: 'rightMiddle',
                        tooltip: 'leftMiddle'
                    },                
                    target: false,
                    adjust: { mouse: false, scroll: false}
                },
 
                api: {
                  onHide: function() {
                    $(item).qtip('destroy');
                  }
               }
 
            });
        }

Is there something special about how IE8 creates the tooltip that is slowing it down?

Regards DotnetShadow

[Craig]

Dotnewshadow,

This is most likely to do with the way in which IE7 emulation is handled through IE8, as at the moment all event handlers are assigned at page load, which can create delays in older browsers, and as you said emulation of older browsers. I'd recommend not using IE7 emulation if possible, as there is no way round this unfortunately.

In the 1.1 release which is due out over the coming months I plan on moving over to event delegation which should results in massive increases in performance for the library as a whole, but until that time I'm afraid there isn't a quick fix solution.

[jovinhan]

Dotnetshadow,

I also encountered this issue in IE. One thing that helped in my case was to launch the qTip initialization on another thread in the document.ready event. That way, the page load completes for the user before the tooltips are initialized, which is good enough in most cases. Craig, it would be great if you could implement this as an initialization option, I suspect it will be a common issue.

Example:
$(document).ready( function() { setTimeout( 'initializeTooltips();', 0 ); });

function initializeTooltips()
{
$('.myItem').qTip( 'you get the idea' );
}

[Dotnetshadow]

jovinhan Wrote:Dotnetshadow,

I also encountered this issue in IE. One thing that helped in my case was to launch the qTip initialization on another thread in the document.ready event. That way, the page load completes for the user before the tooltips are initialized, which is good enough in most cases. Craig, it would be great if you could implement this as an initialization option, I suspect it will be a common issue.

Example:
$(document).ready( function() { setTimeout( 'initializeTooltips();', 0 ); });

function initializeTooltips()
{
$('.myItem').qTip( 'you get the idea' );
}

Thanks for your suggestion cool tip. The only problem is that I'm not even initializing the tooltip on page load. I only create the tooltip once a person mouseovers an item. Therefore it should be creating it on demand.

[Dotnetshadow]

craig Wrote:Dotnewshadow,

This is most likely to do with the way in which IE7 emulation is handled through IE8, as at the moment all event handlers are assigned at page load, which can create delays in older browsers, and as you said emulation of older browsers. I'd recommend not using IE7 emulation if possible, as there is no way round this unfortunately.

In the 1.1 release which is due out over the coming months I plan on moving over to event delegation which should results in massive increases in performance for the library as a whole, but until that time I'm afraid there isn't a quick fix solution.

The problem is that it is happening in IE7 as well not just IE8 emulation mode. Also I noticed you said "all event handlers are assigned at page load" but if you have a look at my code I'm actually only ever setting up and creating the tooltip via function. Therefore on page load nothing should be happening until I actually rollover an item, and only then should the qTip be created for that one item. But for some reason to create just that one item it is taking a very long time, even though I'm telling it exactly which item I want the qTip created on?

Regards DotnetShadow

[Craig]

Dotnetshadow,

The problem it seems is not in the library itself but actually IE8 and below's JS parsing speed. Creating the tooltips is quite complex if you have rounded corners and tips enabled, especially for IE7 and below since they both have aggravatingly slow JS parsers which causes this problem. I'm working on optimizing this in future releases, maybe even creating VML corners and tips at page load for IE and simply duplicating them for each tooltip as needed.

Lots to do in terms of optimization but for the moment there isn't really a solution to this other than to pre-render tooltips in IE after document load in the background. I know this isn't ideal at the moment, but its the only feasible way of doing it at the moment unless anyone has a better idea? I'd love to hear your thoughts.

P.S. Disregard grammar errors, currently on a Caffeine binge exam revision. Roll on 4am!

[Dotnetshadow]

craig Wrote:Dotnetshadow,

The problem it seems is not in the library itself but actually IE8 and below's JS parsing speed. Creating the tooltips is quite complex if you have rounded corners and tips enabled, especially for IE7 and below since they both have aggravatingly slow JS parsers which causes this problem. I'm working on optimizing this in future releases, maybe even creating VML corners and tips at page load for IE and simply duplicating them for each tooltip as needed.

Lots to do in terms of optimization but for the moment there isn't really a solution to this other than to pre-render tooltips in IE after document load in the background. I know this isn't ideal at the moment, but its the only feasible way of doing it at the moment unless anyone has a better idea? I'd love to hear your thoughts.

P.S. Disregard grammar errors, currently on a Caffeine binge exam revision. Roll on 4am!

hehee hope it's good coffee, I have done further investigations with this issue. I found something interesting.

Test 1:
1) Mouseover row 1 - Tooltip is created and loads (shows) - slow
2) Mouseout and go to row 2
3) Mouseover row 2 - Tooltip is created and loads (shows) - slow

Test 2:
1) Mouseover row 1 - Tooltip is created and loads (shows) - slow
2) Quickly go to row 2 while the tooltip is visibile
3) Mouseover row 2 - Tooltip is created and loads (shows) - fast

It seems the tooltip might be taking a while to hide and show, but when one is present it seems faster.

While I'm on the subject how do make a tooltip not fade or slide or anything I tried effect type:'none' but that didn't work

Edit: I just changed effect from fade to slide and it was significantly faster, so perhaps I need to make sure there are no effects

Thanks for all your hard work and effort really appreciate it

DotnetShadow

[Craig]

I have a feeling it's down to IE's VML and filter performance, especially when using opacity on elements containing VML children. As you said the workaround is to use another show/hide effect and avoid opacity use at all times.

[Dotnetshadow]

craig Wrote:I have a feeling it's down to IE's VML and filter performance, especially when using opacity on elements containing VML children. As you said the workaround is to use another show/hide effect and avoid opacity use at all times.

Just a quick question what are the effect types? Like I know there is fade, slide what else is there? what happens if you don't want an effect at all is it "off"?

Regards Dotnetshadow

[Craig]

Dotnetshadow,

If you don't want an effect simply set the effect.type to false like so:

JS Code

$('.selector').qtip({ show: { effect: { type: false } } });

Also note that this can't be written shorthand i.e. show: false, because that also sets the show event to false and causes prerendering to be enabled for all qtips resulting from the method call.

[Dotnetshadow]

craig Wrote:Dotnetshadow,

If you don't want an effect simply set the effect.type to false like so:

JS Code

$('.selector').qtip({ show: { effect: { type: false } } });

Also note that this can't be written shorthand i.e. show: false, because that also sets the show event to false and causes prerendering to be enabled for all qtips resulting from the method call.

Hi Craig,

I just tried using effect: {type: false} but I get a javascript error object doesn't support this property or method, if I try effect: {type: 'false'} no errors but the effect slides down and snaps to the point of mouseover which isn't right. I'm using the latest trunk version any ideas?

Thanks for all your help
DotnetShadow

[Craig]

Dotnetshadow

Could you please upgrade to revision 68 please? I've upgraded the code to include a check specifically for false test cases:

http://bazaar.launchpad.net/~craig.craig...runk/files