You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[…] 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.
I do understand that Chromium has more of overhead compared to glslViewer and think it makes sense to stick to glslViewer for performance reasons. Though, I do think using Chromium would not break with the core idea behind Openframe. It would still be possible to define exactly how the artwork is being displayed.
I would see two advantages to this:
support for GIF images: we wouldn't need a separate GIF extension. Having two extensions for images I would find somewhat unintuitive.
Maybe moving to LXDE-pi (OpenframeProject/Openframe-Website#14) would bring some performance improvements with Chromium and justify moving away from glslViewer?
The text was updated successfully, but these errors were encountered:
Following up from OpenframeProject/Openframe#44
@jmwohl:
I do understand that Chromium has more of overhead compared to glslViewer and think it makes sense to stick to glslViewer for performance reasons. Though, I do think using Chromium would not break with the core idea behind Openframe. It would still be possible to define exactly how the artwork is being displayed.
I would see two advantages to this:
Maybe moving to LXDE-pi (OpenframeProject/Openframe-Website#14) would bring some performance improvements with Chromium and justify moving away from glslViewer?
The text was updated successfully, but these errors were encountered: