Re: Native C module: accessing objects. Now it's crashing...
Posted: Tue Sep 15, 2020 5:32 am
Yes, I didn't take this into account in my earlier reply... There's just no compile-time way to get hold of the mp_type_framebuf instance.pythoncoder wrote: ↑Sun Sep 13, 2020 2:20 pmI don't know if this type conflict is to be expected - the code could be much simplified if it did not occur or if I could subclass the device from my FrameBuffer, using that class throughout.
As you've already pointed out, the issue is that you end up completely duplicating the FrameBuffer type (and all its code). The only thing they have in common is their name.
Unfortunately I wasn't able to repro your crash (unix 64bit, unix 32bit, PYBD_SF6, or PYBD_SF2).
I wonder instead if you could provide "additional helper methods for framebuffers" and have those helper methods do what's necessary to access the internal state of the framebuffers. The key thing is that they need mp_type_framebuf, but potentially that could be part of the API.
Here's a rough sketch of the idea...
- framebuf_utils is a module that provides a method render(type, dest, src, x, y, x, y, fgcol, bgcol)
- type is expected to be FrameBuffer (i.e. you rely on the Python caller to give you the necessary hook to the builtin FrameBuffer. (I think this would also work if FrameBuffer came from a .mpy too).
- dest and src can both be FrameBuffer-derived instances.
- You get access to the set/get pixel functionality by getting it from the type's locals_dict. (Equivalently you could access other methods on FrameBuffer)
- It's not-quite-but-almost-very-nearly as fast as calling setpixel/getpixel directly, and still gets all the format conversion.
Example implementation and test at:
https://github.com/jimmo/micropython/tr ... ebuf_utils
(I'm not sure I'm actually endorsing this idea, but it does seem to work. I'd love to see an officially supported mechanism for this... but I have no idea how that would work!)