A toolkit for implementing and reviewing software rendering operations using the pixman library.
Install
mkdir -p .claude/skills/pixman && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/10108" && unzip -o skill.zip -d .claude/skills/pixman && rm skill.zipInstalls to .claude/skills/pixman
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Use this skill when working on pixman broadly: image creation, compositing operators, regions, transforms, trapezoids, glyphs, gradients, clipping, damage tracking, pixel formats, endianness, software rasterization, and raw buffer integration. Best for full pixman implementation and code review, with wlframe-specific integration as a secondary concern.Key capabilities
- →Create pixman images
- →Implement compositing operators
- →Manage regions and clipping
- →Audit raw memory access
- →Handle pixel formats
How it works
It manages pixman integration, focusing on correct pixel semantics, buffer lifetime, and compositing operations.
Inputs & outputs
When to use pixman
- →Create and configure a pixman image
- →Implement a new compositing operator
- →Audit raw memory access in a software renderer
About this skill
Pixman Rasterization Skill
Apply this skill whenever a task involves pixman concepts, even if the current wlframe codebase does not yet use that pixman feature set.
Primary Goal
Produce pixman integration code that is correct about pixel formats, data access windows, and buffer ownership:
- Format mapping stays consistent with the chosen external pixel format model and endianness.
pixman_image_tlifetime follows the backing buffer lifetime.- Buffer listeners are linked and unlinked exactly once.
- Software rendering code remains explicit about raw memory access.
- Pixman operations, regions, transforms, and clipping are treated as semantics-sensitive rendering logic, not mere helper calls.
Use This Skill To
- Implement or review pixman image creation, compositing, clipping, transforms, source patterns, gradients, glyph rendering, and region math.
- Audit software render buffers, stride/pixel layout assumptions, and raw data access windows.
- Review pixman image creation, destroy, and listener hookup.
- Validate external pixel format to pixman format conversions when pixman is used as a display or rendering backend.
- Extend wlframe to more advanced pixman usage without losing correctness in buffer lifetime or pixel semantics.
Domain Coverage
This skill should be treated as broad pixman guidance, including:
pixman_image_tcreation and ownership.- Format codes, alpha handling, premultiplication assumptions, and endianness.
- Compositing operators, source/mask/destination semantics, and clipping.
- Regions, boxes, damage tracking, and incremental redraw logic.
- Transforms, scaling, filtering, repeated sources, solid fills, gradients, trapezoids, and glyph paths.
- Raw memory-backed images, stride calculation, alignment, and external buffer lifetime.
- Performance-sensitive software rendering tradeoffs such as avoiding redundant conversions or full-surface repaints.
Source Of Truth
Prefer pixman semantics and pixel-correctness first, then adapt them to wlframe.
Within this repository, relevant integration points include:
buffer/pixman/buffer.crenderer/pixman/**- relevant public headers under
include/wlf/** - top-level
meson.build
wlframe Integration Notes
- wlframe maps external buffer formats to pixman formats with endianness-specific conditionals.
- Pixman render buffers subscribe to wlframe buffer destroy events.
- Pixman image creation uses raw buffer data and stride from wlframe buffer access helpers.
Mandatory Rules
1) Format Mapping
- Treat external format and pixman format mapping as correctness-critical.
- Review both little-endian and big-endian branches when changing format tables.
- Unsupported format handling must fail clearly.
- Do not add silent fallback formats that may corrupt channel ordering.
- Be explicit about premultiplied alpha assumptions when introducing new formats or operators.
2) Buffer Data Access
- Use begin/end access helpers as a strict pair around raw memory access windows.
- Do not keep raw data assumptions alive longer than the buffer access contract allows.
- If pixman image lifetime depends on the backing storage remaining valid, make that ownership and access contract explicit.
- Avoid creating pixman images from data pointers whose validity ends before the image use ends.
- Review stride, row padding, and alignment assumptions whenever pixel layout changes.
3) Listener And Buffer Lifetime
- Link buffer-destroy listeners exactly once.
- Unlink listeners before freeing the pixman render buffer.
- A pixman render buffer destroy helper may accept
NULL; ordinary helpers should not silently hide invalid objects. - Keep listener teardown consistent between manual destroy and signal-driven destroy.
4) Compositing And Pixel Semantics
- Choose pixman operators intentionally; alpha, mask, and blending semantics matter.
- Keep source, mask, and destination roles clear in compositing code.
- Do not mix premultiplied and non-premultiplied assumptions implicitly.
- Treat color-channel ordering and endian-sensitive format interpretation as review-critical.
5) Regions, Clipping, And Damage
- Use regions and clipping to model visible and damaged areas explicitly.
- Prefer incremental redraw logic that matches the actual damaged region instead of repainting blindly.
- Keep region ownership and mutation boundaries clear when regions are shared across helpers.
6) Software Rendering Discipline
- Prefer direct, explicit memory and stride calculations over hidden macros.
- Keep pixman wrapper responsibilities narrow: format lookup, image creation, listener wiring, and teardown.
- Do not let software-rendering helpers mutate unrelated wlframe buffer state unexpectedly.
- When performance matters, optimize after correctness of format, stride, clip, and operator semantics is clear.
Code Review Protocol
Prioritize findings in this order:
- Wrong format mapping or endian mismatch.
- Invalid data pointer lifetime or mismatched begin/end access.
- Wrong operator, alpha, clip, or transform semantics.
- Damage or region handling that repaints too much or too little.
- Listener leaks, double unlink, or double destroy.
- Pixman image lifetime not matching backing buffer lifetime.
- Missing Meson or dependency follow-up for pixman code changes.
Review questions to answer:
- Is the format mapping correct for both endian configurations?
- Is the data pointer valid for as long as the pixman image needs it?
- Are operator, alpha, source, and destination semantics correct?
- Do clipping and damage regions match the intended redraw behavior?
- Do destroy paths remove listeners and unref the image exactly once?
- Does unsupported-format behavior fail loudly instead of corrupting pixels?
Validation Pointers
- When adding new pixman use sites, inspect format assumptions, operator semantics, clipping, and image lifetime together.
- When changing raster flow, verify raw memory access, region math, and blend semantics as one unit.
- Check format table edits against all related external pixel-format entries nearby.
- Review both manual destroy and signal-triggered destroy flows together.
- Reconfirm pixman dependency wiring if files or features move.
Response Pattern
For review tasks:
- Lead with format correctness, pixel semantics, region behavior, or raw-memory lifetime issues.
- Call out begin/end access mismatches, operator mistakes, and damage/clip bugs explicitly.
- Keep style comments secondary.
See also:
PLAYBOOK.mdfor implementation and review checklists.
When not to use it
- →Hardware-accelerated rendering
Prerequisites
Limitations
- →Software rendering performance constraints
How it compares
It ensures pixel-correctness and efficient buffer management in software rendering, avoiding common pitfalls like endianness mismatches.
Compared to similar skills
pixman side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| pixman (this skill) | 0 | 4mo | No flags | Advanced |
| vulkan | 0 | 4mo | No flags | Advanced |
| unity-developer | 142 | 4mo | No flags | Advanced |
| code-coverage-with-gcov | 15 | 4mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by zzxyb
View all by zzxyb →You might also like
vulkan
zzxyb
Use this skill when working on Vulkan broadly: instance and device setup, queues, swapchains, render passes, pipelines, descriptor sets, synchronization, memory allocation, command recording, extensions, validation layers, and Vulkan portability concerns. Best for full Vulkan implementation and code
unity-developer
sickn33
Build Unity games with optimized C# scripts, efficient rendering, and proper asset management. Masters Unity 6 LTS, URP/HDRP pipelines, and cross-platform deployment. Handles gameplay systems, UI implementation, and platform optimization. Use PROACTIVELY for Unity performance issues, game mechanics, or cross-platform builds.
code-coverage-with-gcov
gadievron
Add gcov code coverage instrumentation to C/C++ projects
unity-mcp-orchestrator
CoplayDev
Orchestrate Unity Editor via MCP (Model Context Protocol) tools and resources. Use when working with Unity projects through MCP for Unity - creating/modifying GameObjects, editing scripts, managing scenes, running tests, or any Unity Editor automation. Provides best practices, tool schemas, and workflow patterns for effective Unity-MCP integration.
arm-cortex-expert
sickn33
Senior embedded software engineer specializing in firmware and driver development for ARM Cortex-M microcontrollers (Teensy, STM32, nRF52, SAMD). Decades of experience writing reliable, optimized, and maintainable embedded code with deep expertise in memory barriers, DMA/cache coherency, interrupt-driven I/O, and peripheral drivers.
3d-games
davila7
3D game development principles. Rendering, shaders, physics, cameras.