A question about fast incremental updates

[ACTCMS]

I've been playing with MLPanel trying to figure out how incremental updates work...
Every 10 seconds, MLPanel displays a randomly located rectangle superimposed on a full screen black background. The second render doesn't clear the rectangle from the first, but subsequent renders clear the rectangle from the previous one.

Starting from here in the log

Code:

2009-03-13 22:18:38.254 VERBOSE [6] Unrequested needsRendering()...
2009-03-13 22:18:38.285 VERBOSE [6] Creating new render hash list
2009-03-13 22:18:38.285 VERBOSE [6]  - adding render hash: background:0,0,640,500:False
2009-03-13 22:18:38.301 VERBOSE [6]  - adding render hash: static (MLBackGround):0,0,640,500:False
2009-03-13 22:18:38.301 VERBOSE [6]  - adding render hash: static (NotPlaying-Small-6):236,85,179,125:False
2009-03-13 22:18:38.301 VERBOSE [6]  - ...updated screen rectangle now: 0, 0, 640, 500
2009-03-13 22:18:38.301 VERBOSE [6] sendIncrementalFrame3 (loc = 44,40) (rect = {X=0,Y=0,Width=640,Height=500})

I'm puzzled as to where these co-ordinates are coming from on the second render

Code:

2009-03-13 22:18:48.463 VERBOSE [6] Sending clearing update for: 64, 425, 512, 50

I'm testing on an MVP since I don't have access to an NMT

[mvallevand]

Did you check how this works with 0,0 as the offset?

Martin

[ACTCMS]

Did you check how this works with 0,0 as the offset?

Martin

Not until now... but this is what happens...

Code:

2009-03-14 01:04:14.313 VERBOSE [6] Unrequested needsRendering()...
2009-03-14 01:04:14.344 VERBOSE [6] Creating new render hash list
2009-03-14 01:04:14.344 VERBOSE [6]  - adding render hash: background:0,0,720,576:False
2009-03-14 01:04:14.360 VERBOSE [6]  - adding render hash: static (MLBackGround):0,0,720,576:False
2009-03-14 01:04:14.376 VERBOSE [6]  - adding render hash: static (NotPlaying-Small-6):172,161,201,144:False
2009-03-14 01:04:14.376 VERBOSE [6]  - ...updated screen rectangle now: 0, 0, 720, 576
2009-03-14 01:04:14.376 VERBOSE [6] sendIncrementalFrame3 (loc = 0,0) (rect = {X=0,Y=0,Width=720,Height=576})

Code:

2009-03-14 01:04:24.553 VERBOSE [6] Sending clearing update for: 72, 489, 576, 57
2009-03-14 01:04:24.553 VERBOSE [6] sendIncrementalFrame3 (loc = 0,0) (rect = {X=72,Y=489,Width=576,Height=57})

The symptom remains. The co-ordinates have changed from the first post, but everytime I carry out the test with the 0,0 offset, the new co-ordinates are as shown.

Alex

[mvallevand]

Ok these look consistent for a 10% overscan allowance being cleared.

Martin

[ACTCMS]

Ok these look consistent for a 10% overscan allowance being cleared.

Martin

Yep (I just did the rough maths)... I'm just not sure why the first clearance always uses the same co-ordinates...

Alex

[mvallevand]

Sub, do you have tips on using Incremental Updates. I'm about to throw in the towel on MusicLibrary 3 because Incremental Updates don't work at all, there are pieces of what I do want and don't want all over the screen. I can't turn it off for the NMT, performance needs it.

I get this error but I have no idea what gbpvr is expecting maybe ListBackground?

Code:

2009-12-06 18:51:33.508    ERROR    [6]    Unexpected error in doCompositeRendering(): System.NullReferenceException: Object reference not set to an instance of an object.
   at GBPVRX2.MVP.x3ca133dee7547455.x19e39e0d5aeedfb8()

Martin

[sub]

Can you post the few lines immediately prior that crash message in log? This would hopefully give some clues about which aspect of render list it doesnt like.

Is there maybe an element in the render list which has the name set to null?

[mvallevand]

I can't say for certain that there are no null entries in the renderlist, but I haven't see it, in the logs. Is has been extremely difficult for me to put this logic together, there are three UiLists in play from different cs files and they load different skins for the same screen dynamically which is beyond my skill level at this point.

Here is one log of the rendering, it looks like the rendering of the full screen image image fails, and all the partial updates are than sent.

Martin

[sub]

The renderlist stuff is pretty complicated, and then the incremental rendering stuff was added a year later or so, and needed to be done without changing the mechanisms that plugins used for the renderer list, leading to an even more complicated set of processing logic.

For that crash, it doesnt like something about one of the items in the render list. To work out what exactly, you'd probably need to run it in the debugger to catch that error, then inspect that render list to look at the UiElement after the one with the name "static (ScreenDetails)" which seems to be about the 30th element in the list.

Regarding the incremental updates, basically the app goes through the items in the render list, making a hash of the name/location/size/forceRefresh attribute, and compares them with the last render list hash to determine which bits have changed. It cant pratically compare the actual pixels from the previous and next screen - that'd be way too slow, so it makes a guess based on the info it has available (ie the hash string derived from name/location/size/forceRefresh).

If the new render hash list is shorter than the old one, then it works on the assumption that there is some bits of the screen that were previously visible which arent any more, so it goes for a complete screen update.

You can look at lines after the log message "Creating new render hash list" to see it checking the hash for element in the render list. If the render list is shorter you see stuff like "...forcing whole screen update". Usually Video Library dont reduce the number of things rendered on the screen, so this doesnt actually happen that often. I thought I should mention it though, since I dont know what the Music Library 3 is doing for the render list.

[mvallevand]

Thanks a lot for the explanation sub I understand it better now. I found the item added after ScreenDetail and commenting it out did allow proper rendering that matches the PC and non-incremental mode which must ignore the error.

Martin