Don't know how I would illustrate it... hmmm
Logic renderer
| |
| |
Renderer.CreateWidget( widget ); -> queue |
| process messages
| receive ptr to widget
sometime in the future |
| |
| |
widget.SetPosition(); widget.Expose();
| |
| |
restart loop restart loop
Well the
SetPosition can be anything really, even several modifications. What I'm trying to say that I can be messing with data the widget is trying to read while it's rendering and eventually mess things up. Let's say I SetPosition to 400,300 and the logics thread manages to write the x position then it's position would be 400,0 and then expose is called and renders to that position. That's a mild error and not so serious. It becomes worse if I delete the widget and then send a message to remove it from the graphics side. Then it would be trying to render an object that does not exist anymore.
And why I can't use messages are because I would need to send back information that a widget has been clicked on, hovered above and stuff like that. I make the renderer the logic threads bitch which simplifies and optimizes the synchronization a lot. And well anyone familiar with
Amdahl's law should know why that is necessary.
What I am thinking that I'll modify is that I detach input, logics and data from a widget into a separate class which can export a state class the original widget class can read and then render accordingly.
class WidgetState
{
public:
GDE::AnyType GetParameter( const std::string &aName );
private:
std::map< std::string, GDE::AnyType > myParameters;
};
class WidgetLogics
{
public:
virtual const WidgetState *GetState() const;
};
class Widget
{
public:
virtual WidgetLogics *DeattachLogics();
virtual void ReadState( const WidgetState *aState );
};
Just a basics of what I'm thinking. The widget itself will still contain the logics so it can function entirely like originally intended but you can also deattach the logics from it and handle it separately and then you transfer the changes with the WidgetState class. When the Deattach function is called then the Widget looses all reference to the logics and will not do anything anymore no matter what. It can only be modified by the state interface after that.
I'm not requesting that you do it! I'm just thinking that I'll fork your project and modify it so that it becomes... well more of a MVC like architecture to the functionality that is already there.
Maybe you got some pointers?