I'm designing it specifically with other coders in mind. At the core of the system is the messenger object and message types, each messenger object is a thread that has a mutex protected object queue and functions for popping and pushing messages. The basic rule is that as messages move around, they are only within one messenger at a time so they don't have to be thread safe (which is good for performance). The thread as it spins around, checks the queue for messages, calls a virtual; abstract; function (domessage) for handling the message which returns if the message was passed on or not. if not, the message is destroyed.
Most objects in the UI are sub-classes of this messenger object, the implemented domessage for each sub-class handles whatever logic you like for any message type you like, in JUI's case the messages are mouse movement, window close requests, keyboard etc
this means that every thread can handle it's local messages without blocking the other threads, and only rarely blocking when there is simultaneous domessage popping and external pushing.
At the moment the main application thread, by means of another thread has a locked-frame rate. it iterates through the tree of window manager, windows, widgets etc locking that element, calling render then unlocking the element.
This is a problem, it needs to lock as other threads may very well manipulate the values used for rendering (position, colour theme etc). So with a high volume of elements, the rendering thread will have to wait on the occasional lock. I've minimized this best I can but unfortuantly very rarely this causes a visually identifiable 'pause' in events (mouse stalls). it's hardly noticable and as I'm running on a slow system (Atom 330), most people wouldn't notice at all. But I'm a perfectionist so I can't leave it like that
I'm going to solve this by improving/rewriting the locking mechanisms in order to decrease/eliminate the potential for this to happen.
Reply With Quote
Bookmarks