eSWT, just like SWT, implements a single threaded UI model (single-threaded apartment model). And just like SWT it provides access to UI functions from this thread only. This does not mean that you can have only a single thread on eSWT/SWT applications it means that the GUI interaction is exclusive to a designated thread. You can read more about SWT threading model in SWT FAQ. In this post, I will compare the implementation details of this model on eSWT port for Symbian and the new Qt port.
Avkon UI, that is used to implement the S60 port of eSWT, also have similar restrictions on threads. So one would think that eSWT S60 port just wraps the native Symbian UI thread since we have matching behavior. However, this is not the case with the S60 eSWT port. eSWT on Symbian actually creates two threads. Thread one runs the Symbian's UI environment which within the team we refer as the native UI thread. Thread two runs the eSWT's UI thread which is referred as main thread. Although, from an eSWT developer perspective, main thread is eSWT's UI thread but it actually has nothing to do with the native UI resources. The implementation of LCDUI on the same platform also has a similar architecture. LCDUI is specified to be a thread-safe API so in LCDUI's case the second thread (that hides the native UI thread) is more or less a necessity where eSWT's second thread is a design decision.
This design, as with any design. comes with both positive and negative consequences. The main benefit of the two threaded solution is because the real UI is run by a thread that is not directly accessible for Java applications, it is not possible for a poorly developed application to freeze the UI and eventually get killed by the Symbian OS. However, this security comes with a performance penalty. A two thread design translates to a lot of thread switching and thread switching is costly. In theory, for every call that you make to UI components, even simple things such as setting the background color for a line makes a thread switch. In practice, however both eSWT and LCDUI tries to reduce the number of thread switches especially for primitive graphics drawing by introducing command buffers etc. in the implementation. eSWT buffers all GC calls that are possible to buffer during a paint event and passes them to the UI thread at the end of the event. LCDUI also does similar on paint callbacks.
When the new implementation of eSWT port for Qt started, it was decided that the performance penalty was too much to dismiss for the gained robustness. So eSWT port on Qt is designed and implemented to have a single thread that wraps the Qt's UI thread. As a consequence of the simplified design, the implementation ended up to be identical to any other SWT port. In fact,it borrows much of the code from SWT win32 port. I see that this contributed a big deal to the maturity of the Qt port. In the earlier testing we have also noticed some performance gains. it is really unfortunate that LCDUI implementation is not able to take advantage of a similar architecture because the thread safe nature of LCDUI forces the implementation to use two threads.
If you are an application developer using eSWT or LCDUI on Symbian platform this is probably some geeky extra information that you should not worry much about and the eSWT and LCDUI implementation will care about it for you. If you are interested in the actual implementation of the toolkit, you should keep this information at the corner of your mind.
Avkon UI, that is used to implement the S60 port of eSWT, also have similar restrictions on threads. So one would think that eSWT S60 port just wraps the native Symbian UI thread since we have matching behavior. However, this is not the case with the S60 eSWT port. eSWT on Symbian actually creates two threads. Thread one runs the Symbian's UI environment which within the team we refer as the native UI thread. Thread two runs the eSWT's UI thread which is referred as main thread. Although, from an eSWT developer perspective, main thread is eSWT's UI thread but it actually has nothing to do with the native UI resources. The implementation of LCDUI on the same platform also has a similar architecture. LCDUI is specified to be a thread-safe API so in LCDUI's case the second thread (that hides the native UI thread) is more or less a necessity where eSWT's second thread is a design decision.
This design, as with any design. comes with both positive and negative consequences. The main benefit of the two threaded solution is because the real UI is run by a thread that is not directly accessible for Java applications, it is not possible for a poorly developed application to freeze the UI and eventually get killed by the Symbian OS. However, this security comes with a performance penalty. A two thread design translates to a lot of thread switching and thread switching is costly. In theory, for every call that you make to UI components, even simple things such as setting the background color for a line makes a thread switch. In practice, however both eSWT and LCDUI tries to reduce the number of thread switches especially for primitive graphics drawing by introducing command buffers etc. in the implementation. eSWT buffers all GC calls that are possible to buffer during a paint event and passes them to the UI thread at the end of the event. LCDUI also does similar on paint callbacks.
When the new implementation of eSWT port for Qt started, it was decided that the performance penalty was too much to dismiss for the gained robustness. So eSWT port on Qt is designed and implemented to have a single thread that wraps the Qt's UI thread. As a consequence of the simplified design, the implementation ended up to be identical to any other SWT port. In fact,it borrows much of the code from SWT win32 port. I see that this contributed a big deal to the maturity of the Qt port. In the earlier testing we have also noticed some performance gains. it is really unfortunate that LCDUI implementation is not able to take advantage of a similar architecture because the thread safe nature of LCDUI forces the implementation to use two threads.
If you are an application developer using eSWT or LCDUI on Symbian platform this is probably some geeky extra information that you should not worry much about and the eSWT and LCDUI implementation will care about it for you. If you are interested in the actual implementation of the toolkit, you should keep this information at the corner of your mind.
