8000 framebuf module : Add support for rotation · Issue #4963 · micropython/micropython · GitHub
[go: up one dir, main page]

Skip to content

framebuf module : Add support for rotation #4963

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

Open
iommu opened this issue Jul 31, 2019 · 8 comments
Open

framebuf module : Add support for rotation #4963

iommu opened this issue Jul 31, 2019 · 8 comments

Comments

@iommu
Copy link
iommu commented Jul 31, 2019

Add support for setting the rotation a frame buffer in the micropython framebuf module.

Currently the orientation of a display is limited by it's physical rotation. The best method I found to rotate a display is to use the adafruit circuitpython framebuf implementation instead of the native micropython one as it does allow for setting rotation.

@peterhinch
Copy link
Contributor

The Adafruit implementation performs operations in Python where the official version uses C so I'd expect it to be very much slower.

@iommu
Copy link
Author
iommu commented Jul 31, 2019

This is true, using it I can see it's a lot slower but it's still a mis 8000 sing feature from the native lib.

From the forums the best native solution people are currently recommending is to create 2 framebuffers (one rotated, one not) and then to write one on top of the other using the blit() function. Generally memory is a fairly scarce resource so this is far from an optimal solution.

@MrSurly
Copy link
Contributor
MrSurly commented Jul 31, 2019

is to create 2 framebuffers (one rotated, one not) and then to write one on top of the other

Why not 2 framebuffers pointing to the same block of RAM?

@peterhinch
Copy link
Contributor

I don't think this would work in the general case where a pixel occupies more than one byte (e.g. RGB565).

@MrSurly
Copy link
Contributor
MrSurly commented Jul 31, 2019

I don't think this would work in the general case where a pixel occupies more than one byte (e.g. RGB565).

Hmm, yeah, seems it needs a rotational transform for the actual coordinates ... but I haven't thought about this too deeply =P

@dhalbert
Copy link
Contributor

A bit of a diversion but in CircuitPython we have replaced framebuf with displayio, which takes a rather different approach, to support a wide variety of displays. Rotation is included, and lots of other stuff. https://circuitpython.readthedocs.io/en/latest/shared-bindings/displayio/__init__.html

@peterhinch
Copy link
Contributor

Arguably a full solution to rotation should include the three possible rotated directions (I have had a request for upside down display on one of my graphics libraries).

There are a range of useful enhancements to framebuf some of which which have been discussed e.g. #2973. I would like to see further graphics primitives such as circles and triangles with filled variants which could readily be implemented using standard algorithms. I would code these if I thought a PR might be approved. I suspect framebuf does not have a high priority; my offer to implement a "micro" solution to #2973 has gone unanswered.

@andrewleech
Copy link
Contributor

OpenMV has a wide range of image manipulation functions like this already available in C.

Their rotation function for instance does handle 3 dimensions.

You can use a (slightly out of date) version of their imaging library as a C user module with mainline python as described here: https://gitlab.com/alelec/mp_omv

Or perhaps it's a good time to work with them to bring some of their great image buffer work into mainline, as an optional module.

tannewt pushed a commit to tannewt/circuitpython that referenced this issue Jul 9, 2021
Enable audiomixer for esp32s2.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3F3B
Projects
None yet
Development

No branches or pull requests

5 participants
0