Hi all, I've run into a situation where occasionally I have thousands of possible options supplied to a SuggestionPopup. As soon as I make the SuggestionPopup visible, the EDT sometimes locks up for more the 600ms. I've eventually figured out that this is due to the call to TerraListViewSkin.getPreferredWidth(int) (the ListView being used internally to render the options). This particular method iterates through each of the options and then 'renders' each of them using the ListView.ItemRenderer in order to calculate the maximum preferred width for each of the options. This obviously all happens on the EDT (which makes sense), and hence gives rise to the lock-up. I'm not sure what could be done to improve performance in this case (clearly using a background thread isn't an option here).
I thought about using a custom ItemRenderer which could potentially return a constant preferred width. In terms of the use case, calculating this constant width up front would definitely be possible as the subsequent list of options passed to the SuggestionPopup would always be a sub-set of the initial list of options. Even though it is possible to pass a custom ItemRenderer to the SuggestionPopup, this wouldn't work given the way that the previously mentioned getPreferredWidth method is implemented (the renderer has no say in the iteration over each of the options). At first I thought that the ListViewSkin's getPreferredWidth method could be changed to stop the iteration of options as soon as their combined rendered heights exceed the height value passed into the method. This would probably work for most ListView use cases - except when used within a Panorama (as is the case here). Does anyone have any suggested workarounds / solutions? In the meantime, I'll have to resort to displaying suggestions only once a sufficient number have been filtered out. Regards, Pierre
