Opened 12 years ago

Closed 9 years ago

Last modified 8 years ago

#4108 closed task (wontfix)

Combobox: better interface to page through list choices

Reported by: bill Owned by: haysmark
Priority: high Milestone: 1.5
Component: Dijit - Form Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

Currently Combobox displays a drop down list with a specified number of items, possibly with a scrollbar, but also with "more choices" button. Seems more user-friendly to have one or the other (a scrollbar or a button) but not both.

When the table widget finally gets written maybe we can leverage that technology, to only have a scrollbar, that does lazy loads from the store as you move down.

Attachments (1)

perfTest.html (4.8 KB) - added by haysmark 9 years ago.
Page for timing queries and startup times.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 12 years ago by haysmark

Bill are we going to have a dijit.grid for 1.1? I am wondering if we need to push this until grid is ready.

comment:2 Changed 12 years ago by bill

Milestone: 1.12.0

Won't have grid for dijit 1.1, probably move it in for 2.0... sure, at any rate we can push this to 2.0.

comment:3 Changed 11 years ago by alex

Milestone: 2.01.3

Milestone 2.0 deleted

comment:4 Changed 11 years ago by bill

Description: modified (diff)
Milestone: 1.31.5

Changed 9 years ago by haysmark

Attachment: perfTest.html added

Page for timing queries and startup times.

comment:5 Changed 9 years ago by haysmark

Resolution: wontfix
Status: newclosed

I ran various performance tests in FF3 and IE8 on ComboBox?; see the attached file. Some findings:

  • Users should not use option tags to populate ComboBoxes?. Option tags take arbitrarily longer for the browser to parse. In IE8, it took 111610ms to create a ComboBox? and 10000 option tags, vs 78ms to create a ComboBox? and 10000 JSON items.
  • When you want to display all items in a data store, an ItemFileReadStore? returns results significantly faster when you pass a null query instead of an object containing a wildcard query. In IE8, a Grid with a null query renders in 859ms, vs 1938ms with a ComboBox?-style wildcard query. Consecutive page requests are similarly faster with a null query.
  • Grid incurs more overhead rendering items than ComboBox?. In IE8, a Grid page took 2580ms to scroll the page into view, render the empty cells, fetch the page, and finally load the data into the cells. By contrast, the ComboBox? menu took only 1180ms to fetch the same page and open the menu. This gap grows as you page deeper into the data set.

Based on the last point, I think that the performance penalty while the Grid loads the next page negates usability gains from having virtual scrolling. The whole point of the ComboBox? is that the end users have some goal text in mind and want to quickly type part of it in and quickly autocomplete the rest. If users have no idea what they are looking for and need virtual scrolling, then a Grid might be a better choice than a ComboBox? for the customer to deploy.

Regarding the alternatives, it is infeasible in the rich text case to know the height of row a priori, hence you cannot request a magic number of rows to prevent scrolling. We could try rendering the menu and then stripping out extra rows, but that would cause flickering. If someone finds the performance of Grid vastly improves or has another idea for making the ComboBox? menu more usable, they can then reopen this ticket.

comment:6 Changed 8 years ago by bill

Component: DijitDijit - Form
Note: See TracTickets for help on using tickets.