# glsl A programming language for writing shaders for the programmable processors in the OpenGL API pipeline. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## 2026 Real-Time Shading Ecosystem Survey Results DevFeed: [2026 Real-Time Shading Ecosystem Survey Results]() Original publisher: [Read original article]() Author: jphilips (jeff@khronosgroup.org) Published: 2026-07-21T13:00:00Z Content type: release Language: en Sources: [Blogs Khronos Blog]() Topics: [releases](), [shaders](), [real-time](), [Programming](), [glsl](), [GPU]() Tags: [2026](), [blog](), [debugging](), [developers](), [glsl](), [graphics](), [porting](), [real-time](), [report](), [survey]() ### AI overview Khronos reports results from a 2026 survey of more than 400 shader developers, graphics programmers, rendering engineers, and tools creators. Shader debugging and profiling were the leading reported pain point, while cross-platform shader porting also affected a majority of respondents. ### Source excerpt Khronos releases the 2026 Real-Time Shading Ecosystem Survey Report, a summary of insights from over 400 shader developers, graphics programmers, rendering engineers, and tools creators. Conducted between June 16 and July 10, 2026, the survey captures a clear picture of how the real-time shading community works today -- and where standardization efforts can deliver the greatest impact. ## Inside Shopify Hack Days: Building a prototype for music-playing pages DevFeed: [Inside Shopify Hack Days: Building a prototype for music-playing pages]() Original publisher: [Read original article]() Author: Justin Henricks Published: 2026-07-14T13:55:57Z Content type: article Language: en Sources: [Shopify Engineering](), [Shopify Engineering - Shopify Engineering]() Topics: [glsl](), [real-time](), [App](), [Web](), [API](), [Template]() Tags: [3d](), [api](), [app](), [audio](), [generation](), [glsl](), [hackathon](), [interactive-3d](), [real-time](), [shopify](), [web]() ### AI overview Shopify's Hack Days team built a prototype for music-playing product pages in three days. The project combined a Shopify app, audio playback, per-track purchasing, GLSL visualizers driven by real-time audio, synced lyrics, and tour-date information. ### Source excerpt How a Hack Days team built a music player, custom GLSL visualizers, and an artist toolkit for storefronts, all in three days. ## A series of tricks and techniques I learned doing tiny GLSL demos DevFeed: [A series of tricks and techniques I learned doing tiny GLSL demos]() Original publisher: [Read original article]() Published: 2025-12-07T17:48:26Z Content type: tutorial Language: en Sources: [The Last Static Blog RSS]() Topics: [glsl](), [Demo](), [Code](), [iteration](), [color]() Tags: [code](), [demo](), [fun](), [glsl](), [graphics](), [iteration](), [math](), [prog](), [techniques](), [tricks]() ### AI overview This tutorial examines four tiny GLSL demos--Moonlight, Entrance 3, Archipelago, and Cutie--and explains selected techniques learned while creating them. It introduces an alternative raymarching approach using inverse-density color contributions and relates it to photon-density integration. ### Source excerpt In the past two months or so, I spent some time making tiny GLSL demos. I wrote an article about the first one, Red Alp. There, I went into details about the whole process, so I recommend to check it out first if you're not familiar with the field. We will look at 4 demos: Moonlight, Entrance 3, Archipelago, and Cutie. But this time, for each demo, we're going to cover one or two things I learned from it. It won't be a deep dive into every aspect because it would be extremely redundant. Instead, I'll take you along a journey of learning experiences. Moonlight Moonlight demo in 460 characters // Moonlight [460] by bµg // License: CC BY-NC-SA 4.0 void main(){vec3 o,p,u=vec3((P+P-R)/R.y,1),Q;Q++;for(float d,a,m,i,t;i++<1e2;p=t<7.2?Q:vec3(2,1,0),d=abs(d)*.15+.1,o+=p/m+(t>9.?d=9.,Q:p/d),t+=min(m,d))for(p=normalize(u)*t,p.z-=5e1,m=max(length(p)-1e1,.01),p.z+=T,d=5.-length(p.xy*=mat2(cos(t*.2+vec4(0,33,11,0)))),a=.01;a<1.;a+=a)p.xz*=mat2(8,6,-6,8)*.1,d-=abs(dot(sin(p/a*.6-T*.3),p-p+a)),m+=abs(dot(sin(p/a/5.),p-p+a/5.));o/=4e2;O=vec4(tanh(mix(vec3(-35,-15,8),vec3(118,95,60),o-o*length(u.xy*.5))*.01),1);} Note See it on its official page, or play with the code on its Shadertoy portage. In Red Alp, I used volumetric raymarching to go through the clouds and fog, and it took quite a significant part of the code to make the absorption and emission convincing. But there is an alternative technique that is surprisingly simpler. In the raymarching loop, the color contribution at each iteration becomes 1/d or c/d where d is the density of the material at the current ray position, and c an optional color tint if you don't want to work in grayscale level. Some variants exist, for example 1/d^2, but we'll focus on 1/d. 1/d explanation Let's see how it looks in practice with a simple cube raymarch where we use this peculiar contribution: One glowing and rotating cube void main() { float d, t; vec3 o, p, u = normalize(vec3(P+P-R,R.y)); // screen to world coordinate for (int i = 0; i < 30 ## Fast calculation of the distance to cubic Bezier curves on the GPU DevFeed: [Fast calculation of the distance to cubic Bezier curves on the GPU]() Original publisher: [Read original article]() Published: 2025-10-18T09:21:56Z Content type: article Language: en Sources: [The Last Static Blog RSS]() Topics: [GPU](), [glsl](), [WebGL](), [shaders](), [pixel](), [Code]() Tags: [glsl](), [gpu](), [graphics](), [math](), [maths](), [pixel](), [prog](), [shaders](), [source](), [visualization](), [webgl](), [webgl-demo]() ### AI overview This article explains how to calculate the distance from a point to a cubic Bézier curve on the GPU. It derives the distance function and its derivative, reducing the problem to solving a fifth-degree polynomial, and demonstrates the method with self-contained GLSL fragment shaders and WebGL visualizations. ### Source excerpt Bézier curves are a core building block of text and 2D shapes rendering. There are several approaches to rendering them, but one especially challenging problem, both mathematically and technically, is computing the distance to a Bézier curve. For quadratic curves (one control point), this is fairly accessible, but for cubic (two control points) we're going to see why it is so hard. A glyph from the Virgil font, composed of multiple Bézier curves Having this distance field opens up many rendering possibilities. It's hard, but it's possible; here is a live proof: Distance to a cubic Bézier curve In this visualization, I'm borrowing your device resources to compute the distance to the curve for every single pixel. The yellow points are the control points of the curve (in white) and the blue zone is a representation of the distance field. Note All the demos and code in this article are self-contained GLSL fragment shaders. Most of the code can be found in the article, but feel free to inspect the source code of any of these WebGL demo for the complete code. They can be run verbatim using ShaderWorkshop. The basic maths In a previous article, we explained that a Bézier curve can be expressed as a polynomial. In our case, a cubic polynomial: B_3(t) = \textbf{a}t^3 + \textbf{b}t^2 + \textbf{c}t + \textbf{d} Where a, b, c and d are the vector coefficients derived from the start (P_0), end (P_3), and control points (P_1, P_2) using the following formulas (you can refer to the previous article for details): \begin{aligned} \textbf{a} &= -P_0 + 3(P_1-P_2) + P_3 \\ \textbf{b} &= 3P_0 - 6P_1 + 3P_2 \\ \textbf{c} &= -3P_0 + 3P_1 \\ \textbf{d} &= P_0 \end{aligned} For a given point p in 2D space, the distance to that Bézier curve can be expressed as a length between our curve and p: \begin{aligned} d(t) &= ||B_3(t) - \textbf{p}|| \\ &= ||\textbf{a}t^3 + \textbf{b}t^2 + \textbf{c}t + \textbf{d} - \textbf{p}|| \end{aligned} Our goal is to find the t value where d(t) is the smallest. ## Code golfing a tiny demo using maths and a pinch of insanity DevFeed: [Code golfing a tiny demo using maths and a pinch of insanity]() Original publisher: [Read original article]() Published: 2025-09-29T13:30:50Z Content type: tutorial Language: en Sources: [The Last Static Blog RSS]() Topics: [glsl](), [Code](), [Canvas](), [coding]() Tags: [3d](), [canvas](), [code](), [coding](), [floating-point](), [fun](), [glsl](), [graphics](), [math](), [prog]() ### AI overview This tutorial explains how a 448-character GLSL fragment shader creates a procedural demo by evaluating mathematical formulas for each pixel. It examines the shader structure, WebGL2 canvas inputs, code-golfing techniques, and a local live-coding workflow. ### Source excerpt A few weeks ago, I made a tiny demo that fits into 448 characters: Red Alp GLSL demo in 448 characters void main(){vec3 c,p,K=vec3(3,1,0);for(float z,i,a,g=1.,t,h,d,w,k=.15;i++<1e2;d=max(max(d-3. ,-d),a=z)*k,w=g-g/exp(h>.001?a++,d/.4:h*3e2),g-=a*=w,c+=a*d*4.5+(d>z?z:h/2e2)*K,a=min(p.y+2. ,1.),c.r+=w*a*a*.1,t+=min(h*.2,k/=.985))for(p=normalize(vec3(P+P-R,R.y))*t,p.xz*=mat2(cos( sin(T*.2)+K.zyxz*11.)),p.z+=T*.3,d=p.y,h=d+.5,a=.01;a<1.;a+=a)p.xz*=mat2(8,6,-6,8)*.1,d+=abs (dot(sin((p/a+T)*.3),p-p+a)),h+=abs(dot(sin(p.xz*.6/a),P-P+a));O=vec4(tanh(c),1);} Note The number of characters was 464 characters at first, but thanks to the community it got reduced further, and the article updated accordingly. There is no texture, no mesh, no 3D helper: it's simply a procedural mathematical formula evaluated at each pixel assigning them a color. Code golfing is about making it as short as possible, and thus is part of the art performance. To put things into perspective, the 853x480 JPEG thumbnail of this article is 167x larger than this code. You can watch a larger version on its main dedicated page, or a portage on Shadertoy (484 chars). If your device is not powerful enough (I'm sorry for the lag on this page) or doesn't support WebGL2, a short preview video can be seen on Mastodon. I'm guessing the wizardry of the code has confused many people so we're going to dive through the making-of together. Overall, this demo is a particularly dense and entangled compilation of different techniques, where each aspect could mandate a dedicated article. For that reason, some parts will prefer to link to external resources when the literacy is verbose on the subject. Warning Some demos in this article will start "decaying" over time due to floating point variables getting too large. Reloading the page should fix that. The base template The code is written in GLSL and is executed for each pixel (technically each fragment) on a simple quad geometry (to be accurate it's even a single big triang ## Choosing sRGB, Linear RGB, and OkLab for Color Gradients DevFeed: [Choosing sRGB, Linear RGB, and OkLab for Color Gradients]() Original publisher: [Read original article]() Published: 2025-07-18T20:10:43Z Content type: article Language: en Sources: [The Last Static Blog RSS]() Topics: [glsl](), [color](), [Code]() Tags: [code](), [color](), [glsl](), [graphics](), [math](), [prog](), [technology]() ### AI overview This article examines how sRGB, linear RGB, and OkLab behave when generating color gradients. It explains that sRGB can produce muddy midtones, linear RGB models light energy correctly but may look less perceptually suitable, and OkLab generally provides the best perceptual result at a performance cost. It also notes that monochrome gradients produce different tradeoffs. ### Source excerpt The idea that we must always linearize sRGB gradients or work in a perceptually uniform colorspace is starting to be accepted universally. But is it that simple? When I learned about the subject, it felt like being handed a hammer and using it everywhere. The reality is a bit more nuanced. In this article we will see when to use which, how to use them, and we will then see why the situation is more dire than it looks. Code snippets Before we start, since we are going to use GLSL as language, following are the reference functions we will use for the rest of the article. vec3 s2l(vec3 c) { // sRGB to linear return mix(c/12.92, pow((max(c,0.0)+0.055)/1.055,vec3(2.4)), step(vec3(0.04045),c)); } vec3 l2s(vec3 c) { // linear to sRGB return mix(c*12.92, 1.055*pow(max(c,0.0),vec3(1./2.4))-0.055, step(vec3(0.0031308),c)); } vec3 l2oklab(vec3 rgb) { // linear to OkLab const mat3 rgb2lms = mat3( +0.4122214708, +0.2119034982, +0.0883024619, +0.5363325363, +0.6806995451, +0.2817188376, +0.0514459929, +0.1073969566, +0.6299787005); const mat3 lms2lab = mat3( +0.2104542553, +1.9779984951, +0.0259040371, +0.7936177850, -2.4285922050, +0.7827717662, -0.0040720468, +0.4505937099, -0.8086757660); vec3 lms = rgb2lms * rgb; return lms2lab * pow(lms, vec3(1.0/3.0)); } vec3 oklab2l(vec3 lab) { // OkLab to linear const mat3 lab2lms = mat3( +1.0000000000, +1.0000000000, +1.0000000000, +0.3963377774, -0.1055613458, -0.0894841775, +0.2158037573, -0.0638541728, -1.2914855480); const mat3 lms2rgb = mat3( +4.0767416621, -1.2684380046, -0.0041960863, -3.3077115913, +2.6097574011, -0.7034186147, +0.2309699292, -0.3413193965, +1.7076147010); vec3 lms = lab2lms * lab; return lms2rgb * (lms*lms*lms); } Also, the output of the pipeline will be expected to be sRGB all the time. Color gradients To illustrate how sRGB, linear RGB and OkLab respectively look like, let's interpolate between two colors with each one of them: Color gradients from top to bottom: sRGB, linear, OkLab The 3 stripes were generate ## Understanding Gradient Noise with WebGL2 and GLSL DevFeed: [Understanding Gradient Noise with WebGL2 and GLSL]() Original publisher: [Read original article]() Published: 2025-06-06T14:45:38Z Content type: tutorial Language: en Sources: [The Last Static Blog RSS]() Topics: [glsl](), [GPU](), [Code](), [hashing]() Tags: [code](), [complexity](), [cpu](), [floating-point](), [function](), [glsl](), [graphics](), [hashing](), [math](), [performance](), [procedural](), [prog]() ### AI overview This tutorial explains gradient noise, beginning with its one-dimensional form and progressing through higher dimensions and complexity. It uses a GPU-oriented approach with WebGL2 and GLSL, including deterministic coordinate-based pseudo-random values and hashing considerations. ### Source excerpt You've most likely heard about gradient noise through the name Perlin noise, which refers to one particular implementation with various CPU optimizations. Because it's an incredible tool for creative work, it's used virtually everywhere: visual effects, video games, procedural mathematical art, etc. While getting it right can sometimes be subtle, a "broken" implementation can still look good or interesting. After all, "it looks fine, and I'm an artist". In order to gain a deeper and more meaningful understanding we will start studying the 1D version (a case often omitted in the literature), then slowly climb our way up in dimensions and complexity. We'll also work from a GPU perspective rather than a CPU-based one, hence all code snippets and visuals here are implemented in WebGL2/GLSL (hopefully without being too heavy on performance). They should run on most modern devices; let me know if you run into issues. Before we begin, credit where it's due: most of the material here are nothing new. This article is the result of weeks of studying and experimenting with the maths from Inigo Quilez's incredible pages and other scattered resources over the Internet. But as rich and valuable these resources are, they sometimes move quickly over the details, assuming they're obvious. This post is an attempt to fill those gaps. A welcoming wavy 1D gradient noise signal Hashing function and pseudo-random values At the most elementary level, we need a deterministic coordinate based pseudo-random system. More specifically, for any given integer coordinate we need a random value, and as uniformly distributed as possible. Something like: \begin{aligned} h(-3) &= -0.006124 \\ h(-2) &= -0.996686 \\ h(-1) &= 0.200864 \\ h(0) &= -1.000000 \\ h(1) &= 0.053313 \\ h(2) &= -0.893312 \\ h(3) &= 0.854923 \\ \text{...} \end{aligned} Perlin's implementation relies on a permutation table, which is convenient when working on the CPU, but more awkward for a shader. On the GPU, most people rely on v ## Monthly Update on a Haskell Game Engine DevFeed: [Monthly Update on a Haskell Game Engine]() Original publisher: [Read original article]() Published: 2023-01-01T00:00:00Z Content type: opinion Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Game engine](), [Programming](), [shaders](), [glsl](), [Graphics]() Tags: [code](), [haskell](), [programming](), [render](), [shaders](), [technical](), [vulkan]() ### AI overview A monthly development update on Ghengin, an unreleased Haskell game engine. It describes a procedural-planets demo and outlines the engine's Vulkan renderer, FIR shaders embedded in Haskell, entity management, scene graph, render queue, and supporting libraries. ### Source excerpt Contents 1 Ghengin 1.1 Bullets on Technical Details 1.2 The Small Victories 1.3 A peek into the code 1 Ghengin I've been working the past month or two in a game engine titled Ghengin (pronounced /ɡɛn-ʤɪn/, never /ɡɛn-ɡɪn/). This is not yet a release, and version 0.1.0 is far into the future. However, I've come a long way and I'd like to share a few pictures of my progress. This post was migrated from the discussion at the Haskell Discourse The demo I've been working on is based on Sebastian Lague's series Procedural Planets. It is a showcase of procedurally generated planets you can move around in and tweak the procedural generation parameters of the planets to create oceans and continents. Fig 1. Screenshot of planets demo 1.1 Bullets on Technical Details I hope to, soon enough, write a more substantial explanation of the engine's technical challenges and overall design decisions so far, and on the game developer's facing side of the engine. In the meantime, here are a few key points regarding the technical feats of the engine along with the main libraries it currently depends on, which help create a picture of how it is working: The renderer is written using the great bindings to the Vulkan API The shaders are crucial in the overall design, and a lot of code depends on their definition (e.g. preparing render pipelines, allocating descriptor sets and textures, everything materials related ...). The shaders are written using FIR, an amazing shader language embedded in Haskell! The entity management, scene graph and render queue are done/created through the apecs entity component system. Vectors and matrices are from geomancy GLFW-b for window management and user input (used as the window backend for vulkan) The dear-imgui bindings for the GUI JuicyPixels for loading textures FIR is a really cool shader library and unlike any you've likely tried before (it's embeded in Haskell, but that's just the start). The shader's "interfaces" are defined at the type level, and in ## Building a Pride Rainbow Easter Egg into the Over Android App 🏳🌈 DevFeed: [Building a Pride Rainbow Easter Egg into the Over Android App 🏳🌈]() Original publisher: [Read original article]() Author: Rebecca Franks Published: 2021-06-13T09:39:08Z Content type: tutorial Language: en Sources: [Rebecca Franks - @riggaroo]() Topics: [OpenGL](), [Android](), [glsl](), [implementation](), [render]() Tags: [android](), [glsl](), [guide](), [implementation](), [opengl](), [pride](), [rainbow](), [render](), [ui]() ### AI overview This tutorial explains how the Over Android app implements a Pride-themed Easter egg: text containing selected LGBTQ+ terms changes a text-layer outline into an animated rainbow. It focuses on rendering the gradient bounding box with OpenGL, Android SurfaceView, and GLSL shaders. ### Source excerpt This post originally appeared here on the GoDaddy Engineering blog. The Over App is a playground for creating beautiful content for social media. As developers on the app, we are often inspired by the pictures and videos that our users make. To inspire our users a bit more, we decided to create a small easter [...] The post Building a Pride Rainbow Easter Egg into the Over Android App 🏳🌈 appeared first on Rebecca Franks - @riggaroo. ## Language Injections in Android Studio / IntelliJ IDEA 💉 DevFeed: [Language Injections in Android Studio / IntelliJ IDEA 💉]() Original publisher: [Read original article]() Author: Rebecca Franks Published: 2021-01-20T09:19:12Z Content type: tutorial Language: en Sources: [Rebecca Franks - @riggaroo]() Topics: [Android Studio](), [Syntax Highlighting](), [ide](), [IntelliJ IDEA](), [SQL](), [glsl](), [Kotlin]() Tags: [android](), [android-studio](), [glsl](), [ide](), [idea](), [intellij-idea](), [kotlin](), [language-injection](), [opengl](), [sql](), [studio](), [syntax-highlighting]() ### AI overview This tutorial explains how language injection in Android Studio and IntelliJ IDEA enables embedded code such as SQL or GLSL to receive syntax highlighting, validation, suggestions, and separate-editor support. It also describes using annotations and the GLSL Support Plugin for Kotlin string literals. ### Source excerpt Android Studio is a powerful IDE with a multitude of features that I'll probably never discover. However, when I do discover a feature of the IDE that I've been dreaming about, I get irrationally excited about it (and often times write a blog post such as this one). One feature that really piqued my interest [...] The post Language Injections in Android Studio / IntelliJ IDEA 💉 appeared first on Rebecca Franks - @riggaroo.