What is a correct way of using roRegistrySection inside scene graph components?
Per docs, roRegistrySection can be accessed from TaskNodes only.
Do I really have to create asynchronous task nodes and content node subclasses with my custom fields for each registry usage?
Is there a way to at least create a synchronous task node so I don’t have to wire up all these observers and deal with multithreading complexity for such a simple task?
Are there any other synchronous persistent storage alternatives for scene graph?
Any help to simplify that out would be greatly appreciated.
“Veeta” wrote:
Yes, you need to create a Task node and read from the registry in its background thread. It is a little verbose.
I believe the right word is “verbogus” :mrgreen:
What is a correct way of using roRegistrySection inside scene graph components?
Per docs, roRegistrySection can be accessed from TaskNodes only.
Do I really have to create asynchronous task nodes and content node subclasses with my custom fields for each registry usage?
Is there a way to at least create a synchronous task node so I don’t have to wire up all these observers and deal with multithreading complexity for such a simple task?
Are there any other synchronous persistent storage alternatives for scene graph?
Any help to simplify that out would be greatly appreciated.
That’s an incredibly stupid design decision that made me shake my head more than once.
Just consider: We’re talking here about data with a size of no more than 16kb!! (more is not allowed for registry storage)
I solved it like this:
I’m storing my settings in my own AA
To make the data available everywhere in the channel, store this data as a field in the global node
To persist the data, I’m saving it as a JSON string in a single roRegistry string value
At app start, I load it with a task and wait for completion
Now all read operations can be performed synchronously by returning data from the AA
For write operations, I create a task to save to roRegistry, but I don’t need to wait for the task to complete, because the AA already has the “latest” data
This way, all registry operations can be performed synchronously, just like before..
To make the data available everywhere in the channel, store this data as a field in the global node
To persist the data, I’m saving it as a JSON string in a single roRegistry string value
At app start, I load it with a task and wait for completion
Now all read operations can be performed synchronously by returning data from the AA
For write operations, I create a task to save to roRegistry, but I don’t need to wait for the task to complete, because the AA already has the “latest” data
This way, all registry operations can be performed synchronously, just like before..
Well done!
Except why run a task to read the registry on start? Just read it in main(), before getting in the event loop.
“EnTerr” wrote:
Well done!
Except why run a task to read the registry on start? Just read it in main(), before getting in the event loop.
I wasn’t sure I I’m allowed to modify “screen.getGlobalNode()” before calling “screen.Show()”. I got some vague memory about a hint in the SDK docs about such a case. Setting it after “screen.Show()” is not an option because the scene’s Init() process already needs the data.
Probably I’ve also been too tired of all that scenegraph stuff to actually try this…
Prior to creating an roSGScreen object and calling its show() function, creating roSGNode objects and using their interfaces is not guaranteed to work correctly.
Prior to creating an roSGScreen object and calling its show() function, creating roSGNode objects and using their interfaces is not guaranteed to work correctly.
Good point but… hmmm. Do you realize that Tasks are roSgNodes themselves? :twisted:
In other words you mustn’t create new tasks before you show the screen!
This was not a trap! Ok so it is a trap but it was put there by the Matrix Architect.
Still not a big fan of spawning threads for nothing. Hmm, in the spirit of coding-while-intoxicated (that apparently RSG is), you could move all the init code into a listener to myRegistry field and do the work only after main() has injected there the post-JSON registry roAA. Or, i am reminding of another musing today: just don’t put your eggs in the Scene basket - instead use a child of the scene that can be added later.
“softworkz” wrote:
Wow, isn’t that impressive? A real revolutionary architecture…
More like,
[spoiler=Dance Dance Counter Revolucion:2whbt8r4][youtube:2whbt8r4]x2mGXbiqnsE[/youtube:2whbt8r4][/spoiler:2whbt8r4]
