On Tue, Nov 20, 2018 at 12:25:08PM +0200, Gabriel Ivăncescu wrote:
On Tue, Nov 20, 2018 at 12:00 PM Nikolay Sivov nsivov@codeweavers.com wrote:
On 11/19/18 9:31 PM, Gabriel Ivăncescu wrote:
But don't we already have that? Right now, LBS_NODATA is implemented using the normal item structure. It works, but it's super slow, especially for single-selection listboxes (which should store no data at all).
I'm not sure what exactly you want me to implement? Can you please elaborate.
Can we fix single-selection case first without major rewrite?That's what was reported as https://bugs.winehq.org/show_bug.cgi?id=32374.
I don't think that's possible, if by major rewrite you mean the specialization of it everywhere, that can't be avoided.
Everything about LBS_NODATA has been implemented already with the previous patchsets last week, *except* for performance (so it was left at the end already, which is now). This style was designed for performance by Microsoft, and applications make use of it for this reason (as long as it exists, they expect performance back).
Note that the helper functions are mostly about multi-selection listboxes, but I'm afraid they can't go away because otherwise this patch would break on LBS_NODATA multi-selection listboxes, whereas they worked before (but slowly).
A temporary alternative is to add even *more* checks to disable it for multi-selection listboxes, so that only single-selection listboxes are handled in this patch. However, I don't think that's a good idea or elegant at all and would probably be considered a "hack" because it will fill the code with arbitrary checks that shouldn't be there (and would also go away on next patch), so I didn't bother with that but it was my first thought, I considered many possibilities. :-/
It seems to me that LISTBOX_SetCount() is likely to be a performance bottleneck. Of course one would have to do profiling to check that, but it seems likely. This could easily be optimized by allocating the items in one go.
Huw.