8000 extmod/framebuf: Add "remap" option to blit by deshipu · Pull Request #3238 · micropython/micropython · GitHub
[go: up one dir, main page]

Skip to content

extmod/framebuf: Add "remap" option to blit #3238

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

Closed
wants to merge 4 commits into from

Conversation

deshipu
Copy link
Contributor
@deshipu deshipu commented Jul 24, 2017

Add an optional keyword argument "remap" to the framebuf.blit method,
which allows to pass an array specifying the color palette to be used
for mapping the colors while blitting. This makes it possible to blit
between framebufs with different color depths, and also to do palette
effects.

Add an optional keyword argument "remap" to the framebuf.blit method,
which allows to pass an array specifying the color palette to be used
for mapping the colors while blitting. This makes it possible to blit
between framebufs with different color depths, and also to do palette
effects.
@deshipu deshipu changed the title [WIP] extmod/framebuf: Add "remap" option to blit extmod/framebuf: Add "remap" option to blit Jul 31, 2017
@deshipu
Copy link
Contributor Author
deshipu commented Jul 31, 2017

I added the docs and a simple test.

@deshipu
Copy link
Contributor Author
deshipu commented Oct 8, 2017

Is there anything else that needs to be done here?

@dpgeorge
Copy link
Member

Overall the idea is good, thanks.

Considering code size: it might be more compact to use positional args rather than have a full array of allowed args. If it's positional then you need to specify "key" if you want to specify "remap", but you can just pass -1 for key if you don't want to use that feature.

How about making the remap argument something with the buffer protocol (eg bytes, bytearray), rather than a list/tuple? Using a buffer object would allow much more compact mappings and allow them to be stored in ROM.

@deshipu
Copy link
Contributor Author
deshipu commented Oct 16, 2017

Not sure what you mean with list/tuple. 8000 I used array of ints, because that seems to fit the color data type best. How would bytes/bytearray work? Take two bytes for every color?

@deshipu
Copy link
Contributor Author
deshipu commented Oct 16, 2017

Oh, I see I have a list in the test, not an array — I guess it's getting converted? I'm not sure how this all works internally in MicroPython, to be honest.

@dpgeorge
Copy link
Member

Not sure what you mean with list/tuple. I used array of ints, because that seems to fit the color data type best. How would bytes/bytearray work? Take two bytes for every color?

The mp_obj_get_array helper function gets the items in either a tuple or a list. It doesn't work for bytes, bytearray or array.array objects.

I'd suggest converting this to mp_get_buffer_raise to support bytes, bytearray and array.array objects. You can use mp_binary_get_val_array to help extract the value from the array, and that will automatically type it to the correct byte-width. Eg array.array('B', [1, 2, 3]) will use bytes and array.array('H', [1, 2, 3]) will use 16-bits. And not to forget that in the future the module may support 32-bit colour width, so makes sense to try and support that as well (which array.array can).

@deshipu deshipu closed this Mar 2, 2019
tannewt pushed a commit to tannewt/circuitpython that referenced this pull request Aug 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0