-
Notifications
You must be signed in to change notification settings - Fork 18
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
Raspberry Pi 4 support #44
Comments
Good to have an issue open on this. I've played around with the Pi 4 and have been in touch with the author of glslViewer, and yeah — it's not looking like there will be a good fix in the short term. For some background, the original POC of openframe did actually do everything in a browser! At the time it wasn't possible to get WebGL running on the pi, so no shaders. Once we started working on the more fully-realized version of openframe, we implemented our current model of having format extensions which define their requirements and how they should run artworks, and glslViewer was a great fit as it was super fast and lightweight and we had the support of the author who integrated openframe into his shader web editing tool — this led to a lot of great initial contributions. I'm hesitant to move the core format extensions to chromium mostly because of performance concerns — historically, chromium was the least performant aspect of openframe. That said, I'm not entirely opposed to the idea, especially as performance continues to improve... @jvolker I'd suggest you create an image and/or shader extension of your own that uses chromium, and play around with it. If you're satisfied with the performance, publish it so that others can play around with it too. |
What if we use Chromium as a temporary fix only for the Pi 4 until there is a different solution? I reckon the image extension is the most important of all extensions, it is broken at the moment and I'm afraid this leads to frustration of new users. I can work on a fork of this that implements this. |
Good news! The author of As such, I'm going to close this issue. Since the core of the idea behind Openframe is that an artwork format extension can define exactly how artworks are displayed, I'd like to avoid using Chromium for formats that don't specifically require it. I understand the additional desire to have attribution displayed, but for now I think that requirement is secondary and doesn't warrant reliance on Chromium. |
That is amazing! 🎉
I'm going to start new threads to continue this conversation. |
I've just tested Openframe on the Raspberry Pi 4 running
2019-07-10-raspbian-buster
.Video
okay
Website
okay, after running
sudo apt-get install xserver-xorg-legacy
Images
Error:
* failed to add service - already in use?
Shader
Error:
* failed to add service - already in use?
The image and shader extensions are based on glslViewer which has been reported not to support Raspberry Pi 4 currently. patriciogonzalezvivo/glslViewer#141 (comment)
I've also successfully tested WebGL on the Raspi 4, which means shaders could run in Chromium.
What is the best way to go from here? Two basic options:
It sounds like it's going to be a while until a fix for glslViewer is available. I think it is important to fix the extensions and choose alternatives to be independent of glslViewer. Chromium seems like an easy fix as a there is a working codebase for it in the website extension. I could imagine this might also fix the issue people are having with TFT/SPI/GPIO screens. I could give it a shot.
Taking this even further, basically, all default formats (image, video, shader, website) could run in Chromium. This would also make it easy to display captions with author and title as an overlay. Also, it might offer the possibility to create smooth transitions between artworks. Not sure if using Chromium is generally a good idea for performance reasons on slower Pis, but it seems like it could have other advantages.
The text was updated successfully, but these errors were encountered: