New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add lazy rendering support to Layout #809
Conversation
Thanks! This looks really clean. Using getModified is a nice trick but I think it'll backfire on the Pixl and Bangle.js 2 where getModified is used to know how much of the LCD to 'flip', so we might have to avoid that. You've probably thought about this more than me, but to me it seems like we probably don't need to worry about background colours in h and v... Maybe just during the initial construction phase we just push 'bgCol' down the tree to the children of the group that don't have their own bgCol defined? |
Ah, good point in regards to getModified, I guess I'll have to change that to record the x/y/w/h of the object instead. (Unless you want to add something along the lines of a g.setModified() method that we could re-mark an area as modified.) |
Parent bgCols would still need to be handled by the lazy rendering code, since there might be areas affected by the background color that aren't part of any children. To illustrate, currently this layout:
produces this image: If I enable lazy rendering, it instead results in this: Note how the red areas that aren't covered by any children are missed completely. |
3916554
to
6bd606b
Compare
Okay, I think I've got bg colors working correctly. Demo: https://www.espruino.com/ide/?gist=c9e3ecbea2dfb149314c0130b7698665 |
Looks nice, thanks! It does make the apps nice and tidy. I just did a quick time test on this running on a Bangle2 and it's 84-180ms for just the lazy rendering though, when literally just re-rendering everything using the old code is 60ms. Minification would help I guess (when I figure out why the library breaks when minified). Having said that, the So I guess it reduces flicker on the Bangle 1, but I guess this wouldn't be something we did for performance unless we actually build it into the Espruino firmware as native C code. |
That's a larger difference than I was hoping for... let me do some benchmarking on my Bangle 1. For these benchmarks Layout is being executed from storage, with pretokenization enabled. Benchmark code:
Commit 74e739d, with bg color handling:
Commit 6bd606b, before bg color handling:
espruino/master, for reference:
It looks like the bg color handling comes at some performance cost, even when it shouldn't really be doing anything. 🙁 I might see if I can optimize that more later. On the plus side, lazy rendering doesn't appear to cost anything if you don't use it. 🙂
Yeah, reducing flicker on the Bangle 1 without messy app logic is really the raison d'etre for the feature. Though I would love to see how fast it would run as native C code! |
5c92ea9
to
0c4ac74
Compare
Did a little bit of optimization.
|
This is great - thanks! Just merging. I had a thought last night about how to speed up the update&render functions (switch statements aren't too speedy in Espruino), so I'll give that a try too. Something about the minified Layout code is causing problems for me, although when that can be enabled, I'd hope there would be another bit of a performance improvement. |
Just pushed some extra changes, so layout+render should have seen a decent speed boost now. Minification also works too which gives a minor boost. (On Bangle.js 1)
|
Demo here: https://www.espruino.com/ide/?gist=cc5f26ad897ecaa531b698781d47964a
The overhead of the lazy rendering logic seems overall comparable to the amount of time it saves by not re-rendering things. In the demo most of the time is spent calling
layout.update()
.The one thing this change doesn't currently handle is background colors on "h" or "v" layoutObjects. Those are kind of tricky, since their children are drawn on top of them.