by doing it that way you will also be able to use the timer that does the rendering to set a FreeRTOS notification that will notify a task that you can have running on a different core than LVGL is running on. that second task would set a notification to let the LVGL task know that the rendering has been completed and to swap the buffers in the widget. If doing it this way you could have that “rendering” task clear the idle buffer instead of freeing it and allocating it over and over again.
The above could be done using my MicroPython Binding or writing the code in C instead of using MicroPython. It will not work in the simulator but it does show ways to improve the performance depending on the MCU being used. In your case the ESP32-S3 you would be able to do this.
Yeah I’ve ditched the multi-step approach for now, definitely easier to recycle variables that way.
Here’s the fastest I can get it running with low-res UV/NormTex’s, for now. I thought I’d post it in case you or anyone else would like to try it out and see if there’s any ways to optimize it further
It looks pretty much the same:
The code:
simulator_refmap_test2d_micropython.zip (62.6 KB)
@FishOfTheNorthStar
I think we can clean up the output if we set any pixels that don’t have an alpha of zero to have an alpha of 255 then run it through the texture map and the last step would be to apply anti-aliasing at the end.
Yeah good point, the less data written to the buffer, the better. So actually, to that end, what I’ve done here is cook up a special optimized mode that’s using 8 bit palettized images for the source texture, and the output buffer. That raised the frame rate about 20% immediately, but then what I’ve also done is for this special test, I’ve made a reference texture like the yellow sphere, but for this test it’s just a one pixel wide strip, and that defines everything necessary to render flat 3d planes. So way less buffer reading, too (and storage needed, for that texture). And instead of referencing that texture once per pixel, now it does two lookups to it per line, and then interpolates between those values per pixel, which it can do much faster. That had a really big impact on performance, hard to say exactly how much but I’d guess about 200-300% improvement. Of course it only applies to this special flat-plane test, but that’s pretty useful for a lot of stuff.
This update looks really cool in motion, it’s very smooth (even in the stock simulator)
Anyways here’s the code as it stands, warts and all. Needs cleaned up a lot, but I’m trying not to get to invested in Python for this since that’s really more of an interim step and it’ll all be C soon anyways.
simulator_refmap_test3d_micropython.zip (32.0 KB)
Do you think we’re push maximum reasonable thread length for these forums? I’ve been wondering if we should start a new thread or something, this ones getting bulky.
we can move the discussion into a private message and update this thread with the final results…
@kisvegabor
You really should have a look at some of what is going on here. It’s pretty cool stuff. might be worth taking a look at. Might be something if interest to add into LVGL.
@FishOfTheNorthStar
This is fantastic work you are doing. The double buffering when rendering the output image sure has helped with smoothing things out didn’t it?
1 Like
Thanks! Yeah it sure did smooth it out nice, thanks for all your help with this. I’m not sure how much benefit this little demo actually offers most LVGL users though, most aren’t trying to put a flight simulator on their smart-thermostat etc. But I’m digging through the code some looking for parts that are both ‘Lightweight’ and ‘Versatile’, and maybe those would be worth a look. The part that actually maps one canvas onto another with a warped / perspective the user can define, that seems pretty useful in a lot of situations, and I think I could set it up to work almost identically between pixel art and vector art. That will probably be my next thread.
It’s really fantastic! I’ve already contacted @FishOfTheNorthStar in private to do something together officially. 
1 Like
Ya know. They might not be trying to do a flight simulator but perhaps a background that is animated or maybe icons that animate when hovered over. One of the things you have to remember is that animated images tend to take up a decent amount of space. having the ability to use a texture map and a static image and be able to animate it could be something that might be of interest.
With MicroPython the math is being done 200 times slower than it is able to in C code. The Viper code emitter solves this problem but it is not available in the simulator. I figure the math is being processed just about as fast in Python code as it would be using the Viper code emitter on an MCU. Toss in there JavaScript being a slow fat bloated cow of a programming language and it might just run better on an MCU Using C code or the Viper code emitter.
Any Python code that I write that has complex math and has a large number of objects where interactions between the objects involves a large number of function calls I end up using Cython to convert the Python code into C code so it can be compiled as a C extension module that is able to be used in Python just like any other module is except it runs at the speed of C code.
Python has the benefit of fast development. While I am able to compile LVGL in < 8 seconds I still hate having to do that to test something. It is much easier to hammer things out in Python code and then convert it to C code.
