[PATCH 2/2] comctl32/listbox: Implement LBS_NODATA

[Nikolay Sivov]

On 11/19/18 4:42 PM, Gabriel Ivăncescu wrote:

> The LBS_NODATA style's purpose is to drastically improve performance and
> memory usage on very large lists, since they should function as virtual
> lists. We don't store any data for single-selection listboxes, while for
> multi-selection listboxes, only 1 bit per item is stored, which is very
> significant for performance on such large lists as this allows us to process
> 32 (or 64) items at a time (so it's not just useful for lower memory usage).
>
> Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=32374
> Signed-off-by: Gabriel Ivăncescu <gabrielopcode at gmail.com>
> ---
>
> I'm aware that the patch is large, but it is hard to split it up more
> than this without causing breakage somewhere, and it should be implemented
> properly for the purpose of the style (not really to add any extra features,
> but just massive performance & memory improvements). So no new tests are
> needed, but it should pass all existing tests, obviously.
>
> Actually it is a bit larger than it seems. For example, most of the changes
> in InsertItem and RemoveItem are just due to indentation changes, the actual
> changes are small there (just adding LBS_NODATA case).
>
> Note that every detail about the LBS_NODATA internal storage is kept within
> the NODATA helper functions so it doesn't leak outside. I did it this way
> to encapsulate the implementation details so that the rest of the code
> doesn't have to concern itself with how LBS_NODATA is actually stored,
> the only rule is to never dereference descr->items since there's no such
> normal data available (NULL for single-selection in fact). This means fewer
> changes outside of LBS_NODATA helpers and should be easier for maintenance.
>
> I tried hard to avoid changing much of the previous code (i.e. outside of
> the new helper functions) and I couldn't really split this patch more than
> this without breaking something in the process.
I suggest to start with byte array for item data, reusing existing 
"items" field,
and try to avoid specializing LBS_NODATA case everywhere. Heavy 
optimizations like that
should be justified by some real life use case in a first place.

If the only item data is selection bit, you can use array of selection 
ranges as another approach,
that's what ListView does. To return number of currently select items I 
don't think
you need to iterate, you can simply keep and update a single counter field.

Do you have additional tests for LBS_NODATA? Mostly notifications are 
interesting.