3 ms·

> Once I had the design [of the enclosure], I tried to 3D print it on my brand new 3D printer, which turned out to be a disaster. Took me some time to learn mor

> Once I had the design [of the enclosure], I tried to 3D print it on my brand new 3D printer, which turned out to be a disaster. Took me some time to learn more about designing for manufacturing, especially for 3D printing. Would have been nice to hear how specifically it was made to work in the end. > Turns out, cross-fading two 4MP images at 60 frames per second on a moderately powerful single board computer is not so easy. Yeah, at first it feels stupid that every pretty LCD screen for bus or train stops, ads or whatnot has a full computer behind it, but then you ballpark the memory bandwidth and realize you need a ~ 1 GHz device anyway just to be able to chew through the pixels fast enough. (1920² px × 24 bpp × 60 Hz = 620 MB/s.) You also realize why “fill rate” used to be such a buzzword 20 years ago and why it took a while until true color became ubiquitous. On the flip side of the O(n²), you can easily drive a watch-sized display with pretty good ppi using a 32-bit MCU, which is why the Apple/Google/Samsung battery-guzzling approach to smartwatches seems wrongheaded to me compared to Pebble/Zepp/etc.

markb139 3mo ago
Way back in time (1980s) I worked in the broadcast tv industry. We used to used digital still stores. A single frame of PAL took up 1MB of RAM. The machines had 2MB fitted. The board had a hardware cross fade function implemented in discrete logic chips. They also had a 20 or 40MB scsi drive. It was all controlled by a 6809 cpu. Quite impressive for the time
skippyfish 3mo ago
Large displays are not driven by a general-purpose CPU that bit-bangs a single serial data line, and never were. They're driven by separate circuitry with direct memory access, often integrated on the die of chips meant for these applications. The actual bus to the display controller may be a parallel dot-clock RGB bus, or an ultra-speed differential multi-lane serial (MIPI DSI, HDMI, etc). And train stop displays certainly don't need 60 fps. The main constraint for high-resolution displays is memory, not CPU clock speed. Your (odd) 1920x1920x24bpp frame buffer takes up more than 10 MB.
- Aurornis 3mo ago
  > They're driven by separate circuitry with direct memory access, often integrated on the die of chips meant for these applications In embedded SoCs the memory bandwidth is often shared between the CPU and the GPU. There is not a separate pool of memory and bandwidth for the GPU. > The actual bus to the display controller may be a parallel dot-clock RGB bus, or an ultra-speed differential multi-lane serial (MIPI DSI, HDMI, etc). That’s not what the parent comment is talking about. To get the data into the framebuffer you need to write it first. You also need to read the source images. For blending two images and writing the output, the floor is 3X the total image size every single frame. (Two reads, one write). There are tricks that can be played with frame buffers and scan out blending, but you get the idea. > And train stop displays certainly don't need 60 fps. We’re talking about the product in the link, which is trying to blend seamlessly between two images at 60fps. > The main constraint for high-resolution displays is memory, not CPU clock speed. I don’t think you understood the problem space. If you’re doing software blending of 10MB image buffers at 60fps, the CPU can be easily be a bottleneck. You have to ensure the CPU can do enough load operations, math on the loaded data, and store operations to get it done in 16.7ms. Ideally you have a GPU, but if you don’t then you need to pay close attention to optimizations and special instructions to get it done within the frame budget and also allow some cycles for all of the other work the app has to do. > Your (odd) 1920x1920x24bpp frame buffer takes up more than 10 MB. The 1920x1920 size came from the article. Parent commenter wasn’t making up odd sizes, they were responding to the article.
atoav 3mo ago
As a mediatec guy I think the idea that everything needs to be 60 fps is a pest. I understand the idea in gaming, but it is not needed elsewhere. A train stop display can easily do its job at 1 fps or lower. You do not need to display motion at all and the 1 fps you need mostly for blinking things off and on (if there is no dedicated circuit for it). Most cinema films I watched projected from analog film looked perfect at 24 fps. Heck some anime loocks better at 5 or 10fps than it would look if the motion was fluid at 120 fps. Why would a display at a train stop need double the frame rate of a cinema classic that still looks completely convincing? Because some gamers decided they can't play below 60 fps?
- trashb 3mo ago
  > 60 fps is a pest I agree. Even for gaming just the fps is misinformed. It doesn't account for latency and is kind of a arbitrary limit that became industry standard. Consider a 60fps or 144fps stream can still be out of sync for example you might have experienced watching the same video stream on two different devices and one is more ahead compared to the other while both are the same framerate (one having higher latency from the source). 24fps is good for most real video, animations even dial back to way less animating on 4s, 3s or 2s is common practice. However while gaming you may want higher fps (usually corresponds to lower latency) to allow you to respond in a timely fashion mostly because our brains are quite slow. For embedded applications even if there is movement it should never ever need a 60fps source.
- rcxdude 3mo ago
  >Most cinema films I watched projected from analog film looked perfect at 24 fps Until you get a panning shot and then it looks very juddery. Filmmakers have gotten quite good at dealing with the limitation but it is a limitation. (That said, you do have a challenge with higher fidelity video because it makes it harder to hide the imperfections in what the video is capturing, which makes things tend to look more fake) Anime (and most animation) can adjust the framerate for what makes sense for the shot or even the element. It's common, for example, that panning happens on ones while the animation happens on twos or threes, because low-framerate panning looks bad and it's relatively easy with cell shading to animate the pan at a higher framerate. And again, the animators use a ton of techniques to deal with the low framerate and avoid the situations where it looks bad. Which could also apply to train stop displays, if the graphics were designed for it (and almost certainly a consistent 24fps will look better than an inconsistent ~50-60fps).

markb139 3mo ago

Way back in time (1980s) I worked in the broadcast tv industry. We used to used digital still stores. A single frame of PAL took up 1MB of RAM. The machines had 2MB fitted. The board had a hardware cross fade function implemented in discrete logic chips. They also had a 20 or 40MB scsi drive. It was all controlled by a 6809 cpu. Quite impressive for the time

skippyfish 3mo ago

Large displays are not driven by a general-purpose CPU that bit-bangs a single serial data line, and never were. They're driven by separate circuitry with direct memory access, often integrated on the die of chips meant for these applications. The actual bus to the display controller may be a parallel dot-clock RGB bus, or an ultra-speed differential multi-lane serial (MIPI DSI, HDMI, etc). And train stop displays certainly don't need 60 fps. The main constraint for high-resolution displays is memory, not CPU clock speed. Your (odd) 1920x1920x24bpp frame buffer takes up more than 10 MB.

Aurornis 3mo ago
> They're driven by separate circuitry with direct memory access, often integrated on the die of chips meant for these applications In embedded SoCs the memory bandwidth is often shared between the CPU and the GPU. There is not a separate pool of memory and bandwidth for the GPU. > The actual bus to the display controller may be a parallel dot-clock RGB bus, or an ultra-speed differential multi-lane serial (MIPI DSI, HDMI, etc). That’s not what the parent comment is talking about. To get the data into the framebuffer you need to write it first. You also need to read the source images. For blending two images and writing the output, the floor is 3X the total image size every single frame. (Two reads, one write). There are tricks that can be played with frame buffers and scan out blending, but you get the idea. > And train stop displays certainly don't need 60 fps. We’re talking about the product in the link, which is trying to blend seamlessly between two images at 60fps. > The main constraint for high-resolution displays is memory, not CPU clock speed. I don’t think you understood the problem space. If you’re doing software blending of 10MB image buffers at 60fps, the CPU can be easily be a bottleneck. You have to ensure the CPU can do enough load operations, math on the loaded data, and store operations to get it done in 16.7ms. Ideally you have a GPU, but if you don’t then you need to pay close attention to optimizations and special instructions to get it done within the frame budget and also allow some cycles for all of the other work the app has to do. > Your (odd) 1920x1920x24bpp frame buffer takes up more than 10 MB. The 1920x1920 size came from the article. Parent commenter wasn’t making up odd sizes, they were responding to the article.

atoav 3mo ago

As a mediatec guy I think the idea that everything needs to be 60 fps is a pest. I understand the idea in gaming, but it is not needed elsewhere. A train stop display can easily do its job at 1 fps or lower. You do not need to display motion at all and the 1 fps you need mostly for blinking things off and on (if there is no dedicated circuit for it). Most cinema films I watched projected from analog film looked perfect at 24 fps. Heck some anime loocks better at 5 or 10fps than it would look if the motion was fluid at 120 fps. Why would a display at a train stop need double the frame rate of a cinema classic that still looks completely convincing? Because some gamers decided they can't play below 60 fps?

trashb 3mo ago
> 60 fps is a pest I agree. Even for gaming just the fps is misinformed. It doesn't account for latency and is kind of a arbitrary limit that became industry standard. Consider a 60fps or 144fps stream can still be out of sync for example you might have experienced watching the same video stream on two different devices and one is more ahead compared to the other while both are the same framerate (one having higher latency from the source). 24fps is good for most real video, animations even dial back to way less animating on 4s, 3s or 2s is common practice. However while gaming you may want higher fps (usually corresponds to lower latency) to allow you to respond in a timely fashion mostly because our brains are quite slow. For embedded applications even if there is movement it should never ever need a 60fps source.
rcxdude 3mo ago
>Most cinema films I watched projected from analog film looked perfect at 24 fps Until you get a panning shot and then it looks very juddery. Filmmakers have gotten quite good at dealing with the limitation but it is a limitation. (That said, you do have a challenge with higher fidelity video because it makes it harder to hide the imperfections in what the video is capturing, which makes things tend to look more fake) Anime (and most animation) can adjust the framerate for what makes sense for the shot or even the element. It's common, for example, that panning happens on ones while the animation happens on twos or threes, because low-framerate panning looks bad and it's relatively easy with cell shading to animate the pan at a higher framerate. And again, the animators use a ton of techniques to deal with the low framerate and avoid the situations where it looks bad. Which could also apply to train stop displays, if the graphics were designed for it (and almost certainly a consistent 24fps will look better than an inconsistent ~50-60fps).