Mouseover event speed IE6, IE7 and IE8

[GoogleCodeExporter]

When viewing this example -
http://chujoii.googlepages.com/manualsearchpeak.html - the crosshair is
perfectly responsive in Firefox 2 and 3 (windows and mac) and Safari
(latest), but in IE6, IE7 and IE8 it is slow. For some reason IE6 is a
better performer than IE8.

Original issue reported on code.google.com by wbruc...@gmail.com on 2 Jul 2009 at 3:00

[GoogleCodeExporter]

IE is always slower, but yes, in that example it's unreasonably slow. I've 
recently
pulled the crosshair into a plugin. If you'd like to help and gain eternal 
glory :),
see if you can find out what part of the code IE is choking over. I hear that 
IE8 has
a profiler built-in. Otherwise it's probably easiest to comment out some parts 
and
see what happens.

Original comment by olau%iol...@gtempaccount.com on 2 Jul 2009 at 3:43

[GoogleCodeExporter]

The flot chart we have just built uses the crosshair plugin and is a bit faster 
than
the example, but its still a far cry from the realtime speed of firefox and 
safari.
We're keen for the 'eternal glory' tag, but won't have the time to tackle it 
until
the end of the year. So, hoping there's someone else out there thats up for the
challenge. Anyone?

Original comment by wbruc...@gmail.com on 3 Jul 2009 at 1:27

[GoogleCodeExporter]

wbruceis,

Stumbled upon this issue while searching for a solution to the exact same issue 
I am
having. When I went to your example in IE7, it was immediately responsive, as 
is the
example with the tooltip on the flot page. Is there something that you did to 
solve
this issue? I'd appreciate any help you could offer!

Thanks,

BFH

Original comment by deusprim...@gmail.com on 4 Sep 2009 at 11:13

[GoogleCodeExporter]

Hi deusprimus1,

No, we still haven't solved the issue. We tried to outsource the issue on 
getafreelancer.com but had no luck. I'm not sure why you thought the example 
was 
immediately responsive in IE7 as it is still very 'jumpy' for us. When you move 
your 
cursor slowly, but continuously does the crosshair follow without jumping?

Otherwise, did you manage to find a solution?

Original comment by wbruc...@gmail.com on 11 Sep 2009 at 5:02

[GoogleCodeExporter]

wbruceis,
I too am using Flot for an analysis application and have same issue as bought 
up by
you in this thread. I'd appreciate if you could tell if this problem was finally
solved for you (by your service provider on GAF)? 

Regards.

Original comment by omkan...@gmail.com on 23 Oct 2009 at 12:12

[GoogleCodeExporter]

Hi omkanwar,

No, we haven't solved the issue yet. The GAF service provider accepted the job, 
but
then dropped all communication, and I haven't pursued the issue with any other 
providers.

I hope you can take up the mantle!

Original comment by wbruc...@gmail.com on 23 Oct 2009 at 12:17

[GoogleCodeExporter]

wbruceis,
Thanks for your reply.

I will let you know if I get into solving this issue and have any luck. 

Regards.

Original comment by omkan...@gmail.com on 23 Oct 2009 at 1:07

[GoogleCodeExporter]

Thanks omkanwar, much appreciated.

Original comment by wbruc...@gmail.com on 23 Oct 2009 at 1:10

[GoogleCodeExporter]

I think I may have discovered the issue:

In IE, it seems that mouseover events can prevent setTimeout callbacks from 
firing.

If you look at the crosshair plugin implementation, it calls 
plot.triggerRedrawOverlay() inside the mousemove event handler. 

And if you look at triggerRedrawOverlay, it does this:
redrawTimeout = setTimeout(drawOverlay, 30);

So I think what is happening is that drawOverlay is simply not being called 
until 
mouse movement pauses, giving the appearance of sluggishness.

As a test, I modified triggerRedrawOverlay to directly call drawOverlay, and 
the 
crosshair performance on IE improved considerably (although still slower than 
on 
Firefox/Chrome)

I don't know what other implications there are for removing that setTimeout 
call, so 
perhaps a better alternative would be to make drawOverlay public, so that the 
crosshair plugin can call it directly, instead of triggerRedrawOverlay.

A third option would be to introduce an option to the Plot object that 
determines 
whether calls to triggerRedrawOverlay use setTimeout or call drawOverlay 
immediately.

Original comment by dpoin...@gmail.com on 21 Apr 2010 at 11:36

[GoogleCodeExporter]

Hi dpoineau,

Thanks for that. We'll try your suggestions on our end and let you know how we 
go.

Original comment by wbruc...@gmail.com on 21 Apr 2010 at 11:49

[GoogleCodeExporter]

I think the problem in the first example is plainly that it is doing too much 
on each plothover event. They used to be rate-limited from inside Flot to 
prevent this kind of issue, but aren't anymore because that turned out to be a 
bit too restrictive (that change is long ago, though).

Since you get a great deal of events in no time with mousemove, if you're too 
slow in the callback, it's going to look sluggish. "Too slow" of course depends 
on the speed of the Javascript engine, which is probably why IE is so bad here 
(plus as dpoineau points out, it seems IE's event mechanism doesn't interact 
with this so well).

So I believe the solution is to insert a setTimeout rate limit mechanism in the 
callback, and hence will close this now.

Regarding the idea of being able to control the redraw overlay timeout: I don't 
see why not, so I've added support for setting the timeout just now. You can 
pass in -1 to redraw immediately without getting into the event queue.

Original comment by olau%iol...@gtempaccount.com on 13 May 2011 at 12:09

• Changed state: Done

[GoogleCodeExporter]

@dpoineau:

I tried changing the plot.triggerRedrawOverlay() to call drawOverlay() directly 
in my project and I thought I would share "what other implications there are 
for removing that setTimeout call".  I also have the "selection" plugin and 
when I made this change, it resulted in an inability to select on the flot 
without a couple attempts first.  So, I agree with your better alternative to 
have the "crosshair" plugin call drawOverlay directly.  Switching back the 
setTimeout resolved this problem.

Thanks all!

Original comment by brett.ha...@gmail.com on 1 Sep 2011 at 4:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I also changed plot.triggerRedrawOverlay() to call drawOverlay() directly and 
tested out "selection" plugin and it was fine.  Selection plugin actually 
performed better.

Original comment by gsh...@yahoo.com on 28 Sep 2011 at 6:10

[GoogleCodeExporter]

Original comment by dnsch...@gmail.com on 4 Jun 2012 at 2:52