3 ms·

No, that isn't allowing exposure to kernel graphics buffers. That's allowing clients to draw to the main framebuffer with no acceleration at all. If you're memo

No, that isn't allowing exposure to kernel graphics buffers. That's allowing clients to draw to the main framebuffer with no acceleration at all. If you're memory mapping pixels into user space and drawing with the CPU then you're necessarily leaving kernel space. Around the same time X11 had an extension called DGA that did the same thing. It was removed because it doesn't work correctly when you have hardware acceleration. So the optimization only makes sense for a machine like yours with no native drivers. With any kind of GPU acceleration it will actually make things much slower. GTK doesn't do this because it would only be useful for that kind of machine running around 25 years ago.

DonHopkins 3y ago
Shared kernel graphics buffers in main or memory mapped framebuffer device memory are one thing (common in the early 80's, i.e. 1982 SunView using /dev/fb), but does it expose modern shared GPU texture buffers to multiple processes, which are a whole other ball game, and orders of magnitude more efficient, by not requiring ping-ponging pixels back and forth between the CPU and GPU when drawing and compositing or crossing process boundaries?
AshamedCaptain 3y ago
> With any kind of GPU acceleration it will actually make things much slower. GTK doesn't do this because it would only be useful for that kind of machine running around 25 years ago. Precisely one of the points of TFA is be able to use the "25 year old" hardware overlay support whenever possible (instead of the GPU) in order to save power, like Android (and classic Xv) does.
- play_ac 3y ago
  1. The hardware overlay support is implemented on the GPU. It's not "instead of the GPU". 2. The provided code in Haiku doesn't appear to support overlays. 3. Yes, it's upsetting that a real API wasn't available for this until recently. But, it was of limited practical use without the entire display pipeline being moved to the GPU and without Wayland being established (X11 never had the API quite like this, classic XV is too limited to do what this is doing)

DonHopkins 3y ago

Shared kernel graphics buffers in main or memory mapped framebuffer device memory are one thing (common in the early 80's, i.e. 1982 SunView using /dev/fb), but does it expose modern shared GPU texture buffers to multiple processes, which are a whole other ball game, and orders of magnitude more efficient, by not requiring ping-ponging pixels back and forth between the CPU and GPU when drawing and compositing or crossing process boundaries?

AshamedCaptain 3y ago

> With any kind of GPU acceleration it will actually make things much slower. GTK doesn't do this because it would only be useful for that kind of machine running around 25 years ago. Precisely one of the points of TFA is be able to use the "25 year old" hardware overlay support whenever possible (instead of the GPU) in order to save power, like Android (and classic Xv) does.

play_ac 3y ago
1. The hardware overlay support is implemented on the GPU. It's not "instead of the GPU". 2. The provided code in Haiku doesn't appear to support overlays. 3. Yes, it's upsetting that a real API wasn't available for this until recently. But, it was of limited practical use without the entire display pipeline being moved to the GPU and without Wayland being established (X11 never had the API quite like this, classic XV is too limited to do what this is doing)