Skip to content
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

[Feature] Poco.makeColor (or similar) #8

Closed
rwaldron opened this issue Dec 5, 2017 · 6 comments
Closed

[Feature] Poco.makeColor (or similar) #8

rwaldron opened this issue Dec 5, 2017 · 6 comments

Comments

@rwaldron
Copy link
Contributor

rwaldron commented Dec 5, 2017

Right now the only way to make a PocoPixel value is to make an instance of Poco and call the makeColor method. Since this value is non-this-sensitive, it would be great to be able to access the functionality as a static method of Poco. There is a precedent in the C code for this API, ie. PocoMakeColor(r, g, b).

@rwaldron
Copy link
Contributor Author

rwaldron commented Dec 5, 2017

If there is interest in this addition, I have a patch. Let me know!

@phoddie
Copy link
Collaborator

phoddie commented Dec 6, 2017

Fair point. The native PocoMakeColor certainly suggests a JavaScript equivalent. The reason it is implemented that way is that I want to keep open the option of Poco supporting multiple output pixel formats in the future. That's impractical on ESP8266, but easy to imagine with the bigger addressable flash space (e.g. code space) on the most recent MCUs. In that case, the result of makeColor would depend on the Poco instance. Maybe I should make that intention more clear by adding a poco parameter to PocoMakeColor even though it will be unused in the current implementation. What do you think?

@rwaldron
Copy link
Contributor Author

rwaldron commented Dec 6, 2017

What if semantics of the proposed Poco.makeColor(r, g, b) were defined to allow returning the ideal output pixel format of target MCU, whatever that might be? So, for example Poco.makeColor(r, g, b) would return an 8-bit value when the target is ESP8266 (as poco.makeColor(r, g, b) does today), and a 24-bit value when the target is some MCU that offers adequate flash space. Since you have the authority to say "this value is expected to be used with X, Y, & Z apis" those APIs can also be designed to accept the ideal pixel format for the target MCU.

@phoddie
Copy link
Collaborator

phoddie commented Dec 6, 2017

From Poco.prototype.makeColor's perspective, there isn't a preferred or ideal pixel format for the MCU. The output it is bound to is what matters.

Going back to the the docs, for Poco.prototype.makeColor the return value "is in the format of the PixelsOut instance bound to the Poco instance." On Moddable Zero when Poco is bound to the display driver as its PixelsOut, the ILI9341 controller, the pixel format is RGB565LE.

A second PixelsOut could be present on the device, for example BufferOutwhich is used to render to an offscreen bitmap. It could be configured to create a bitmap in a different pixel format (e.g. Gray256). In that case, the values from Poco.prototype.makeColor should be 8-bit gray instead of 16-bit RGB565LE. I say "should be" because the implementation today is limited to a single rendering pixel format to conserve space. But that may not always be the case.

There is an example of using BufferOut in examples/commodetto/docs/main.js in the offscreen case. You can see in the call to the BufferOut constructor where it could be instantiated with any pixel format.

Poco.prototype.makeColor operates in device pixels, rather than an intermediate form, to allow a script to convert a given color once to device color (e.g. device pixel) and re-use that. It save a little time.

@rwaldron
Copy link
Contributor Author

rwaldron commented Dec 6, 2017

Ah! Thank you @phoddie for your patience and taking the time to clarify all of this (Sometimes my excitement and enthusiasm get ahead of me).

@phoddie
Copy link
Collaborator

phoddie commented Dec 6, 2017

@rwaldron, thanks for staying with the discussion. I will update the PocoMakeColor macro as described so the intent is more clear.

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

No branches or pull requests

2 participants