[PD] GEM & RPi

Dan Wilcox danomatika at gmail.com
Wed May 16 13:59:14 CEST 2018

> On May 16, 2018, at 1:34 PM, pd-list-request at lists.iem.at wrote:
> Date: Wed, 16 May 2018 13:30:35 +0200
> From: oliver <oliver at klingt.org <mailto:oliver at klingt.org>>
> To: michael strohmann <itsnotfair9 at gmail.com <mailto:itsnotfair9 at gmail.com>>
> Cc: pd-list at mail.iem.at <mailto:pd-list at mail.iem.at>
> Subject: Re: [PD] GEM & RPi
> Message-ID: <affda5cb3702ccef13c9e4a0a650ec60 at mail.klingt.org <mailto:affda5cb3702ccef13c9e4a0a650ec60 at mail.klingt.org>>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> i myself tried GEM some time ago on a PI but quickly gave up on 
> displaying images/movies.
> i guess there was no GL support whatsoever.
> but that was on a PI2 and i don't know about the openGL status on newer 
> raspbian versions.

My 2 cents:

A common misconception seems to be that RPI "doesn't support OpenGL". It does, including the original RPI. The issue is that they all use Open GL ES which is *not* the same as full blown OpenGL. ES is a subset of the spec for embedded systems and now mainly mobile devices. It simplifies and removes some extra functionality in order to run things better on lower specs machines, etc.

The issue is more that software which is written for normal OpenGL doesn't generally work directly with OpenGL ES and some of the missing parts are done in software aka on the CPU the through X windows when running Linux. So in the case of GEM, you have to run X windows and some things run more slowly depending on what your doing as not everything is actually running on the GPU.

And for movies, if you use the mechanism to decode compressed video on the GPU, an RPI 1 can play HD x264 movies *no problem* as well as with other light weight codecs. The problem comes when your software doesn't;t know how to do that and tries to do it all on the CPU.

Now, GEM *could* be updated to support OpenGL ES directly and it could theoretically run on the commandline without needing X and run very much faster without some of the software emulation. It could also use the hardware movie decoding. However, we'd need someone to come along and do that work...

OpenFrameworks has, on the other hand, a native OpenGL ES renderer and window handling on the commandline which is why I suggested it. As Ofelia is built using OpenFrameworks, that might be a good option as well. For the movie stuff, it would need to also include support for the RPI-only  OMAP video player addon, I believe.

An even cooler, old school solution to all of this could be to create a simple console app that loads the largest console font available in the system and simply clears the console buffer and writes the time each update ala ncsurses, etc. Now *that* would be fast :)

Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180516/965658d6/attachment.html>

More information about the Pd-list mailing list