Community
Participate
Working Groups
When you type into the filter dialog you can observe how the tree refreshes after each keystroke. This results in a lot of flickering and might also result in bad performance with large preference trees.
I've attached a patch which refreshes the tree only after a small timeout. Using this patch I get a much smoother look.
Created attachment 21591 [details] patch to FilteredTree The patch uses a UIJob to delay and filter out unneeded refreshes.
Erich are you planning to raise this as a polish issue? If so I'll get the approval process started.
Tod, yes this one is on my polish wish list, but I haven't brought it up with the polish team yet.
Looks like this will create a separate job for each key press, which may be expensive.
Performance concerns aside, I really like the visual behaviour you get from this patch. You are correct that the current implementation creates a job per key stroke. This can be optimized if really needed. I haven't found a performance problem in my testing (and it is the same logic that is used in the Open Type dialog which has been tuned for performance). I like the simplicity of the current implementation and compared to the previous implementation where the tree was refreshed after each keystroke it might even be more efficient. Anyways, since I really would like to see this happen as a polish item. I'm open to revisit the patch, just let me know.
Actually, when a new job is created then an existing one should be cancelled so it never gets scheduled.
I think that would work fine. +1 for this polish item.
I have modified how this is done using some of the features jobs give us First of all as we don't check state until the job is running we could continually reschedule the same job so I made the UIJob a field and just called schedule again. This also meant that we didn't have to bother with keeping a timestamp to check as rescheduling an existing job is a no - op. Modified patch released for build >20050524
That will cause more, earlier refreshes than canceling the pending job first.
Understood but this method guarantees a refresh every 200 ms - do we want to effectively disable updating during fast typing? If so then we can just cancel the job and reschedule it.
I'm actually fine with either, with a slight preference to updating every 200ms if there's been a change, rather than waiting until the user stops. Either way it's an improvement on updating on every keystroke. Erich, any preference?
The implementation that is currently implemented in HEAD works well for me and is better than my original patch
Verified in 20050526
