[u-u] Electronic signage...

[Dan Astoorian]

On Wed, 13 Jul 2016 10:45:03 PDT, "Greg A. Woods" writes:
> > The first part of displaying the above is easy enough, a browser the
> > like of Chromium set up in kiosk mode.
> 
> 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.

I wouldn't necessarily choose Chromium as that web browser (in fact, I
didn't), but a web browser is certainly a sensible choice.

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.

> Especially on a RPi?  Even on the latest greatest RPi-B2 or B3 (where such
> extravagance might actually be possible without running out of memory)?
> 
> If you're running any JS in the browser, and you would be, then you can expect
> a browser window with that kind of display to require upwards of 500MB of memory
> plus the main browser process at another 150MB, plus the X server, etc., and
> the browser would be in very serious threat of suffering major memory leaks and
> require restarting at least every 24 hours, if not far more often.  (Though
> Chrome has been getting better at keeping JS from leaking memory in the past
> few months, but by no means can you trust it.)

As I mentioned, I haven't tried it with Chromium, but kweb on our
signage is currently taking up about 400MB of mapped VM (of which about
150MB is resident, 100MB shared).

The only time our Pis have ever even had to breathe heavy was when
someone started uploading 5500x3100 JPGs into the slideshow (for
1920x1080 displays) and they started running out of VM.

Restarting a browser once a day is not at all burdensome.

> You probably need less than a thousand lines of C to make a reasonably easy
> to maintain and adapt form that could display graphics, video, and text, and
> also pull the data from some kind of service or set of services (weather
> underground or similar, plus perhaps some USB or RS-232 connected local
> weather station).  Assuming a good support library or two of course.

But whatever you come up with will probably be harder to document and
maintain and less adaptable that if you'd just done it in HTML, or some
comparably widely-used standard.

> It's probably half that many lines in Go or Python.

Actually, I recently implemented a web browser in Python to implement a
simple web kiosk (on our lab desktops, not Raspberry Pis).  It consisted
of a button bar with "Back," "Forward," "Reload," and "Quit," and
applied a URL filter to prevent the user from browsing outside the
fences.  The whole thing came in under 270 lines, the most important of
which was "import webkit".  It's not polished, but it does the job
(better, IMHO, than the ancient Opera browser in kiosk mode that I was
replacing).

kweb (1.6) is about 1200 lines of C code, also using webkit.

-- 
Dan Astoorian, Systems Administrator
Engineering Computing Facility
University of Toronto