summaryrefslogtreecommitdiff
path: root/addons/web/static/lib/jquery.deferred-queue/jquery.deferred-queue.js
diff options
context:
space:
mode:
authorXavier Morel <xmo@openerp.com>2011-09-22 10:58:12 +0200
committerXavier Morel <xmo@openerp.com>2011-09-22 10:58:12 +0200
commit51dbb70b8d3894450684226cf786c76e98abc924 (patch)
treebe7ffa4c405fee3285db9e46b9a1512469a7a16a /addons/web/static/lib/jquery.deferred-queue/jquery.deferred-queue.js
parentb4722d456464c658e69e0cdfddc29aff0bb7675a (diff)
[FIX] mitigate horrendous performance issues inserting options in Webkit
In some cases, at least with complex-enough views, inserting many options in a document in a row will get progressively slower. In import, this issue is hit on trying to import partners: partners have a humongous number of fields (direct and on their o2m), ~940, which yields a correspondingly huge number of options in the selection. A basic partner export also has quite high a number of columns (~50 without exporting o2m fields), so this list of 940 options is inserted 50 times in a row (literally too, they're all in the same table row).. While not all that fast, Firefox 5/6 has no significant issue with this (~18ms/insertion, where an insertion is a full select with all its options). Webkit browsers (Chrome and Safari) on the other hand start out fair (~10ms/insertion), but get slower and slower until they end up at 3~5 *seconds* for each insertion (3s if inserting a DocumentFragment, 5s if inserting text via innerHTML). This means the preview table takes up to *two minutes* to display, even the best cases (pre-generating everything that can be and optimizing everything I could think of) take 75 *seconds* for the insertions (the pregeneration of a given select and its options is ~100ms, the base template rendering is ~20ms). rendering divs or inputs does not have this issue, I did not manage to reduce or fix the issue directly so I replaced the options by jQuery-ui's autocomplete widget. This is not issues-free: when tabbing through the fields lists, when reaching the edge of the popup the browser will automatically scroll the field back into view. However, this is done *after* autocomplete's popup has opened, and as a result the popup opens in the wrong place (at the popup's edge, instead of under the now-moved field). bzr revid: xmo@openerp.com-20110922085812-3u1esk6czraskm01
Diffstat (limited to 'addons/web/static/lib/jquery.deferred-queue/jquery.deferred-queue.js')
0 files changed, 0 insertions, 0 deletions