xcb_damage_create(3)

📦
version 1.17.0 · 5 versions
, in alpine 3.22, alpine 3.23, alpine 3.24, arch rolling, centos-stream 10, debian trixie, fedora 43, fedora 44, nixpkgs unstable, opensuse-leap 16.0, ubuntu questing, ubuntu resolute, ubuntu stonking

✨ xcb_damage_create ✨

okay bestie, welcome to the xcb_damage_create(3) page from the XCB Requests corner of the manual 💖 this one's about making a Damage object so you can stalk 👀 a drawable and get told every time its pixels change. lowkey iconic behaviour fr fr.

🌸 NAME 🌸

xcb_damage_create — creates a Damage object to monitor changes to a drawable.

like, it's giving surveillance but make it pixel-perfect 💅

🎀 SYNOPSIS 🎀

#include <xcb/damage.h>

Request function

xcb_void_cookie_t xcb_damage_create(xcb_connection_t *conn,
       xcb_damage_damage_t damage, xcb_drawable_t drawable,
       uint8_t level);

🦋 REQUEST ARGUMENTS 🦋

  • conn — the XCB connection to X11. your lil hotline to the server 📞
  • damage — the ID you'll use to refer to the new Damage object, and you get it from xcb_generate_id. yes bestie, you have to make the ID yourself, it's not just handed to you ✨
  • drawable — the ID of the drawable that's getting monitored. the main character of this whole operation 👑
  • level — the level of detail to be provided in Damage events. how much tea do you want spilled, basically 🍵

💜 DESCRIPTION 💜

So this creates a Damage object that monitors changes to a drawable, and it specifies the level of detail to be reported for changes. that's the whole vibe check right there.

Throughout this extension, we call the changes made to the pixel contents of windows and pixmaps 'damage'. periodt. that's the terminology, no notes 🫶

Damage accumulates as drawing happens in the drawable. Each drawing operation is guaranteed to include the set of pixels modified by that operation, but — and this is the important bit, no cap — it may include significantly more than just those pixels. The desire is for the damage to strike a balance between the number of rectangles reported and the extraneous area included. A reasonable goal is for each primitive object drawn (line, string, rectangle) to be represented as a single rectangle, and for the damage area of the operation to be the union of these rectangles. cute, right? very tidy of it 🌈

The DAMAGE extension lets applications do one of two things:

  1. receive the raw rectangles as a stream of events, or
  2. have them partially processed within the X server, which reduces the amount of data transmitted and reduces the processing latency once the repaint operation has started.

both are valid, pick your fighter 💅

The Damage object holds any accumulated damage region, and it reflects the relationship between the drawable selected for damage notification and the drawable for which damage is tracked. it's keeping receipts on both sides, honestly 💀

⭐ RETURN VALUE ⭐

It returns an xcb_void_cookie_t. Any errors (if there are any) have to be handled in the event loop, bestie — that's just how void cookies roll.

If you want to handle errors directly with xcb_request_check instead, use xcb_damage_create_checked. See xcb-requests(3) for details. 🙈

💀 ERRORS 💀

This request does never generate any errors.

not one. zero. none. it's a good egg 🥚✨

🌟 SEE ALSO 🌟

👑 AUTHOR 👑

Generated from damage.xml. Contact xcb@lists.freedesktop.org for corrections and improvements.

ngl if you find a typo, tell the list, they're genuinely so nice about it 💌

okay that's the whole page!! hope it slayed for you 💖 mwah!! and just so you know where this lore came from: this is X Version 11, libxcb 1.17.0, page xcb_damage_create(3) — stay hydrated and go monitor some drawables, bestie 🧚‍♀️🌸🦋

📦 where this page comes from