Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Experience with SceneGraph architecture and migration

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?
0 Kudos

Re: Experience with SceneGraph architecture and migration

my classic app which i did develop is a medium size app, around 6000 lines of code and Ive been trying the past 2 weeks to learn scenegraph and slowly rewrite ALL my code.

My impressions so far... pure brightscript was way simpler than scenegraph here you have to learn about threads, nodes, components, xml, brightscript and a whole lot more. Brightscript was simpler, the only advantage so far ive seen with scenegraph is in fact drawing stuff on screen is faster and animations, but just drawing because when you need to code what that drawing or animation needs to do you have to start writing a lot of brightscript anyway. 

To make my post short scenegraph is not better, its harder, has its problems but apps look nicer with all the nodes...

Brightscript was limited and was hacky, i had to do a lot of workarounds pretty clever ones to make my app great, I expect the same from scenegraph, the problem is its just new, give it time, let the forums grow on info.
0 Kudos