5 ms·

Dude Winamp was a clean, simple and wickedly responsive UI that allowed a multitude of real-time audio tweaks and supported playlists with thousands of files. T

Dude Winamp was a clean, simple and wickedly responsive UI that allowed a multitude of real-time audio tweaks and supported playlists with thousands of files. This was in the late 90’s running on 166Mhz processors with maybe 16MB of system ram. Are you saying modern car infotainment systems have fewer resources allocated to the UI?

randomdata 3y ago
Are you saying that you want to control a car’s infotainment system with a keyboard and mouse while staring at a CRT monitor?
- uncletaco 3y ago
  Yes, unironically. Give me tactile buttons and a near zero latency screen.
philsnow 3y ago
You’ve just reminded me that I lived in a time when my desktop machine was not powerful enough to decode and play MP3s in real time. I had to decode to wav files and play those. This was in a time when far fewer instructions were accelerated on the cpu, and my cpu at the time was something like a 66MHz 486-dx2, and even the (Frauenhofer) mp3 codec wasn’t as optimized as it was later.
- berkle4455 3y ago
  Gotta use that turbo button bro
Dalewyn 3y ago
>Are you saying modern car infotainment systems have fewer resources allocated to the UI? Relatively speaking: Yes. Response lag is always because the hardware is chugging to process all the bits in time (they're not in time). Between underprovisioned hardware and shittily written software, hell yeah fewer resources are allocated to the UI. We need a small supercomputer's worth of resources allocated to bring the software of today up to snap like it was the 90s.
gjadi 3y ago
I haven't yet worked on automotive stuff but I work in the embedded space. We're using small MCU (not CPU) to drive 480x272 or 800x600 screen. 240Mhz, 8MB of RAM. For example on ESP32-S2 or ESP32-S3. If you had GPS, bluetooth, wifi, etc. to the mix, yeah that's a challenge and you need to make your UI pretty simple.
- londons_explore 3y ago
  Nearly everything automotive now has a GPU. When you have a GPU, even a very low power one, graphics get far easier. simple operations like "fade from this screen into that screen at 60 fps" become easy. They would be impossible with CPU graphics, simply because a slow CPU can't update every pixel on the screen at 60 fps anyway. Despite that, automotive graphics ramain laggy because they normally build something barely gpu accelerated using java or QT or something else laggy by nature...
  - gjadi 3y ago
    Yeah a GPU makes things easier. Note that you can do it with Java, we do it at $work. Anyway, when you're designing your UI, you've to take into account the computation power available and design around that, otherwise you're doomed.
  - jlokier 3y ago
    At the highest resolution of the GP comment, 800×600, and a 240MHz CPU/MCU and 8MB RAM, 60fps smooth updates for things like scrolling, scaling, and drawing new buttons and icons should normally be possible with the CPU alone. Fading and blending large areas of the screen won't be, but small areas will be fine. Basically anything that involves copying pixels or solid fills without per-pixel calculations. 60fps at 800x600 is 28.8Mpixel/s. Copying and filling at that rate should be achievable by a 240MHz CPU with some tight coding. The rest is 2d geometry, mostly axis-aligned, with relatively few edges. That's not demanding at all. (I used to write 2d and 3d rendering engines for slower CPUs than that.) A GPU is necessary for fancier effects like fades and shading, but the basics can be smooth on a CPU and the fancy stuff too if confined to smaller areas. Also, for the car, people would be happy enough if it could do a consistent 30fps I think. Those annoyingly slow GUI updates you tend to see on TV set top boxes are not slow because of the hardware... it's usually the software not being written with sleedy rendering in mind. All that said, you're right that if there's a GPU or even just a Blitter, it should be used and then the CPU speed almost doesn't matter as the geometry calculations are so simple.

randomdata 3y ago

Are you saying that you want to control a car’s infotainment system with a keyboard and mouse while staring at a CRT monitor?

uncletaco 3y ago
Yes, unironically. Give me tactile buttons and a near zero latency screen.

philsnow 3y ago

You’ve just reminded me that I lived in a time when my desktop machine was not powerful enough to decode and play MP3s in real time. I had to decode to wav files and play those. This was in a time when far fewer instructions were accelerated on the cpu, and my cpu at the time was something like a 66MHz 486-dx2, and even the (Frauenhofer) mp3 codec wasn’t as optimized as it was later.

berkle4455 3y ago
Gotta use that turbo button bro

Dalewyn 3y ago

>Are you saying modern car infotainment systems have fewer resources allocated to the UI? Relatively speaking: Yes. Response lag is always because the hardware is chugging to process all the bits in time (they're not in time). Between underprovisioned hardware and shittily written software, hell yeah fewer resources are allocated to the UI. We need a small supercomputer's worth of resources allocated to bring the software of today up to snap like it was the 90s.

gjadi 3y ago

I haven't yet worked on automotive stuff but I work in the embedded space. We're using small MCU (not CPU) to drive 480x272 or 800x600 screen. 240Mhz, 8MB of RAM. For example on ESP32-S2 or ESP32-S3. If you had GPS, bluetooth, wifi, etc. to the mix, yeah that's a challenge and you need to make your UI pretty simple.

londons_explore 3y ago
Nearly everything automotive now has a GPU. When you have a GPU, even a very low power one, graphics get far easier. simple operations like "fade from this screen into that screen at 60 fps" become easy. They would be impossible with CPU graphics, simply because a slow CPU can't update every pixel on the screen at 60 fps anyway. Despite that, automotive graphics ramain laggy because they normally build something barely gpu accelerated using java or QT or something else laggy by nature...
- gjadi 3y ago
  Yeah a GPU makes things easier. Note that you can do it with Java, we do it at $work. Anyway, when you're designing your UI, you've to take into account the computation power available and design around that, otherwise you're doomed.
- jlokier 3y ago
  At the highest resolution of the GP comment, 800×600, and a 240MHz CPU/MCU and 8MB RAM, 60fps smooth updates for things like scrolling, scaling, and drawing new buttons and icons should normally be possible with the CPU alone. Fading and blending large areas of the screen won't be, but small areas will be fine. Basically anything that involves copying pixels or solid fills without per-pixel calculations. 60fps at 800x600 is 28.8Mpixel/s. Copying and filling at that rate should be achievable by a 240MHz CPU with some tight coding. The rest is 2d geometry, mostly axis-aligned, with relatively few edges. That's not demanding at all. (I used to write 2d and 3d rendering engines for slower CPUs than that.) A GPU is necessary for fancier effects like fades and shading, but the basics can be smooth on a CPU and the fancy stuff too if confined to smaller areas. Also, for the car, people would be happy enough if it could do a consistent 30fps I think. Those annoyingly slow GUI updates you tend to see on TV set top boxes are not slow because of the hardware... it's usually the software not being written with sleedy rendering in mind. All that said, you're right that if there's a GPU or even just a Blitter, it should be used and then the CPU speed almost doesn't matter as the geometry calculations are so simple.