5 ms·

>Haiku is ideal for embedded graphical systems Well, except there's no accelerated graphics driver (for any device) :(

dleslie 5y ago
For the apps it has this doesn't seem to matter; not everything needs pixel shaders to be performant.
swiley 5y ago
IME: hardware accelerated UI toolkits are very slow on all but the largest/newest computers. Rendering a GUI can be done in real time on ancient CPUs. This has been true since the 1980s and continues to be true today. If your app has a performance issue then you should consider cutting down on the animations/special effects/abstractions.
- zozbot234 5y ago
  > Rendering a GUI can be done in real time on ancient CPUs. That depends on the style of GUI. As soon as you introduce any amount of animation (even something as trivial as drag-and-drop, never mind touch-swipe or touch-zoom gestures), hardware acceleration can be quite useful.
  - swiley 5y ago
    It's certainly useful but it tends to break and in the context of embedded: constrain hardware choices to vendors known to have serious support problems. CPUs are more than capable of rendering graphics needed for gestures like you mentioned.
  - colejohnson66 5y ago
    > As soon as you introduce any amount of animation (even something as trivial as drag-and-drop, never mind touch-swipe or touch-zoom gestures), hardware acceleration can be quite useful. Didn’t Windows XP (and prior) not render the window as it was dragged, but just a dashed box? And when you release the window, it’d be redrawn in the new spot.
    - caslon 5y ago
      XP rendered the window unless you had a few settings switched (or the classic theme on).
      - unilynx 5y ago
        In fact, dragging a window in XP was the quickest way to see if hardware acceleration was properly enabled. If you saw the window tearing while being dragged, chances were installing an extra driver would make the user a lot happier.
    - deleted 5y ago
      [deleted]
    - deathanatos 5y ago
      I believe Windows 95 had only that behavior… but everything after it could render in real time. In Windows 98, it's under the Control Panel → Display → Effects → Show window contents while dragging https://copy.sh/v86/?profile=windows98 https://copy.sh/v86/?profile=windows98 (The VM here is slower than a machine of the era.) (I also want to say Transport Tycoon Deluxe's windows were draggable without needing a frame / in real time, and that was in DOS?)
  - slackfan 5y ago
    Haiku does some amazingly impressive things software-only, drag & drop and scroll really don't need hardware acceleration. If they do, there's a problem with your code. Mind you, I can do real-time 1080p mp4 video scrubbing on haiku running on a thin client so...
    - swiley 5y ago
      I was thinking about it and the issue is really the "if there's no compatible hardware llvmpipe will just take care of it" attitude. If you watch these software rendered graphics carefully (or read the code) they make trade-offs that allow everything to work with low input latency and render in real time and sometimes that means "corrupt" looking graphics on the screen which the OpenGL style graphics won't generate (the frame is either done or it gets skipped.)
  - rjsw 5y ago
    The Macintosh did drag-and-drop with no hardware acceleration in 1984.
- livre 5y ago
  >IME: hardware accelerated UI toolkits are very slow on all but the largest/newest computers. This has been my experience too with an old GMA GPU, I have to keep disabling hardware acceleration in everything I try to run (browsers, electron apps if possible, desktop environments). The UI runs order of magnitude faster on the CPU than on the GPU through OpenGL.
  - garaetjjte 5y ago
    I don't think these anachronistic comparisons make any sense. GMA might do OGL2.1 at best, it won't work well with software with modern assumptions. I wouldn't be surprised if it doesn't use GPU at all and falls back to software OGL renderer.
    - livre 5y ago
      It tries to do hardware rendering, I had to force software rendering due to artifacts and messed up colors in addition to slow rendering.
- aspaceman 5y ago
  You should look at GUI via ImGUI if this is an opinion you hold. Immediate mode GUI creation. Very straightforward and just requires an OpenGL context (which can be software of course, so all CPU based if you want). A lot of games use it because it can be easily added as an additional layer to your final image (and is represented as just an image).
  - swiley 5y ago
    Sure and ImGUIs are extremely unpleasant to use in power/resource constrained environments. You should look at GTK+, motif, or TCL/Tk. They're very straightforward and don't turn people's devices into hand warmers.
    - garaetjjte 5y ago
      GTK in resource constrained environment? Uh... Motif, along with X11 is just completely obsolete platform. (btw, this is what UHH thinks about it: "What Motif does is make Unix slow. Real slow.") There's some weird GPU hate in this thread that I don't quite understand. Try to render dragging content of 1080p window at 60fps on cheap mobile ARM core, and you will likely blow your whole time budget just on filling the window with solid color...
      - dleslie 5y ago
        Like on the PinePhone, using sxmo? Works great. Ditching the _enormous_ Android stack is an easy win.
        pjmlp 5y ago
        That was Brillo's main goal, except when it came to production it got rebooted as Android Things and now is dead.
    - aspaceman 5y ago
      Is this because they tend to heat up when you use a GL context? And the UI toolkits composite to the screen less often? I'm not a mobile developer so this is all new to me. Thanks for the info.
yellowapple 5y ago
I ain't sure if that's strictly necessary for that use case, given how snappy I've found Haiku to be even with limited resources. It'd probably be nice, but having seen plenty of embedded graphics, I'd hardly call them "accelerated" anyway.

For the apps it has this doesn't seem to matter; not everything needs pixel shaders to be performant.

IME: hardware accelerated UI toolkits are very slow on all but the largest/newest computers. Rendering a GUI can be done in real time on ancient CPUs. This has been true since the 1980s and continues to be true today. If your app has a performance issue then you should consider cutting down on the animations/special effects/abstractions.

zozbot234 5y ago
> Rendering a GUI can be done in real time on ancient CPUs. That depends on the style of GUI. As soon as you introduce any amount of animation (even something as trivial as drag-and-drop, never mind touch-swipe or touch-zoom gestures), hardware acceleration can be quite useful.
- swiley 5y ago
  It's certainly useful but it tends to break and in the context of embedded: constrain hardware choices to vendors known to have serious support problems. CPUs are more than capable of rendering graphics needed for gestures like you mentioned.
- colejohnson66 5y ago
  > As soon as you introduce any amount of animation (even something as trivial as drag-and-drop, never mind touch-swipe or touch-zoom gestures), hardware acceleration can be quite useful. Didn’t Windows XP (and prior) not render the window as it was dragged, but just a dashed box? And when you release the window, it’d be redrawn in the new spot.
  - caslon 5y ago
    XP rendered the window unless you had a few settings switched (or the classic theme on).
    - unilynx 5y ago
      In fact, dragging a window in XP was the quickest way to see if hardware acceleration was properly enabled. If you saw the window tearing while being dragged, chances were installing an extra driver would make the user a lot happier.
  - deleted 5y ago
    [deleted]
  - deathanatos 5y ago
    I believe Windows 95 had only that behavior… but everything after it could render in real time. In Windows 98, it's under the Control Panel → Display → Effects → Show window contents while dragging https://copy.sh/v86/?profile=windows98 https://copy.sh/v86/?profile=windows98 (The VM here is slower than a machine of the era.) (I also want to say Transport Tycoon Deluxe's windows were draggable without needing a frame / in real time, and that was in DOS?)
- slackfan 5y ago
  Haiku does some amazingly impressive things software-only, drag & drop and scroll really don't need hardware acceleration. If they do, there's a problem with your code. Mind you, I can do real-time 1080p mp4 video scrubbing on haiku running on a thin client so...
  - swiley 5y ago
    I was thinking about it and the issue is really the "if there's no compatible hardware llvmpipe will just take care of it" attitude. If you watch these software rendered graphics carefully (or read the code) they make trade-offs that allow everything to work with low input latency and render in real time and sometimes that means "corrupt" looking graphics on the screen which the OpenGL style graphics won't generate (the frame is either done or it gets skipped.)
- rjsw 5y ago
  The Macintosh did drag-and-drop with no hardware acceleration in 1984.
livre 5y ago
>IME: hardware accelerated UI toolkits are very slow on all but the largest/newest computers. This has been my experience too with an old GMA GPU, I have to keep disabling hardware acceleration in everything I try to run (browsers, electron apps if possible, desktop environments). The UI runs order of magnitude faster on the CPU than on the GPU through OpenGL.
- garaetjjte 5y ago
  I don't think these anachronistic comparisons make any sense. GMA might do OGL2.1 at best, it won't work well with software with modern assumptions. I wouldn't be surprised if it doesn't use GPU at all and falls back to software OGL renderer.
  - livre 5y ago
    It tries to do hardware rendering, I had to force software rendering due to artifacts and messed up colors in addition to slow rendering.
aspaceman 5y ago
You should look at GUI via ImGUI if this is an opinion you hold. Immediate mode GUI creation. Very straightforward and just requires an OpenGL context (which can be software of course, so all CPU based if you want). A lot of games use it because it can be easily added as an additional layer to your final image (and is represented as just an image).
- swiley 5y ago
  Sure and ImGUIs are extremely unpleasant to use in power/resource constrained environments. You should look at GTK+, motif, or TCL/Tk. They're very straightforward and don't turn people's devices into hand warmers.
  - garaetjjte 5y ago
    GTK in resource constrained environment? Uh... Motif, along with X11 is just completely obsolete platform. (btw, this is what UHH thinks about it: "What Motif does is make Unix slow. Real slow.") There's some weird GPU hate in this thread that I don't quite understand. Try to render dragging content of 1080p window at 60fps on cheap mobile ARM core, and you will likely blow your whole time budget just on filling the window with solid color...
    - dleslie 5y ago
      Like on the PinePhone, using sxmo? Works great. Ditching the _enormous_ Android stack is an easy win.
      - pjmlp 5y ago
        That was Brillo's main goal, except when it came to production it got rebooted as Android Things and now is dead.
  - aspaceman 5y ago
    Is this because they tend to heat up when you use a GL context? And the UI toolkits composite to the screen less often? I'm not a mobile developer so this is all new to me. Thanks for the info.

yellowapple 5y ago

I ain't sure if that's strictly necessary for that use case, given how snappy I've found Haiku to be even with limited resources. It'd probably be nice, but having seen plenty of embedded graphics, I'd hardly call them "accelerated" anyway.