-
Notifications
You must be signed in to change notification settings - Fork 581
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
Display abstraction interface #1644
Comments
I fully agree with the requirement. Additionally, there should be an implementation for And then, it would be great if we had an OS-independent way of taking a screen shot of the main display, so that one could do things like mirroring (part of) the main screen to a SPI display. Looking for the linux way of doing that didn't really bring up many solutions for me yet. [This is independent, but would make these displays a lot more useful] |
I am also favorable to the proposal but I have a couple of observations. The name of the interface is ambiguous. Displays based on the Hitachi interface can't do most of the thing specified in the interface. I would rather split text and graphics display methods. They could eventually be implemented both on most graphical devices. Also, given the amount of devices that can display something, it would be better providing a method to return its capabilties. This could avoid the mess of catching the |
It would be good to look at some of the display options at https://www.daktronics.com/ and see if this interface (or any we propose) would satisfy the style of displays that those folks provide. |
@dotMorten we've already had a long discussion about similar interface in the past. See conversation at #189 - I'm fine with continuing the conversation after taking all points in there and this thread into consideration. Please do not block your PR on this. If you want we can schedule a call to share all our past points why we didn't ship anything like that yet and what should we take into account and do initial review - ideally if you find an existing abstraction inside ImageSharp which you could use in our bindings that would be best - I'd personally encourage us to not try to solve problems in this repo which are out of scope for it (our main goal is to provide bindings for different devices and not be a generic purpose library for anything related to IoT) - having said that most of the people can appreciate good and consistent design (which implies abstraction) but best if we didn't design it ourselves and rather reused something existing. |
Maybe we could take inspiration from OpenWF Display spec that I helped write a few years ago. It is written specifically with these type of embedded display HWs in mind. https://www.khronos.org/registry/OpenWF/ Some comments on proposed API.
|
Old comment of basing bitmaps/buffers on Memory seems viable still, ImageSharp supports that too. |
@maloo would you be interested in driving this issue? Most of us are not graphics experts by any means, would you be interested perhaps in making some short presentation or just proposing specific APIs/changes? (or both) We can review that during one of our triage meeting. Note that what we care about a lot is possibility to port this code to nanoFramework so less complexity makes it easier |
I would love to, but as everyone else I have many other higher prio stuff. I was planning to do this for a product a few years ago when I started using dotnet iot, but I ended up using neopixels instead for the interface and that I already pushed. |
Just want to put on the table that we could also start with an existing API/implementation and morph it to what we want. There is a mid-point between "start from scratch" and "use an existing package". |
@maloo I don't want to promise you a specific timeline here - I will bring this up today during our triage meeting. We currently have couple of other subjects going on so not sure when this will be picked up (Serial Ports, Firmata, nanoFramework) |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
[Triage] Blocked on #1767 |
[Triage] not blocked anymore |
assigning to @pgrawehr to reiterate on the interface design and figure out next steps |
I've noticed all the various displays have different methods exposed to work with them. I'd like to suggest an interface (or abstract base class) is provided for all of them, so we can write common code, and quickly swap out the display used in our code, without having to change anything but the display creation.
I've found that I'd often change displays to something better, and having rewrite quite a lot of code because of it, and it would also make it easier for people to adapt existing code and apps for the display they have.
For instance it's pretty typical that there's a method for
SendBitmap(Bitmap)
,ClearScreen()
andFillRect(Color,Rectangle
)`, and it would be nice to be able to write display-agnostic code against all of these. It would also allow us to build a common text and line drawing API for all of these.The interface would also need a few getters to get display info like width/height, bit depth, etc, information about whether there's on/off control (and if so methods for doing that).
Describe the ideal solution
Suggestion for interface
The text was updated successfully, but these errors were encountered: