Community
Participate
Working Groups
There are way to many selection change events being sent. Since much of the UI is based on responding to selection changes any optimizations in this code path will have a significant benefit. To recreate: Start with the "Hello World" example but write something to the console on every selection change event. Launch the example and activate the action set. Start clicking around in the UI and notice: In several views you get multiple selection change events being processed for single clicks. REALLY IMPORTANT: Try extending selection in an editor and notice that you get tons of events.
What is the result from doing this on the R2.1 base? Is this a regression?
Defer until after M9
Defering due to too much risk in changing the order/number of selection events. This should be fixed in 3.1 after accurate tests exist for selection change events.
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
Stefan, what is the status of this?
There's many reasons why we get extra selection changes. For example, the workbench used to temporarily nulled the active part between each activation change. This required clearing the selection from the old part (since there was no way to tell the difference between a focus change and a part being disposed at the time of the deactivate event). Recent refactoring to workbench page has made it possible to locate the new active part at the time we deactivate the old part (which means we don't need the temporary null activation or selection anymore). Right now, there are 4 selection changes whenever part activation changes. The new changes to workbench page would should let us to make do with only 1... but a lot of refactoring had to happen to workbench page to make this possible. IMHO, an even bigger issue than the number of selection changes is the number of things listening to a selection change. For example, actions have no good reason to be notified about selection changes unless they are currently visible somewhere.
I can investigate reducing the selection change events on focus changes. cc'ing Dooge to investigate reducing the places where selection changes get broadcast. (I suspect it would be possible to send every action the correct selection when it becomes visible, send it an empty selection when it becomes hidden, and stop notifying them of selection changes while they're hidden).
What percentage of the selection change notifications do you think are covered by this case. It sounds like it could potentially be considered a breaking change, so we should tread carefully.
Please see Bug 12285. I believe this at least a partial duplicate. In particular Bug 12285 comment #10.
Filed bug 95155 regarding the enhancement to reduce listeners. The "redundant selection changes in one click" issue is fixed. The selection changes during a drag are not a bug unless some of them are duplicates.
