6 ms·

> Happy to answer questions about Wayland if anyone has some! OK then! Hopefully this isn't too off topic. How should I write an application that does smooth

> Happy to answer questions about Wayland if anyone has some! OK then! Hopefully this isn't too off topic. How should I write an application that does smooth animation in Wayland? I'd like to have a main loop like this: while (1) { DrawStuffIntoAPrivateBitmap(); GiveBitmapToTheCompositor(); WaitUntilNextFrameNeeded(); // This loop should iterate at 60 Hz or whatever the monitor's frame rate is. } Does that seem like a reasonable approach? I've searched for this info before and got nowhere. Does Wayland even have a mechanism to allow the compositor to tell the application that it is time to draw another frame? If I give the compositor a bitmap every 60th of a second, to I get any guarantee it will display it at the right time? An application I have in mind is smooth scrolling in a text editor. I have a mild preference for doing the private bitmap update on the CPU rather than the graphics card for various reasons.

Sir_Cmpwn 8y ago
>Does Wayland even have a mechanism to allow the compositor to tell the application that it is time to draw another frame? Yes, Wayland will tell you when it's time for another frame. >If I give the compositor a bitmap every 60th of a second, to I get any guarantee it will display it at the right time? Basically you should wait for the compositor to tell you when it's time to draw the next frame, diff it from the time you drew the last frame, and smoothly animate over the difference. If you don't want to draw on the GPU, what you can do is allocate a pixel buffer with wl_shm (shared memory). Then the compositor will read from this and presumably upload it to the GPU (with wlroots the GPU is always used, but you can probably convince it to use blitting instead with a custom renderer). Check out my intro to writing Wayland clients article: https://drewdevault.com/2017/06/10/Introduction-to-Wayland.html https://drewdevault.com/2017/06/10/Introduction-to-Wayland.h... A friend of mine (and core contributor to wlroots) has written a dead-simple example client you can check out as well: https://github.com/emersion/hello-wayland https://github.com/emersion/hello-wayland
- bitwize 8y ago
  That said, it's 2018 and you should be using the GPU for all rendering. The only compositor I know of that actually works without one is plain old Weston, so it's not like falling back to CPU-munged bitmaps is some sort of compatibility mode. If you want to do pixel-level operations on your output framebuffer, write a fragment shader.
  - emersion 8y ago
    Sometimes there are tasks that are not really suited for the GPU. For instance, drawing text is much easier to do on the CPU. Also for clients that only draw a few frames occasionally (status bars, background images) drawing on the CPU is totally fine.
  - abainbridge 8y ago
    Yeah, that's a thing I should learn to do. When I last tried, about 10 years ago, the OpenGL drivers on my then Windows system used to decide to make my app take 20 seconds to start every now and again. The OpenGL init function would just block for that long. That was a show stopper for me. Also, my machine uses the graphics hardware embedded in the processor. That shares system DRAM. The DRAM bandwidth is already the bottleneck with my CPU routines, so it's not clear how much performance benefit the GPU would offer (although there could be power savings, I guess). But basically, my CPU based rendering code is already fast enough and I'm pretty sure it's simpler than getting the GPU involved and easier to debug and more portable (to, say, an Amiga 1200). Therefore I consider writing a fragment shader to be a form of premature optimization. I realize this makes me a mad man :-)
- abainbridge 8y ago
  Nice answer. Thanks. The example app looks like a great starting point.
  - emersion 8y ago
    In case you haven't found it yet, the "please draw a frame" event you get from the compositor is wl_surface.frame: https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_surface-request-frame https://wayland.freedesktop.org/docs/html/apa.html#protocol-...
- sevensor 8y ago
  So, since we're asking about clients -- do you have any recommendation for terminal emulators that are actual Wayland clients rather than X clients? Last I checked even vte-based terminal emulators were still running under XWayland.
  - Sir_Cmpwn 8y ago
    Not really, personally I use urxvt. I might switch to alacritty once it gets a little better. A friend uses termite, another uses gnome-terminal, but I don't like either.

Sir_Cmpwn 8y ago

>Does Wayland even have a mechanism to allow the compositor to tell the application that it is time to draw another frame? Yes, Wayland will tell you when it's time for another frame. >If I give the compositor a bitmap every 60th of a second, to I get any guarantee it will display it at the right time? Basically you should wait for the compositor to tell you when it's time to draw the next frame, diff it from the time you drew the last frame, and smoothly animate over the difference. If you don't want to draw on the GPU, what you can do is allocate a pixel buffer with wl_shm (shared memory). Then the compositor will read from this and presumably upload it to the GPU (with wlroots the GPU is always used, but you can probably convince it to use blitting instead with a custom renderer). Check out my intro to writing Wayland clients article: https://drewdevault.com/2017/06/10/Introduction-to-Wayland.html https://drewdevault.com/2017/06/10/Introduction-to-Wayland.h... A friend of mine (and core contributor to wlroots) has written a dead-simple example client you can check out as well: https://github.com/emersion/hello-wayland https://github.com/emersion/hello-wayland

bitwize 8y ago
That said, it's 2018 and you should be using the GPU for all rendering. The only compositor I know of that actually works without one is plain old Weston, so it's not like falling back to CPU-munged bitmaps is some sort of compatibility mode. If you want to do pixel-level operations on your output framebuffer, write a fragment shader.
- emersion 8y ago
  Sometimes there are tasks that are not really suited for the GPU. For instance, drawing text is much easier to do on the CPU. Also for clients that only draw a few frames occasionally (status bars, background images) drawing on the CPU is totally fine.
- abainbridge 8y ago
  Yeah, that's a thing I should learn to do. When I last tried, about 10 years ago, the OpenGL drivers on my then Windows system used to decide to make my app take 20 seconds to start every now and again. The OpenGL init function would just block for that long. That was a show stopper for me. Also, my machine uses the graphics hardware embedded in the processor. That shares system DRAM. The DRAM bandwidth is already the bottleneck with my CPU routines, so it's not clear how much performance benefit the GPU would offer (although there could be power savings, I guess). But basically, my CPU based rendering code is already fast enough and I'm pretty sure it's simpler than getting the GPU involved and easier to debug and more portable (to, say, an Amiga 1200). Therefore I consider writing a fragment shader to be a form of premature optimization. I realize this makes me a mad man :-)
abainbridge 8y ago
Nice answer. Thanks. The example app looks like a great starting point.
- emersion 8y ago
  In case you haven't found it yet, the "please draw a frame" event you get from the compositor is wl_surface.frame: https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_surface-request-frame https://wayland.freedesktop.org/docs/html/apa.html#protocol-...
sevensor 8y ago
So, since we're asking about clients -- do you have any recommendation for terminal emulators that are actual Wayland clients rather than X clients? Last I checked even vte-based terminal emulators were still running under XWayland.
- Sir_Cmpwn 8y ago
  Not really, personally I use urxvt. I might switch to alacritty once it gets a little better. A friend uses termite, another uses gnome-terminal, but I don't like either.