Slow Display of Popup Calendar

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use the popup calendar code
2. Click on the popup calendar icon

I would expect it to display quickly, but instead even on a dual core
system, there is a noticeable delay between clicking on the popup icon and
the display of the calendar, almost like a lag. I tested it on several
different systems and on IE and Firefox and they all are very slow to
display the calendar.

Latest version for download as of this date on Windows XP and Windows Vista
with IE6, IE7, Firefox 2, Firefox 3.

The same slow behavior can be found on the demo page for
CalendarDateSelect, so it is nothing I had changed.

Original issue reported on code.google.com by bom...@gmail.com on 16 Jun 2008 at 8:18

[GoogleCodeExporter]

Yes, I'm aware of the delay.  It used to be worse.  It's always been fast 
enough so I haven't bothered to look into 
it.

It's really fast on Safari and Opera.  I think IE8 has improved their 
performance as well, so it'll go away there.

I'm surprised to learn it's slow in FF3.

Original comment by timchar...@gmail.com on 16 Jun 2008 at 8:50

• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

Now that I tested it some more, it is actually much faster in FF3 than it was in
FF2.x and IE6/IE7. I was mainly pondering what the delay is caused from to 
begin with.

Original comment by bom...@gmail.com on 16 Jun 2008 at 9:04

[GoogleCodeExporter]

I've also experienced slow response time on FF3 and IE7. I looked at the code a 
bit,
and it looks like the cause of the problem is the method 
"Element.buildAndAppend",
which calls "eval" for every attribute and every style sheet property of each TD
element. I've tried changing it a bit to the following code:

  var e = new Element(type, options);
  if (options && options.innerHTML)
    e.update(options.innerHTML);
  if (style) 
    e.setStyle(style);
  return e;

Which causes a performace boost of at least x4 on FF3. This seams to work fine,
except for handling events, which now need to be re-written. E.g: instead of

    this.close_button = header_div.build("a", { innerHTML: "x", href:"#",
onclick:function () { this.close(); return false; }.bindAsEventListener(this),
className: "close" });

change to:
    this.close_button = header_div.build("a", { innerHTML: "x", href:"#", className:
"close" });
    this.close_button.onclick = function () { this.close(); return false;
}.bindAsEventListener(this);

Original comment by yehu...@gmail.com on 4 Nov 2008 at 3:14

[GoogleCodeExporter]

yehudab - fantastic tip - yes, I'll be the first to admit the 
Element.buildAndAppend is slow.  I was aiming to keep  
things small, and it appears this time on a heft penalty on performance.  Would 
anyone mind making a patch 
available to pull on github?

Thanks!

Original comment by timchar...@gmail.com on 4 Nov 2008 at 3:32

• Changed state: Accepted

[GoogleCodeExporter]

I'm noticing this same issue but there doesn't appear to be 
"Element.buildAndAppend"
in the code. I do see a few "eval"s in there, though.

Has there been a new release since this issue was reported?

Original comment by brian.h...@gmail.com on 11 Nov 2008 at 7:12

[GoogleCodeExporter]

brian,
This method was called Element.build in version 1.10.x . It was renamed in 
version 1.11

Original comment by yehu...@gmail.com on 12 Nov 2008 at 3:07

[GoogleCodeExporter]

Ah, thanks. I've been trying to get the fix yehudab suggested working, however 
I suck
at JS and have been stuck here on line 175:

(this.calendar_day_grid[cell_index] = days_row.build("td", {
          calendar_date_select: this,
          onmouseover: function () { this.calendar_date_select.dayHover(this); },
          onmouseout: function () { this.calendar_date_select.dayHoverOut(this) },
          onclick: function() { this.calendar_date_select.updateSelectedDate(this,
true); },
          className: (weekday==0) || (weekday==6) ? " weekend" : "" //clear the class
        },
        { cursor: "pointer" }
      )).build("div");

Would it be too much to ask for some help figuring out moving the event handler
assignments out into separate statements?

Original comment by brian.h...@gmail.com on 12 Nov 2008 at 4:47

[GoogleCodeExporter]

Note: it looks like the slow-down is gone in Firefox 3.1b1.

Original comment by brian.h...@gmail.com on 12 Nov 2008 at 7:14

[GoogleCodeExporter]

Turned out to be easier than that, fortunately:

http://github.com/timcharper/calendar_date_select/commit/920610

Thanks for the tip!

Original comment by timchar...@gmail.com on 30 Nov 2008 at 8:49

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for the fix, Tim.

As my focus since I suggested the fix has shifted a little, I did not have time 
to
verify your code yet, but I promise to do it soon and report here.

Original comment by yehu...@gmail.com on 3 Dec 2008 at 10:26

[GoogleCodeExporter]

YEAH YEAH finally got the plugin to work but found the right info not from this 
site.  Well guess I am back to see if their is any new solution to the slow 
calendar problem.  Does not look like it as I already have 1.16 which is slow.  
Looks like jruby suffers from EXACTLY the same problems I experienced when 
trying to use a similar plugin for netbeans & the the now defunct visual 
jsf(was great until netbeans decided they wanted to get rid of it).  Anyways 
java seems to struggle to fire its younger sister javascript.  All these 
hacks/tricks won't help anything...the fact is...java is slow at even 
displaying a simple alert be it using java or jruby.  So, try not to use 
anything that is javascript related as it will simply slow down the interface 
unacceptably.  Stick with drop downs.  Yep that right 6 user inputs altogether 
for the start date & the end date.  But it's about time that users stop 
complaining & start using applications the way they are!  Oh well at least your 
tried to address a lack of a date picker in jruby & for that matter web apps in 
general...(sigh)

Original comment by petc...@gmail.com on 20 Aug 2010 at 10:42