Metal y shaders en SwiftUI: efectos a medida

Hay una frontera donde la composición declarativa se agota: efectos que dependen del valor de cada píxel individual, de su distancia a un punto, del ruido evaluado en su coordenada o de una deformación continua del plano. Nada de eso se expresa combinando máscaras y modos de mezcla, porque exige computación arbitraria por fragmento. SwiftUI abre esa puerta con una elegancia notable: escribes una función en Metal Shading Language, la marcas como enlazable, y el framework la inyecta en su propio pipeline de renderizado como un modificador más. Es el descenso más profundo disponible sin abandonar el framework, y como todo descenso, se justifica por lo que hay abajo y se paga en lo que dejas arriba.

Anatomía de una función enlazable

El shader vive en un archivo con extensión metal dentro del objetivo, se compila junto a la app y se localiza en tiempo de ejecución por su nombre. El atributo stitchable es lo que permite a SwiftUI coserlo dentro de su propio pipeline en vez de exigir una cadena de renderizado propia:

#include <metal_stdlib>
#include <SwiftUI/SwiftUI_Metal.h>
using namespace metal;

[[ stitchable ]] half4 tinteRadial(float2 posicion,
                                   half4 color,
                                   float2 centro,
                                   float radio,
                                   half4 acento) {
    float d = distance(posicion, centro) / max(radio, 1.0);
    half mezcla = half(saturate(1.0 - d));
    return mix(color, acento * color.a, mezcla) ;
}

La firma no es libre: el primer parámetro es siempre la posición del píxel en el espacio de la vista, el segundo el color que ese píxel tendría sin el efecto, y a partir de ahí vienen tus argumentos. El tipo de retorno half4 es color premultiplicado por alfa, y ese detalle explica la mayoría de los halos y bordes sucios de los primeros intentos: si multiplicas el color sin multiplicar también el alfa, rompes la invariante que espera el compositor.

Del lado de Swift, la biblioteca de shaders se consulta por nombre gracias a la búsqueda dinámica de miembros, y los argumentos se envían con constructores tipados:

tarjeta.colorEffect(
    ShaderLibrary.tinteRadial(
        .float2(centro),
        .float(180),
        .color(.orange)
    )
)

Los tres puntos de enganche

SwiftUI ofrece tres modificadores, y la diferencia entre ellos no es de estilo sino de qué información recibe el shader y cuánto trabajo obliga al sistema a preparar.

colorEffect es el más barato: recibe posición y color del píxel, y no puede mirar a sus vecinos. Sirve para tintes, umbralizados, curvas de color, patrones procedurales y ruido.

layerEffect recibe una capa muestreable en lugar de un color, de modo que puedes leer el contenido en cualquier coordenada. Eso habilita desenfoques propios, aberraciones cromáticas, píxeles agrandados o efectos de dispersión, y a cambio obliga a materializar el contenido como textura antes de ejecutar el shader:

[[ stitchable ]] half4 pixelado(float2 posicion,
                                SwiftUI::Layer capa,
                                float tamano) {
    float2 celda = floor(posicion / tamano) * tamano + tamano * 0.5;
    return capa.sample(celda);
}

distortionEffect opera en el espacio geométrico: no devuelve color sino la posición desde la que se debe muestrear, lo que permite ondas, lentes y pliegues. Exige declarar un desplazamiento máximo de muestreo, porque el sistema necesita saber cuánto margen reservar alrededor de la vista para que el efecto no se recorte.

imagen.distortionEffect(
    ShaderLibrary.onda(.float(fase), .float(amplitud)),
    maxSampleOffset: CGSize(width: 24, height: 24)
)

flowchart TD
A[Vista SwiftUI] --> B[Se materializa como textura]
B --> C[Shader stitchable en la GPU]
C --> D[colorEffect solo color por pixel]
C --> E[layerEffect muestreo del contenido]
C --> F[distortionEffect nueva coordenada]
D --> G[Composicion final]
E --> G
F --> G
style C fill:#cba6f7,color:#11111b
style B fill:#fab387,color:#11111b

Animar sin estado

Un shader no recuerda nada entre fotogramas: es una función pura evaluada de nuevo cada vez. La animación, por tanto, no se logra mutando el shader sino inyectando el tiempo como argumento y dejando que el resultado dependa de él. La pareja idiomática es un TimelineView que provee el instante y un visualEffect que aporta la geometría real medida, evitando que el cálculo del tamaño realimente el layout:

TimelineView(.animation) { contexto in
    let t = contexto.date.timeIntervalSinceReferenceDate

    contenido.visualEffect { vista, proxy in
        vista.colorEffect(
            ShaderLibrary.brilloBarrido(
                .float(t),
                .float2(proxy.size),
                .float(reducirMovimiento ? 0 : 1)
            )
        )
    }
}

Ese último argumento es el que separa una demo de un producto: la preferencia de movimiento reducido, leída del entorno, viaja al shader como un interruptor y permite que el efecto se congele en un estado estático razonable en lugar de desaparecer. La misma técnica sirve para el esquema de color, el contraste aumentado o cualquier condición del sistema que deba modular el resultado.

Coste y criterio

Un shader se ejecuta una vez por píxel cubierto y por fotograma. La aritmética es implacable: una superficie de cuatrocientos por ochocientos puntos en una pantalla de tres veces de densidad son casi tres millones de fragmentos, y a ciento veinte fotogramas por segundo eso son cientos de millones de invocaciones por segundo. El coste unitario del código importa poco hasta que lo multiplicas por ese número.

De ahí salen reglas operativas concretas. Usa half en lugar de float siempre que la precisión lo permita, porque las GPU de Apple procesan el doble de operaciones en media precisión. Evita ramificaciones dependientes de la posición, que provocan divergencia entre hilos del mismo grupo. Prefiere colorEffect a layerEffect cuando no necesites vecindad, ya que el segundo obliga a una pasada de materialización. Y desconfía de aplicar shaders a áreas grandes que se desplazan, donde el efecto se recalcula en cada fotograma de la animación de scroll.

Hay además un coste que no aparece en ningún perfil de GPU. Una vista con shader se rasteriza, lo que significa que el sistema pierde parte de la información semántica sobre lo que hay dentro: los efectos se aplican al resultado visual, no al árbol, y cualquier suposición sobre nitidez de texto o escalado vectorial deja de ser válida. La accesibilidad y el tacto siguen funcionando sobre la vista original, pero el usuario ve algo que el sistema ya no puede describir ni adaptar.