glslviewer-shader-debug
glslViewer Shader Debug
Use this skill to turn shader math into repeatable headless previews.
Workflow
- Confirm
glslVieweris available withcommand -v glslViewer || command -v glslviewer. - Create a scratch
.fragfile, usually by copyingassets/sdf-contour-template.frag. - Translate the source shader into standard GLSL.
- Render the shader with
scripts/render_headless.sh. - Inspect the generated PNGs and compare the contour or mask shape against expectations.
Translation Rules
- For runtime-shader or SkSL-like snippets, read
references/runtime-effect-to-glsl.md. - Keep the math identical first. Change syntax before changing behavior.
- Replace non-standard types such as
half4orfloat2with GLSL equivalents. - Rewrite
main(vec2 fragCoord)into standard fragment entrypoint form:
void main()
{
vec2 fragCoord = gl_FragCoord.xy;
fragColor = ...;
}
- Prefer adding a contour or mask visualization instead of staring at raw SDF alpha. The template already includes a reusable
previewColor()helper.
Rendering
Render one or more fragment shaders like this:
/root/.codex/skills/glslviewer-shader-debug/scripts/render_headless.sh path/to/a.frag path/to/b.frag
Useful options:
--output DIR: choose output directory--size WIDTHxHEIGHT: choose render size, default256x256GLSLVIEWER_BIN=/full/path/to/glslViewer: force a specific binary
The script writes one PNG per input shader plus a frame directory that contains the original exported frame.
Validation Heuristics
- For rounded-rect SDFs, top and bottom scanlines should narrow near the corners.
- For gradients or normals, prefer false-color output so directional changes are obvious.
- If the headless preview looks correct but device output does not, suspect uniform binding, backend shader translation, or downstream thresholding rather than the pure math.
Resources
- Renderer:
scripts/render_headless.sh - Translation notes:
references/runtime-effect-to-glsl.md - Starter template:
assets/sdf-contour-template.frag
More from openharmonyinsight/openharmony-skills
openharmony-security-review
Use when reviewing OpenHarmony C++ system service code for security vulnerabilities, particularly IPC handlers, multithreaded components, or code handling sensitive user data
77openharmony-cpp
Expert coding guide for OpenHarmony C++ development. Use this skill when writing, refactoring, or reviewing C++ code for OpenHarmony projects. It enforces strict project-specific conventions (naming, formatting, headers) and critical security requirements (input validation, memory safety).
76oh-ut-generator
|
65ai-generated-ut-code-review
Use when reviewing or scoring AI-generated unit tests/UT code, especially when coverage, assertion effectiveness, or test quality is in question and a numeric score, risk level, or must-fix checklist is needed
50compile-analysis
This skill should be used when the user asks to "分析编译效率", "分析编译时间", "查看头文件依赖", "保存编译命令", "提取编译命令", "生成编译脚本", "保存这个文件的编译命令", "单独编译这个文件", "编译单个文件", "单编文件", "独立编译文件", "分析这个文件的头文件依赖", "头文件依赖关系", "这个文件依赖了多少头文件", "analyze compilation", "check header dependencies", "分析文件编译开销", "save compile command", "extract compile command", "generate compile script", "compile single file", "compile individual file", "standalone compile", "analyze header dependencies", "header dependency tree", "how many header files", or mentions analyzing compilation performance, build times, include dependencies, extracting/saving compilation commands, generating standalone compilation scripts, compiling individual files in isolation, or analyzing header file dependency relationships for specific source files in the ace_engine project. Provides comprehensive compilation efficiency analysis including timing, resource usage, dependency tree visualization with automatic saving, the ability to save reusable compilation scripts with performance monitoring, and standalone compilation capabilities using generated scripts.
49arkui-api-design
This skill should be used when the user asks to "design ArkUI API", "add component property", "create Modifier method", "review ArkUI API", "deprecate API", "write JSDOC for ArkUI", or mentions OpenHarmony API design standards. Provides comprehensive guidance for ArkUI component API design following OpenHarmony coding guidelines, including static/dynamic interface synchronization, SDK compilation, and verification.
47