-
Notifications
You must be signed in to change notification settings - Fork 10
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
Remove canvas dependency #10
Comments
Thanks for the kind words! I too, wish that I'd be open to using a different library, but as far as I know If you disagree, I'm happy to hear what your suggestion would be - specifically I'd be curious how you'd implement some of the examples. |
The ideal thing for me is to have a method like this:
It takes in a pre-generated rgb buffer of the correct dimensions, and does the required pixel manipulation before writing it out. While it makes the usage a lot less elegant, it can also be used with canvas manually. Something like:
The main downside being that it will be up to the callers to know what dimensions to create the canvas, but they could be exposed as properties on the class (This is what is done the elgato-stream-deck, as different models have different display sizes) I actually implemented that method to allow me to do some testing yesteray. I was trying to draw an already generated rgb pixel buffer, but after some fighting with trying to figure out how to get that onto the canvas in the correct colour space, I gave up and wrote this alternate method. If you like I can throw together a branch with this actually implemented, so you can see it in action |
I'm happy with a compromise, if you're open to it: I would support implementing the It would also be nice if the |
That all sounds ideal for me.
I would like to be able to say that is enough, but unfortunately the presence of the library is still problematic for me. But the big problem is that I expect this to be used on a raspberry pi a lot. Unfortunately as canvas doesnt have arm prebuilds, that means each machine will need to compile it locally. |
Thank you for testing the RasPi scenario, that's very useful! It strengthens the case for decoupling. Here's a possible solution that will satisfy both of us... What if we made That way:
|
I just received a loupedeck live and was expecting to have to finish/rework https://github.com/bitfocus/loupedeck-ct to be able to use it. Finding a library that is working and with a reasonable api was a nice surprise!
One problem I do have however, is that this library depends on
canvas
. This is a bit of a dealbreaker for me, as I already havesharp
being used heavily in the projects, andcanvas
are known to not be compatible with each other https://sharp.pixelplumbing.com/install#canvas-and-windows.Are you open to removing the dependency on canvas?
In node-elgato-stream-deck it is expecting buffers of the correct dimensions to be supplied, and then does some manual buffer manipulation to do any colour conversion or image flipping. Doing it in nodejs like this doesnt have much of a performance impact from what I have found. (Now I am wondering if I could make it faster.. perhaps a perfect use case for wasm?)
This lets users of the library bring whatever image generation technology they want. I know of one project which uses a custom button drawing class, with a partner project which receives pre-generated buffers over tcp, and others which are using sharp to render an svg to a buffer. I think I have seen some users who are using 'inefficient' methods because they only need a few images that never change, so a native library is more effort than benefit.
The text was updated successfully, but these errors were encountered: