diff --git a/content/blog/drawing-simple-cubes/index.md b/content/blog/drawing-simple-cubes/index.md index a1c8c0a..f66b8b4 100644 --- a/content/blog/drawing-simple-cubes/index.md +++ b/content/blog/drawing-simple-cubes/index.md @@ -1,7 +1,7 @@ --- -title: "Graphics Dump: Drawing debug cubes" +title: "Graphics Dump: Improving debug cubes" date: 2023-07-03 -draft: true +draft: false summary: "When working on my engine, I wanted to clean up my debug gizmos a bit. The first thing to tackle is drawing bounding boxes!" tags: - Math @@ -61,13 +61,13 @@ void main() { } ``` -Let's break this down, first we can simplify the many equality checks in the beginning with notEqual: +Let's break this down, first we can simplify the many equality checks in the beginning with [notEqual](https://docs.gl/sl4/notEqual): ```glsl notEqual(abs(inPosition), vec3(1.0)) ``` -This is component-wise, so it has the same exact meaning as before. We want to perform a length check on this, hence the `vec3` cast. Why do we do a length cast? It's the easiest way to detect how many booleans are true, I'm not sure of a better way. For example: +This is component-wise, so it has the same exact meaning as before. We want to call [length](https://docs.gl/sl4/length) on this, hence the `vec3` cast. Why do we do a length cast? It's the easiest way to detect how many booleans are true, I'm not sure of a better way. For example: * `(1, 0, 0)` has a length of 1. * `(1, 1, 0)` has a length of $\sqrt{2}$. diff --git a/content/blog/wayland-ssd/index.md b/content/blog/wayland-ssd/index.md new file mode 100644 index 0000000..03d1e46 --- /dev/null +++ b/content/blog/wayland-ssd/index.md @@ -0,0 +1,51 @@ +--- +title: "How to use xdg-decoration in a Wayland client" +date: 2023-07-03 +draft: false +tags: +- Wayland +--- + +I wanted to enable server-side decorations in a Wayland client, but didn't know where to start. When searching for _"How to enable server-side decorations wayland"_ in a search engine you get a lot of user support questions and not really anything for programmers. Here's a short tutorial on how to request server side decorations from the compositor if supported. + +# Which protocol to use? + +When searching for the Wayland protocol to use, you'll come across two different ones: +* [kde-server-decoration](https://wayland.app/protocols/kde-server-decoration) +* [xdg-decoration](https://wayland.app/protocols/xdg-decoration-unstable-v1) + +What is the difference between the two? From what I can tell the first extension was by KDE and put into their protocol collection. It doesn't appear to be used anymore, and not even installed on my system. xdg-decoration is actually in wayland-protocols (albeit unstable) so we'll use that one. + +If you're using ECM ([Extra CMake Modules](https://invent.kde.org/frameworks/extra-cmake-modules)) then use `ecm_add_wayland_client_protocol` to generate the header: + +```cmake +ecm_add_wayland_client_protocol( + WAYLAND_SOURCES + BASENAME + xdg-decoration-v1 + PROTOCOL + ${WaylandProtocols_DATADIR}/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml +) +``` + +# How to use xdg-decoration + +When enumerating the global registry, bind the `zxdg_decoration_manager_v1` struct using the `zxdg_decoration_manager_v1_interface` interface: + +```cpp +auto manager = reinterpret_cast(wl_registry_bind(registry, id, &zxdg_decoration_manager_v1_interface, 1)); +``` + +Using the decoration manager, you want to [set the "mode"](https://wayland.app/protocols/xdg-decoration-unstable-v1#zxdg_toplevel_decoration_v1:request:set_mode) of the decoration to either client side or server side: + +```cpp +auto decoration = zxdg_decoration_manager_v1_get_toplevel_decoration(manager, toplevel); // toplevel is from xdg_surface_get_toplevel + +zxdg_toplevel_decoration_v1_set_mode(decoration, ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE); +``` + +And that's it, you'll get server-side decorations enabled for your client: + +![Window decorations!](wayland.webp) + +There's one more part of the extension I didn't cover, and that's the ["configure" event](https://wayland.app/protocols/xdg-decoration-unstable-v1#zxdg_toplevel_decoration_v1:event:configure). According to the protocol spec, it's possible that the compositor will change the decoration mode from underneath your feet. Is this something that actually happens in real world Wayland compositors? I can't imagine this happens often, although I'm curious if you've heard of this. diff --git a/content/blog/wayland-ssd/wayland.webp b/content/blog/wayland-ssd/wayland.webp new file mode 100644 index 0000000..09eb2d7 Binary files /dev/null and b/content/blog/wayland-ssd/wayland.webp differ diff --git a/themes/red/layouts/_default/single.html b/themes/red/layouts/_default/single.html index af7a566..5d865b2 100644 --- a/themes/red/layouts/_default/single.html +++ b/themes/red/layouts/_default/single.html @@ -31,4 +31,43 @@ {{ partial "comments" . }} {{ end }} + + {{ if .Params.threejs }} + {{ $imagesloaded := resources.Get "js/three.js" }} + {{ if hugo.IsProduction }} + {{ $imagesloaded = $imagesloaded | minify | fingerprint | resources.PostProcess }} + {{ end }} + + {{ end }} + + {{ if .Params.math }} + {{ $math := resources.Get "js/katex.js" }} + {{ if hugo.IsProduction }} + {{ $math = $math | minify | fingerprint | resources.PostProcess }} + {{ end }} + + + {{ $autorender := resources.Get "js/auto-render.js" }} + {{ if hugo.IsProduction }} + {{ $autorender = $autorender | minify | fingerprint | resources.PostProcess }} + {{ end }} + + + {{ $style := resources.Get "css/katex.css" }} + {{ if hugo.IsProduction }} + {{ $style = $style | minify | fingerprint | resources.PostProcess }} + {{ end }} + + + + {{ end }} {{ end }}