Apparently you can create an roRegion using the roScreen as its source bitmap, although the resolution/scaling is off. It also appears that roRegion exposes an ifDraw2d interface , resolving it perhaps by calling it’s source objects ifDraw2d interface. I created an roRegion using roScreen as its source and then called the (non-documented)
roRegion.DrawObject, roRegion.DrawRect , all of which appears to work. (I don’t see any of this documented, but did come across a post on this forum). I am particularly interested in creating regions right from the roScreen buffer which apparently works except for the scaling that is returned. I have not played with any of the pretranslation or scaling flags or rendering functions to see if I could fix it. Any light on this ??? it could possibly help those of us struggling with memory issues. Now I tried all this while a compositor was sitting on top of the screen so I don’t know if I would have had different results without the compositor. But before I continue experimenting, I would like some feedback if possible. Perhaps there is some other documentation that I should be looking at
“NewManLiving” wrote:
Apparently you can create an roRegion using the roScreen as its source bitmap, although the resolution/scaling is off.
What do you mean by this?
“NewManLiving” wrote:
It also appears that roRegion exposes an ifDraw2d interface , resolving it perhaps by calling it’s source objects ifDraw2d interface.
It is undocumented, but roRegion does implement ifDraw2d, and it’s the only (easy) way to do clipping when drawing directly to a bitmap or screen.
“NewManLiving” wrote:
I am particularly interested in creating regions right from the roScreen buffer which apparently works except for the scaling that is returned.
I’ve never had luck trying to draw a portion of the screen to a bitmap or the screen. This is what I was eluding to in the previous thread. In theory it should work, though. Again, could you explain what you mean by “except for the scaling that is returned”?
Well I have been considering what you were talking about. And I do see your point. I have been isolated using only ROKU 3. So, I figured if roScreen is theoretically similar to roBitamp, let me try to get a region from it. So I created l_region = CreateObject(“roRegion”, myRoScreen, x, y, w, h, ) where I use my roScreen instance instead of a bitmap. Well it returned type(roRegion), so I took that region and drew it back onto the screen. It drew the area that I had specified except the length was stretched somewhat longer (actually it was a section of a grid that I am working on - I want to fade in/out a new grid and I thought about what you said, Also I did modify my thinking about drawing directly to the screen; it does have its benefits - thanks to you) anyway, it drew the exact replica of the grid but the cells were stretched out about 25 % longer. So before I go crazy trying to rectify this I thought I would ask. Of course this is ROKU 3 so I don’t know what anything else would return. I am setting up a 2x box as I stated earlier ( as there is one available to me ). A friend is using it and I am helping him with a grid - so I need to know the differences
After further investigation this phenomenon exists in conjunction with a compositor and sprites. Whatever the topmost ( or most recently created sprite. Don’t know for sure yet) happens to be this call: region = CreateObject( “roRegion”, roScreen, 0, 0, roScreen.GetWidth(), roScreen.GetHeight() ) will capture the sprite and scale it accordingly. If the sprite is small, say 100 * 100 it will stretch it across the display in both directions. In the case of my grid I was able to scale the region down to be the same size as the original and write it back to the screen. Of course this does not appear to be Kosher, but the bottom line is: It is doable and can help tremendously with animating areas of the screen without having to create additional overhead. I did try this with just an roScreen not using a compositor/sprite and the results were not the same
“NewManLiving” wrote:
After further investigation this phenomenon exists in conjunction with a compositor and sprites. Whatever the topmost ( or most recently created sprite. Don’t know for sure yet) happens to be this call: region = CreateObject( “roRegion”, roScreen, 0, 0, roScreen.GetWidth(), roScreen.GetHeight() ) will capture the sprite and scale it accordingly. If the sprite is small, say 100 * 100 it will stretch it across the display in both directions. In the case of my grid I was able to scale the region down to be the same size as the original and write it back to the screen. Of course this does not appear to be Kosher, but the bottom line is: It is doable and can help tremendously with animating areas of the screen without having to create additional overhead. I did try this with just an roScreen not using a compositor/sprite and the results were not the same
Interesting. Sounds like the behavior might have changed a little since the last time I tried it. I bet you could use it to do some cool wipe style transitions without having to redraw the previous frame.
I’m also curious how it would behave if you drew the region on top of itself… kind of like doing a bitmap.DrawObject(0, 0, bitmap)… Might have to give that a try 
Yes I agree there is a lot you can do with it , but we do not have the ‘official’ blessing to use it and it may be an anomaly which will break the channel in further releases of the SDK. It really is a must have as you have pointed out in previous posts. It always makes me wonder what really is in the SDK that only the ‘privy’ know.
Now here’s a nice discovery! You can pass an roRegion to roCompositor.SetDrawTo(), and it will correctly clip to that region. If you enable alpha on that region, and set the background color of the compositor to fully transparent (&H00000000), then the compositor will correctly blend to whatever is drawn to the screen behind it. Thinking about a different compositor for different areas of the screen… This compositor thing is becoming more and more appealing…
That would make sense since you can pass a bitmap. Never thought about a region
I am also suspecting that what I mentioned above really only applies to the
Last item drawn to the screen -a pixel or a grid. using a compositor or not
Wouldn’t matter. I’m going to test it. If that’s the case you can draw something
Onto the screen and then return a region for what you just drew
I think this because no matter what I have on the screen the region even if it’s
The entire screen just picks up the last item drawn and stretches it
Don’t know if this occurs between swapbuffers or not. Today I am working
But I’m glad you are looking at it. That is interesting
“NewManLiving” wrote:
but we do not have the ‘official’ blessing to use it
I believe this is the way it was intended, the screen itself is essentially an roBitmap, although specialized and you should be able to treat it as such for the most part.
“NewManLiving” wrote:
It always makes me wonder what really is in the SDK that only the ‘privy’ know.
- Components and functions that have been build for internal use and have not been API reviewed.
- … or that engineering plans to revise significantly
- Custom components, developed for specific business partners which we may or may not eventually release to developers - the general philosophy is that we will eventually release most, unless they fall under #2.
- Joel
“RokuJoel” wrote:
“NewManLiving” wrote:
but we do not have the ‘official’ blessing to use itI believe this is the way it was intended, the screen itself is essentially an roBitmap, although specialized and you should be able to treat it as such for the most part.
“NewManLiving” wrote:
It always makes me wonder what really is in the SDK that only the ‘privy’ know.
- Components and functions that have been build for internal use and have not been API reviewed.
- … or that engineering plans to revise significantly
- Custom components, developed for specific business partners which we may or may not eventually release to developers - the general philosophy is that we will eventually release most, unless they fall under #2.
- Joel
Hey Joel, any idea why the documentation for roRegion doesn’t indicate that it implements the ifDraw2D interface (which was the catalyst for this thread), and why the roCompositor.SetDrawTo() method documentation specifically states that only works with roScreen and roBitmap, instead of anything that implements ifDraw2D?
Probably just an oversight.
- Joel
Thanks for the info Joel. Maybe you could tell us what is done ‘internally’
With the byte array that can be returned from a bitmap. Seems to have no purpose
- For us anyway.
“RokuJoel” wrote:
“NewManLiving” wrote:
It always makes me wonder what really is in the SDK that only the ‘privy’ know.
- Components and functions that have been build for internal use and have not been API reviewed.
- … or that engineering plans to revise significantly
- Custom components, developed for specific business partners which we may or may not eventually release to developers - the general philosophy is that we will eventually release most, unless they fall under #2.
As luck will have it, yesterday i was going over list of classes to see what i am missing - many seem to be in 1-2-3 but there seem to be also
- Components which RokuCo is blissfully unaware are still undocumented. Examples would be roInput and roInputEvent, that exist for maybe 3 years now (earliest mention i see is Jul’2011 in this forum), as well as roGlobal (i digged and this one is explained in BrightSign Object Reference Manual)
If s/o from RokuCo is willing to label them as 1, 2, 3 or 4 accordingly, i’ll open a topic with list of those classes?
