Summary: | Implement a new Display.greedyExec method | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Stefan Xenos <sxenos> |
Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | daniel_megert, Lars.Vogel, loskutov |
Version: | 4.5 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Stefan Xenos
2015-05-29 14:19:53 EDT
Actually, layoutExec may not be necessary since we now have Composite.layout(Control[], SWT.DEFER), which pretty much handles that use case. Display.greedyExec would be sufficient. (In reply to Stefan Xenos from comment #0) > An alternative would be to add a two-argument variant of asyncExec that > accepts a priority argument which can be NORMAL (runs first - for model > changes or setting SWT properties), LAYOUT (for layouts only), or LEGACY > (for the current asyncExec behavior). NORMAL and LAYOUT priorities would > always run before paints or user events. This sounds better as other proposals. What I would like to see is something which would allow us to identify and skip identical async requests. Might be asyncExec(KindOfJobRunnable). > This sounds better as other proposals.
Actually now that I think about it, I'm not sure we actually need the LAYOUT priority, since the SWT.DEFER flag already covers that use case... and if we only need the one priority level, then a new greedyExec(Runnable) method may be the simplest alternative.
So the execution order would be:
1. Any work scheduled by greedyExec(...)
2. Any work deferred by SWT.DEFER (ie: layouts)
3. Paint events
User events and work scheduled by asyncExec could actually come at any point here without breaking things.
If a modal event loop is triggered by any event, it should continue processing events in the order shown above. A greedyExec that was scheduled by an outer context might be executed by an inner event loop.
|