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@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.