[u-u] Electronic signage...

[Greg A. Woods]

On 2016-07-13, at 12:22 PM, Dan Astoorian wrote:
> On Wed, 13 Jul 2016 10:45:03 PDT, "Greg A. Woods" writes:
>> 
>> Even if it seems simpler from a first glance, why the heck would you want
>> to run upwards of 5 million lines of code (plus however many million lines
>> are in your chosen Linux kernel and the Xserver), etc., etc., etc., just
>> to display what is a relatively static layout of graphics, video, and images
>> with a text overlay?
> 
> If it solves the problem, there's no real incentive to count how many
> lines of code are in the solution.  For an application like this, you
> can afford to optimize for developer time, not for memory or CPU.  Web
> browsers will do the job, quite well, and they've already been written
> and tested.

Hmmm....  I think you're talking about a different problem.

A web browser is the very antithesis of a good solution whenever a
static form filled with near-real-time data is involved (even ignoring
the video issue).

Especially when a fully generic browser with full HTML-5 or similar
support is used for client-side scripting for something that can
be done directly in the same amount or less of custom code using
a direct display interface.

Pure HTML might be more maintainable than custom Python, if indeed all
that was happening was a static page with auto-refresh, but the same
cannot be said of the amount of JavaScript that would be required to
do what Colin was describing.  That's a hairy fur-ball of potentially
huge impact, never mind being incomprehensible to anyone after a year.

And besides, a static auto-refreshing pure HTML-only page would still
require some mound of code to generate it -- and instead almost exactly
the very same amount of code could directly drive the display, so why
inject yet another custom language (HTML), and massive amount of
interpreter code (any web browser, even a very simple custom one "just"
using the massive webkit library)?  An interface library at the level of
something like Tk would more than suffice.


> I don't think counting the lines of code in the kernel and X server is
> relevant, unless you're suggesting an alternative solution that doesn't
> include those.

It's relevant in terms of estimating the full resource requirements.

Obviously many of the same system libraries, the X server, etc. might
still be required for a custom-code solution.  But the difference between
a Tk-like library and WebKit is literally orders of magnitude.

Of course on an RPi you can indeed use a direct display interface that
doesn't require the X server, though I'm not familiar enough with the
Linux world to know exact details on what's possible.  I think it's
easier with the BSDs, though I haven't tried such a thing yet.  I also
don't know if the native Xserver on the Linux-based RPi systems has a
direct video extension or not, but if it does that probably makes handling
the video easier through X since then it can be contained to a sub-window.

On the other hand apparently 'picamera' can preview directly to a specified
area on the display, so if space is preserved for the video output in the
display form, it could directly feed video without needing any other
library or Xserver support.

-- 
						Greg A. Woods

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 243 bytes
Desc: This is a digitally signed message part
URL: <http://unixunanimous.org/pipermail/u-u/attachments/20160713/0f761180/attachment.bin>