I'm hoping there's some kind of planned performance improvement work on the gallery control, but posting this, in case there isn't.
At present, the gallery control is incredibly clunky/laggy when scrolling any faster than what I'd consider to be "unreasonablly slow". The behavior is
The rows move up
There is a huge empty whitespace for about 1-2 seconds
The white space fills up as the elements render
I will note:
It doesn't matter if I bind the gallery to a local collection or directly to the data source. Since my data source (Azure SQL) is too large to be cached to a collection, I'm limited to direct binding anyways.
It's reproducible in web player (Chrome browser) and mobile (iPad app)
I am using ThisItem to bind all data to controls in the gallery. At this point, I have 8 controls total in the template row, which are a mix of images (2 icons) and labels (6 of those).
It seems to be completely unrelated to latency in the network. I can verify this by watching the troubleshooting console, and the lag isn't tied to any network calls, though I do see those happen at each 100 rows of data or so.
I can reproduce this on other data sources that I am caching to a local collection on app OnStart, where I see this empty whitespace when I scroll fast enough to where the gallery would need to render more than ~5 rows at a time. In that case, the datasource is cached to a local collection, and that gallery only has 5 labels in the template row.
I'm attaching a video of this behavior. While the lag you see might be "acceptable", it's not a great user experience on any platform. I understand that the gallery is probably working as designed for keeping resource utilization low on mobile devices, however, since this can be reproduce on mobile, too, I'm asking that Microsoft improve this.
I had a whole nice reply typed up, but every time I post something in this community, it fails the first time with an "unexpected error, contact your system administrator", and if I didn't copy what I wrote before submitting, it's lost.
Answers to your reply:
Record count has no bearing on this issue. I can reliably reproduce it on both cached local record sets of 259, or Azure SQL record sets in the thousands.
I've already followed every possible performance recommendation in both of those articles, prior to posting my original issue.