How to reduce the memory consumption of the object definition

[pythoncoder]

...My major point here is, that a small set of fonts always fits into flash, so compressing is hardly a benefit.

Absolutely. I have no appetite for following that route either.

The issue of the compiler running out of heap, or needing larger contiguous blocks than it can find, is a curse. I've not yet figured out the best solution - perhaps you already have? What I had in mind was putting the code that won't cross compile (e.g. Viper) into separate modules. Precompiling the stable code either into mpy modules or into flash as frozen bytecode. And putting fonts into frozen bytecode.

The frozen modules and any mpy modules can then be imported without invoking the compiler so hopefully it will have an easier task.

If the Viper is to go into separate modules it would require changes to tft.py to change the functions from static methods to stand-alone functions.

When I was developing the e-paper driver I put my problems down to the buffers required. I've been disappointed to encounter memory issues with your driver which is relatively frugal with RAM. Even with my scheduler and my GUI code the heap usage is under 50% yet I've had errors and occasional crashes just on importing. But at least precompilation and persistent bytecode offer potential solutions.

I'd very much like to hear your thoughts, both on the general problem and on any changes to the tft module you might be considering.

[Roberthh]

I just started to sort out the function of the tft driver into three classes, tft_base with the low level drivers, tft_draw with the drawing functions and tft_text with all the text and font handling. By LOC, tft_base will be the largest, but that contains many duplicate stuff that can be eliminated. I'm not sure that a static member of a class cannot be called form outside. It seems to me that I did that before, by referencing the class name and not it's instance. I have to give it a try.

[pythoncoder]

Static and class methods can be called by referencing them by the class name. However static methods have no access to the class so there is nothing to stop you redefining them as plain functions. Their principal purpose, as far as I'm aware, is to make it evident to the reader/user that they are associated with the class.

A similar modularisation effect can be achieved by putting plain functions into a Python module e.g tft_driver.py with the function being accessed by (say)

Code: Select all

 tft_driver.displaySCR(data, size)

The main merit is that it would enable them to be split out into a separate module if you plan to go that route.

It's a matter of code style and opinions will doubtless vary. I use bound methods and plain functions on an ad hoc basis.

The event driven GUI stuff looks promising and I'll post some example code shortly.

[Roberthh]

That's obviously true, and the driver functions declared as static do not need any element of the class. I would have seen that more as an element of (coding-)style. What I have to try is having one class as frozen bytecode, including a module or class not frozen. I do not see a reason why not, but trying it with a simple example is better.

[pythoncoder]

I wondered about this at the outset. It works and we're doing it with the machine generated font files which have code like:

Code: Select all

import TFTfont
...
font8mono = TFTfont.TFTFont(_font8mono, _font8mono_index, 14, 8, 96)

You can freeze the font file bytecode while TFTfont.py is in the filesystem. Impressive, isn't it

[Roberthh]

I tried it and it worked instantly, saving a lot of RAM space.