It's great, but way too slow at the moment

[GoogleCodeExporter]

I think the plugin is great and would love to use it. However, I need to 
attach it to 6 input elements on a single page and when I do it, the page 
loads/initializes for 10 seconds, which is unacceptable for me and my users.

When can we expect some plugin performance improvement? I was hoping for 
some improvement in ver. 1.1.0, but it hasn't changed.

Thanks for the great work on the plugin!

Original issue reported on code.google.com by biskup...@gmail.com on 13 Apr 2010 at 9:36

[GoogleCodeExporter]

Hello biskupski,

  I would love to address your speed concerns, and I do have some suggestions to help 
the performance. Firstly, I would like to note that the browser you are using 
makes a 
dramatic impact on the performance of the plugin, as does the version of 
jPicker that 
you are using.

  First, you want to be certain you are using the minified version, as it takes less 
time for initial parsing. Secondly, IE8 in standards mode is incredibly slow at 
this 
script for some reason I have yet to determine. I have gone through the 
profiling and 
determined that the vast majority of the time used in IE is in applying the CSS 
changes to the color map and color bar. Even IE7 is tons faster at this. 
Dragging a 
marker on the map in IE8 is always a little slow and jumpy, but in quirks mode, 
or in 
IE7 it is smooth as can be.

  I will attempt to look into this issue again today and see if I can come to any 
conclusion on a solution. As far as overall performance while running multiple 
pickers, the plugin currently creates a new instance of the picker for each 
instance 
of it on the page. This is an issue that has been on my table to address for a 
long 
time now, but I have not yet had the time to change it up to single instance 
operation.

  If you are looking for better speed, you can try to bind an inline picker on your 
page in your own draggable div, and hold a local variable as to which picker is 
active and register in the liveCallback and commitCallback events and use your 
switch 
to affect the picker in question. This is similar to the ideas I have had about 
single instance operation, but less complicated.

  I will mark this issue as started, but after looking through it, I will report back 
what I have found out, and I may be able to fix it or not. If you can reply to 
this 
and tell me which web browser and OS you are using, that would be greatly 
helpful.

Original comment by christop...@gmail.com on 13 Apr 2010 at 3:36

• Changed state: Started

[GoogleCodeExporter]

Hi,

Thanks a lot for a thorough discussion! I've been testing it on Chrome/Linux. 
I've 
been testing the minified version of the plugin. In my case, I'm pretty sure 
that the  
performance issue was related to the plugin creating a new instance of the 
picker for 
each input element. I've tried a single instance of the picker and the 
performance 
was ok. Due to the performance issue, I had to use another (far inferior) color 
picker (www.eyecon.ro/colorpicker). I'll switch to your plugin as soon as its 
performance improves.

Thanks again!

Original comment by biskup...@gmail.com on 13 Apr 2010 at 4:41

[GoogleCodeExporter]

  I am going to be publishing V1.1.2 probably tomorrow after a little more testing. I 
have dramatically sped up the initialization (all browsers) and marker dragging 
(IE 
only).

  The new code is using a window timeOut call (with 0 delay) for running the updates 
while dragging the markers across the bar or map, and will cancel previous 
calls that 
have not yet started if a new mouseMove call comes in. This makes the marker 
dragging 
in IE much better.

  Additionally, the picker initialization has been reworked into a method fired by a 
window timeOut to reduce blocking of initializations of the the next pickers.

  Also the find() method in use have been adapted for faster retrievals of the 
elements. The old code was already context specific, but ran an .eq(0) method 
after 
the search. That has changed to appending ":first" to the selector in the find 
method 
so the algorithm can use an early-out option while searching.

  Additionally, a large portion of the initialization was in creating the quickPick 
color list. It was using an append on each iteration of the loop, and attach 
the 
events. Now it merely adds all the source code up in the loop, then does a 
single 
html() method. Afterward it attaches the click event to all added elements.

  According to the IE8 Web Dev Kit Profiling feature, the initialition of the whole 
page at http://www.digitalmagicpro.com/jPicker/, which includes 9 pickers, 
decreased 
from 12,400ms to 1,251ms, about a ten fold increase in speed.

  Lastly, I also added context to every method call that needed it so that "this" is 
now longer "window" in any callback method, it will return the original DOM 
node with 
the jPicker object attached to it.

  Hope to see your comments about the change after I post it tomorrow.

Original comment by christop...@gmail.com on 14 Apr 2010 at 12:30

[GoogleCodeExporter]

V1.1.2 has now been uploaded and submitted to all locations. It includes 
dramatic speed 
increases on initialization and marker dragging. Initialization is now about 6 
times 
faster, and IE8 can now drag markers smoothly.

View the ChangeLog.txt file in the ZIP download to view all details of this 
update.

Original comment by christop...@gmail.com on 14 Apr 2010 at 7:39

• Changed state: Fixed

[GoogleCodeExporter]

Hi,

I confirm that it's much faster now. I've just switched to your picker - it's 
amazing! 
Thanks a lot!

Original comment by biskup...@gmail.com on 15 Apr 2010 at 4:55