Scirra
Dropdown List / Autofill Lag
Problem description:
As a project increases in size, the # of elements that accumulate in dropdown lists also increase. In my experience, this has led to significant lag. In my current project I can consistently reproduce this issue.
I've created a mimic large project focused on increasing the elements in the dropdown list. I realize this is not a project you'd see in a natural state. It is purely used to highlight a potential bottleneck that larger projects can begin to approach.
Attach project
Steps to reproduce
The steps are written in comment form in Event Sheet 1
Observed result
The time it takes for the dropdown list to emerge and the lag to end takes significantly longer compared to a fresh project.
Expected result
The time it takes for the dropdown list to emerge would ideally be faster, with less noticeable lag.
Affected browsers/platforms:
Chrome
First affected release:
r320
I can reproduce some slowness with autocomplete appearing and disappearing with this test project. I made some small improvements for the next beta, but unfortunately I think further improvements will be very difficult.
Hiding autocomplete takes ~0.5s and I managed to improve that to about ~0.25s (around twice as fast).
The main problem though is autocomplete takes ~3 seconds to appear (on my machine). According to Chrome's profiler this appears to be ~0.5s in Construct's code, and ~2.5s in the browser performing layout of all the HTML elements in the autocomplete box. This is such a large project that there will be tens of thousands of items in the autocomplete box, and so the main performance overhead is the browser calculating where to position them all. Unfortunately browsers provide virtually no insight in to why the layout is slow or what could be done about it. It's mostly a black box.
Other measures like reducing the amount of content in the autocomplete box can help sometimes, but aren't always effective. For example we could limit autocomplete to list a maximum of 5000 items. But then if your project has 10000 items, it will never autocomplete half the content of your project. It could filter the list based on what you type, but in this project typing "s" will still list the tens of thousands of sprites and still have the problem.
I guess we could completely rewrite the autocomplete feature with a view to improve performance. However I'm not sure what approach would be faster, and that project would also be a significant undertaking, and time is by far our most limited resource. So I'm afraid it's not clear to me what else could realistically be done at this time. Maybe we should just provide an option to turn off autocomplete so it at least doesn't get in the way?
imho filtering the list depending on what is typed would be a decent solution. I think in a more realistic project it is a lot less likely to have that many objects starting with the same letter. (this would also be cleaner overall ux wise) Another idea could be to only layout the top 100 matching options, when scrolling down it would start loading the next batch.
probably not feasible depending how the browser does the layouting. But doing it asynchonously would be cool. So the user can keep typing while the autocomplete is loading.
Main issue:
The main problem though is autocomplete takes ~3 seconds to appear (on my machine).
~0.5s in Construct's code, and ~2.5s in the browser performing layout of all the HTML elements in the autocomplete box.
the main performance overhead is the browser calculating where to position them all
Suggested solutions:
Limiting max items list:
For example we could limit autocomplete to list a maximum of 5000 items. But then if your project has 10000 items, it will never autocomplete half the content of your project.
Static or dynamic?
I need clarification on this, is this a static application, or would this 5k limit be the 5k items that most closely match what was typed (dynamic)?
If it's the static application, then that does sound tricky, but if it's the dynamic application, I fail to see how this limitation would not be an ideal starting grounds, especially if it's an opt-in for those that desire it.
Example:
To make sure I'm on the same page here let's say I have 10k items:
5k start with "square".
5k start with "circle".
If I then type "squa" could filtering not be limited to the top X items that most closely match "squa", and then and only then display those top x items?
I ask this because as of now if we take a more extreme case:
20 start with "square".
9,980 start with "circle":
As of now when you type: "squa", the engine will still display all 10k items.
Most, if not all, items of the project are present in the dropdown list regardless of what's typed?:
From my understanding, C3 displays all items of the project regardless of what is typed.
In this instance, I fail to see how this is useful, but I don't know how difficult it is to control this operation on your end.
I guess we could completely rewrite the autocomplete feature with a view to improve performance. However I'm not sure what approach would be faster, and that project would also be a significant undertaking, and time is by far our most limited resource. So I'm afraid it's not clear to me what else could realistically be done at this time. Maybe we should just provide an option to turn off autocomplete so it at least doesn't get in the way?
The autocomplete in its current state, while working with my current project, gives me the sense that I spend a large portion of my time waiting for autocompletes to finish loading, which defeats one of its primary purposes: saving time.
Maybe we could do something like just display the nearest 1000 items around the current suggested item. That might be easier to implement and still solve the problem. I'm not sure to what extent people rely on scrolling around the autocomplete list though - if we make too big a change it could break other people's workflows.
Maybe we could do something like just display the nearest 1000 items around the current suggested item. That might be easier to implement and still solve the problem. I'm not sure to what extent people rely on scrolling around the autocomplete list though - if we make too big a change it could break other people's workflows.
How difficult would it be to have this as an option? Is it more of an all or nothing situation?
Just display the nearest 1000 items
How difficult would it be to have the # of items to display optionally set (I rarely need beyond the first 5 results).