I’m currently migrating a classic Roku channel (that I haven’t developed) to scenegraph. Having experience with a lot of different UI frameworks, that scenegraph architecture appears to me as pretty much half-baked. The concept itself has a few good points, but when it comes to details there are just too many application scenarios left unaddressed (or at least: not supported in a natural way and if there’s some none-natural way, it’s usually not documented). And for most of these cases, a lot of research is required to find out how to work around.
Over the past two weeks I had at least five questions (of really fundamental interest) where I found that these had already been asked in the forums but were just left unanswered. @Roku: Why not go through and reply to these posts? There are quiet a few things pending a definite answer, and it would really help if these would get a reply.
Also those “SceneGraph Migration” guides, tutorials etc. are nothing more than a joke IMO. They do not address any of the actual problems a developer is facing when migrating a complex channel to scenegraph.
Here’s just one example: Scenegraph doesn’t allow registry access in the SG thread. All registry interaction has to be done through task nodes. This requires migrating the existing code to an event-driven model while BrightScript doesn’t have any kind of async support (like C# or VB.NET).
That means that existing methods need to be split up into multiple partial methods on each registry operation and those fragments would need to be triggered by event. Things are getting ugly pretty soon in such cases. Further it involves a lot of work to get this done, especially when there is complex program flow depending on registry operation results.
Such things leave me wondering about the motivation to create such kind of design. Just take registry access: It’s limited to 16kb total size anyway, but the architecture requires to spawn background threads each time to access these 16kb of data? Really?
