Roku Developer Program

[NewManLiving]

"TheEndless" wrote:

"Komag" wrote:
I prefer to use a compositor instead and do an AnimationTick() at the right times.

"NewManLiving" wrote:
In that case it would make sense. I never did like compositor.animationtick, got more even results using my own animationtick, but I might have been doing something wrong

This is another one of those poorly documented things. You should be calling AnimationTick() on every pass through your loop, and using ifRegion.SetTime() on each of your animated sprite regions to control the frame timing.

Yes I did discover all that and it worked ok but I did not like having to call animatedtick in my loops, I rather instantiate an object which contains its own timing and region frames when needed. one call to compositor drawall takes care of all/any animation that is currently taking place. Actually I did use it extensively for the first year. But as I needed more overlapping and dynamic timing of animation it was just easier for me to create objects. Of course the objects themselves could create/remove/settime animated sprites as well, but I currently prefer my own. Using the compositor has given me the freedom to create complex interface without complex logic to keep track of the order of drawing. So I have become quite creative with interface design. Think about it: A grid which fades out and splits when the user clicks on a cell. Ok what if the Cells bitmap is still the placeholder because of those occasional "late arrivals" from the texture manager (you see this in the built in grids). The grid does not wait for all to arrive but begins its split/fade, the selected module crossfading in. Then the image arrives. It must seamlessly be drawn at the current location of the split with the current alpha blend. Think about several or more doing this almost together. So you can see what a logical mess this could create. So naturally I think differently when it comes to animation. Honestly if I did not use compositor I don't even know how I could even write such interface. So my thinking would naturally be different then designers that do not use it

[EnTerr]

"TheEndless" wrote:
Yes, the key is to not dispose (or modify?) any 2D objects after you've initiated drawing to the screen. This flicker/tearing issue is restricted to the original Roku LT (2400), Roku 2 HD, Roku 2 XD, Roku 2 XS, and Roku Streaming Sticks (i.e., 2400 and all 3XXX models).

Hm, don't you think this is the same issue discussed in a February '15 thread "SwapBuffers not blocking if animation longer than 1/60 sec."? I haven't seen it till now but read it thanks to @Komag's linking above to @oomzay thread. Here is the essential part, what Joel said:

"RokuJoel" wrote:
The issue you are seeing is as I understand it a platform dependent issue (affecting our "Giga" series of hardware, the Roku 2 XS/XD, LT2400, 2400SK, MHL Streaming Stick and possibly the USB stick). Essentially SwapBuffers will de-sync from the vertical blanking interval if you take more than 16 ms before calling it. This was a hack to improve performance of our home screen on these hardware platforms.

The way i read this is that when SwapBuffers() is called, depending on the time "delta" elapsed since previous SwapBuffers():

1. if delta < 17 ms then block&wait for VSYNC, then swap the buffers


2. if delta >= 17 ms, then switch buffers immediately, w/o wait

If we are in case (a), there won't be a flicker/tear. If we are in (b) though, all bets are off - there is potential for flicker and it may happen or not. It's a gamble, depending on how different the two buffers are and when exactly displaying the current frame ends - then VSYNC happens - then drawing next frame begins. So you may get upper half of the screen drawn from the old buffer and the lower half drawn from the new one.

That may sound like word salad - but returning to practice, that would mean at any time when one's double-buffered app frame rate drops below 60fps, it is the flicker "splash zone". So, if drawing a frame brings you close to the 17 ms cut-off, e.g. you are at 15-16 ms and then a relatively small change delays code by 1-2 ms - now we are in screen refresh out-of-sync territory.

[TheEndless]

"EnTerr" wrote:

"TheEndless" wrote:
Yes, the key is to not dispose (or modify?) any 2D objects after you've initiated drawing to the screen. This flicker/tearing issue is restricted to the original Roku LT (2400), Roku 2 HD, Roku 2 XD, Roku 2 XS, and Roku Streaming Sticks (i.e., 2400 and all 3XXX models).

Hm, don't you think this is the same issue discussed in a February '15 thread "SwapBuffers not blocking if animation longer than 1/60 sec."? I haven't seen it till now but read it thanks to @Komag's linking above to @oomzay thread. Here is the essential part, what Joel said:

"RokuJoel" wrote:
The issue you are seeing is as I understand it a platform dependent issue (affecting our "Giga" series of hardware, the Roku 2 XS/XD, LT2400, 2400SK, MHL Streaming Stick and possibly the USB stick). Essentially SwapBuffers will de-sync from the vertical blanking interval if you take more than 16 ms before calling it. This was a hack to improve performance of our home screen on these hardware platforms.

No.. and while what Joel suggested may be true, it is undeniable that what I stated above is 100% effective at eliminating the tearing/flicker, regardless of framerate. This is the same issue that you and I actually discussed in depth earlier in this very thread: viewtopic.php?f=34&t=54513&p=438746#p438741
You're even the one that narrowed it down to it being related to the disposal of the bitmap.

[EnTerr]

"TheEndless" wrote:
No [...] it is undeniable that what I stated above is 100% effective at eliminating the tearing/flicker, regardless of framerate. This is the same issue that you and I actually discussed in depth earlier in this very thread: [...] You're even the one that narrowed it down to it being related to the disposal of the bitmap.

Right, i remember what we talked.
I am hoping there is a single underlying "feature" that causes the tearing. A "grand unified flicker theory", if you will :mrgreen:
Because disposing a bitmap takes some time too, right? It does not have to be comparable to disposing a roArray, since roBitmap presumably is linked to a graphic subsystem element, OpenGL texture or what-have-you - and dealing with that may be causing unusual delays?

[NewManLiving]

"TheEndless" wrote:

"EnTerr" wrote:

"TheEndless" wrote:
Yes, the key is to not dispose (or modify?) any 2D objects after you've initiated drawing to the screen. This flicker/tearing issue is restricted to the original Roku LT (2400), Roku 2 HD, Roku 2 XD, Roku 2 XS, and Roku Streaming Sticks (i.e., 2400 and all 3XXX models).

Using the compositor I do not initiate any drawing to the screen that I am aware of. Generally I create, write/modify, destroy and then when all is done I call compositor.drawall and swapbuffers. So it would be the compositor that initiates drawing to the screen. so I am trying to figure out how your solution would apply or perhaps I'm misunderstanding you.
In the past like Komag and others I have put a screen.clear or screen.finish before compositor.drawall and it worked. But it did not seem natural. So I investigated the finish methods and figured a commit to the screen would solve the problem which it does but as Komag pointed out there is a performance hit as the methods block. However even with the slight performance hit I am getting very good response from the roku 1 which I use as a baseline. But I believe this has more to do with my use of region offsetting which significantly reduces the use of the drawing functions. Now I noticed I'm getting finish crazy (it is there for a reason) and would like to remove them where I can. Could you elaborate a little more about your solution so I can see where in my code I may be doing this. Thanks

[squirreltown]

I'd be curious what .finish actually does and when it's useful, as i never use it. I don't make games but i do a lot of animation and have never had an instance where it seemed to be needed. In fact in my example earlier in the thread where i was modifying an existing bitmap after calling screen.clear() i tried using it before screen.swapbuffers() and it did not have any effect on the tearing/flickering issue - as Endless said - only not changing the bitmap after starting the screen draw fixed it.

[NewManLiving]

A queue is used to stack drawing calls so that when you write to a bitmap for example your update is not necessarily written immediately to the bitmap but stacked and then written all at once. (There may be some optimization there). Calling finish insures that all queued calls are executed upon your 2d object before you call swapbuffers. The screen also has a finish which is called by swapbuffers

[RokuMarkn]

In OpenGL implementations, Finish() calls glFinish(). In DirectFB implementations, it calls WaitIdle(). You can read the documentation for those calls for more detail, but if you don't call Finish, you're relying on timing to ensure that all drawing operations to a bitmap are complete before you use the contents. Depending on the timing of your app, this may well work, but it's risky and if some later change causes timing to change, your code might start failing unexpectedly.

--Mark

[squirreltown]

"NewManLiving" wrote:
A queue is used to stack drawing calls so that when you write to a bitmap for example your update is not necessarily written immediately to the bitmap but stacked and then written all at once. (There may be some optimization there). Calling finish insures that all queued calls are executed upon your 2d object before you call swapbuffers. The screen also has a finish which is called by swapbuffers

Right , I understand that as thats basically how the docs describe it. What I'm saying is I never use it, and never see any visible effect from not using it.

"NewManLiving" wrote:
for example your update is not necessarily written immediately to the bitmap but stacked and then written all at once.

Ok, but what is it waiting for? Doesn't B/S process things in the order they're written? You're saying if I write bitmap.drawthis and then bitmap.drawthat that it waits for the second call before drawing both? how does it know whats coming? Is there a look-ahead process?

[squirreltown]

"RokuMarkn" wrote:
In OpenGL implementations, Finish() calls glFinish(). In DirectFB implementations, it calls WaitIdle(). You can read the documentation for those calls for more detail, but if you don't call Finish, you're relying on timing to ensure that all drawing operations to a bitmap are complete before you use the contents. Depending on the timing of your app, this may well work, but it's risky and if some later change causes timing to change, your code might start failing unexpectedly.

--Mark

Are you saying that drawing call are asynchronous? And if my timing is based on swapbuffers() which is a minimum of 16 ms then the scary timing problems you refer to must be way below that threshold no? From your description it seems like i should have run into some sort of problems constantly writing into bitmaps and showing them immediately but I haven't seen an issue, thats why I'm asking.