On Tue, Nov 20, 2018 at 1:35 PM Huw Davies huw@codeweavers.com wrote:
I was getting ahead of the conversation and referring to the multi-selection case, where you'd need something allocated. Sure this would end up using more memory than your patch, but it would be a stepping stone that should at least help with performance in that case.
Right, I don't mind postponing multi-selection to a later patch, I just don't know how to do it without breaking something that works now (slowly) or adding more redundant checks that will be removed later.
As a first step, I'd do what Nikolay proposed, and handle the single selection case with a NULL items array. What does that patch look like?
Huw.
Do you mean just testing for LBS_NODATA single-selection and leave multi-selection alone for now? I can't test for NULL because some functions, like InsertItem, assume that NULL means "empty listbox" so it's not a reliable check -- I still have to specialize for LBS_NODATA. If not, please elaborate.
I can add checks like (excuse email formatting):
if ((descr->items & LBS_NODATA) && !IS_MULTISELECT(descr)) /* do single-selection LBS_NODATA easy stuff */ else /* leave the current code unchanged */
This will work, but those checks will have to be removed later when multi-sel is implemented of course (I was worried they could be considered a hack, but if you are okay with them I'll go this route).
Another option is to implement multi-sel listboxes as a byte array and iterate 1 item at a time which simplifies it somewhat, as a first patch. Then, I'll profile the difference and implement the bit array (or something else) in a later patch. Would that be acceptable for a first patch at least? (the byte array thing)
Those 2 are the options I can think of.