Binding API Discussion

[kdschlosser]

I have spent some time tearing into the generated C binding code for LVGL. While the code does work from looking at it I had always thought it could be improved upon. There are a couple of things I really didn't like about it. The first thing is everything being lumped into a single source file that has some 50k lines of code. The entire API was plopped into a single python module, The downside of this is the absolute HUGE amount of code that needs to load upon import. Python is not like compiled C code where only the bits and pieces that get used actually get loaded. Even if it's not being used it ends up betting loaded into RAM. I believe we can mitigate some of this by duplicating the LVGL file/folder structure. I would need to work out the mechanics so from lvgl.widgets import slider would work and ONLY the code that is needed for the slider to work would get imported. so if you don't use the button widget code if you don't import it it's not going to get loaded.

Another thing I have not liked about it is how it mangles the original LVGL API. This makes the binding code generator extremely complicated and when something breaks it's a royal pain to fix. There is also the issue with documentation. If the LVGL API is followed there really would only need to be a very minimal amount of documentation written which is always a plus. The current way things are organized makes it confusing to use.

I also don't know if a code generator is the best way to go. The problem with code generation is it has to be written so it's a one size fits all kind of thing. That means it's not going to generate the best code that can possibly be written. This is because it has to be written so it is able to fit the needs of many things instead of being purpose written. As an example. I took the generated code for lv_area_t and placed it all into a single file. Everything that was used to create that class was put in there. It was over 900 lines of code just for that single class. I then reworked the code by flattening the API so it is the same as the LVGL API and purpose wrote the code. Now it takes up about 400 lines and all the same things are there and available. It is going to consume quite a bit less RAM, it will run faster and it is going to take up less flash space all while providing the exact same functionality.

Does anyone have an input or suggestions/ideas?

I get into this because of not being able to update to LVGL 9.2 without having to spend a great deal of time hammering out the problems in the binding generation script. It is going to be easier to write the binding code manually.

[favnec5]

From my point of view, you find yourself in the same situation as your predecessors. The more time goes by, the more I think that lvgl will one day have to be cloned into another simpler project maintained in pure python. By this I mean freezing most of the calculations that require a lot of c and keeping the rest out of c in python.
I get the impression that the lvgl community doesn't give a damn about the python port, and people like me, who mostly do python, unfortunately can't help you in this state.

[favnec5]

If the initiators of lvgl didn't think this through from the start, you'll be pulling your hair out with every release.
And the same goes for your own lcd functions. For example, I remember a time when Mpy integrated a python esp-idf module that contain binding to natives c esp_... functions. This allowed me to develop my own pure python I2s driver before the Mpy community did it in a the c machine module.

[favnec5]

By doing this on esp_lcd, it would have allowed the python community to develop more things on the python side than on the c side, where you're the only master here. I don't know if you understand me, but that's the way I see Mpy.

[kdschlosser]

you don't want to have the code written in pure python It's going to run 200 times slower than it does in C and it is also going to consume more memory than it does in C. C code IS the better way to go. I feel that eliminating the binding code generator is what needs to be done and the binding mode needs to be written by a person this way it will run better. Right now the amount of code that runs for doing something as wimple as making a function call is rather crazy...

This repo is an offshoot of the original binding. My goal was to provide a common API across MCU's for the display drivers and to create a common API across the MCU's for the different busses that are being used. I wanted any bus to be able to be used with any driver. The drivers I also wanted to be written in python so they are runtime compiled instead of something that can only be changed by recompiling the firmware. I also wanted them written in python so the classes could be subclassed and methods can be overridden in order to customize for a specific use case.

I also had the goal of fixing things like the SPI SDCard reader and not being able to use that if it was connected to a bus that had something else on it.

I wanted to be able to access both cores on an ESP32 from inside of python. Being locked to only using one core really kills the performance aspect of the ESP32. BT and WiFi to some degree run on the second core but only is you are actually using those technologies. If you aren't then guess what? the core sits there idle and doing nothing. I have been in conversation with the folks over at espressif to see if they would add the code to push the ISR callbacks to the second core. No need to tie up the application core to handle creating a new DMA transaction. That is something that can be done from the other core.

The problem with trying to handle everything in the Python side is going to be dealing with data conversions. it is simply not cut and dry to be able to do that. integer types along are a HUGE headache to deal with. There needs to be a layer between the Python code and the C code to handle those kinds of things.

For the most part almost every single parameter that is available in a display driver is exposed to the user. There are some things that are because they serve no purpose or it is simply easier to not expose them and just handle what things needs to be set to in that middle layer. This is something that I have done. If you had to duplicate into Python the LCD bus code I have written it would easily consume 3 times for memory. Remember that Python is runtime compiled so the source code itself is loaded into memory and then a lexer reads it and then it gets compiled into something that is usable. That all takes time and memory to do.

[kdschlosser]

I do believe that LVGL is becoming too bloated. There should be NO drivers included with it. There should be separate libraries for those drivers. The "drawing" API needs to be written in a manner that would make it easy to add a renderer or to be able to "mix and match" renderers which can only be done by use of macros not all hardware accelerators implement all of the same rendering functions. so having the ability to render a circle using software and using the hardware to render a line should be possible.

I originally didn't want to include any display and touch drivers with this repo. I wanted to have a separate repo for those and I may do that. drivers are optional and the user should be able to use their own. Except for the bus drivers because those would be required no matter what display is used.

IDK if you know this or not but you can choose to not bake a display driver into the firmware and you can upload your own if you want. You can also bake in more than one driver as well by adding additional DISPLAY= build parameters. You can also bake in your own custom driver by using a path to the driver instead of the driver name. The same thing holds true for the indev drivers as well.

[favnec5]

I understand, my point of view probably can't technically succeed.
Yyes lvgl has gone a bit elsewhere...

nop I didn't know that for drivers, good to know!

By the way, I'm still wondering about the choice of integrating all this directly into the micropython firmware itself.
Because I know that many people's fantasy is to take the basic mpy firmware, make an import and that's it.
Why have you chosen not to put the drivers in a simple mpy file ?
(https://docs.micropython.org/en/latest/develop/natmod.html)