WPE WebKit y WebKitGTK 2.54 estrenan un compositor Skia en lugar de TextureMapper
Igalia sustituye el motor de composición que arrastraba desde 2010 por una implementación sobre Skia, con menos shaders propios y funciones que antes no existían.
WPE WebKit y WebKitGTK 2.54 ya están publicados, y el cambio de fondo de esta versión es el compositor. TextureMapper, que llevaba haciendo ese trabajo desde 2010, deja paso a una implementación basada en Skia. El equipo de gráficos de Igalia ha dedicado el ciclo entero a este reemplazo.
TextureMapper nació en 2010 para el puerto de Qt y luego lo adoptaron otros. Funciona sobre OpenGL ES y mantiene su propia colección de programas shader. El código está prácticamente igual que entonces, sin mantenimiento y con funciones que nunca se llegaron a implementar. La idea no era ganar en benchmarks, sino modernizar, quitarse de encima código propio que mantener y dejar el terreno preparado para añadir lo que faltaba y arreglar lo que estaba roto.
Cómo está montado
El primer paso fue una clase SkiaCompositingLayer en sustitución de TextureMapperLayer, con una variable de entorno para elegir una u otra durante la transición. Las capas siguen generando sus texturas igual que antes (contenido por tiles, búferes de vídeo, WebGL, canvas 2D acelerado) y la clase nueva crea una superficie Ganesh para dibujarlas con drawImageRect. Esa base inicial ya movía la suite MotionMark por defecto sin perder rendimiento.
Los filtros fueron el primer punto delicado. La aproximación con superficie intermedia, la que usaba TextureMapper, funcionaba pero hundía la puntuación en el test de filtros. Resulta que con Skia casi todos los tipos salvo blur y drop shadow se pueden reducir a un SkColorFilter mediante asAColorFilter y aplicarse sin superficie intermedia, solo poniendo el filtro en el SkPaint que recibe drawImageRect. Además de arreglar la regresión, quedó por encima de TextureMapper, que siempre necesita esa superficie.
Con las máscaras pasó algo parecido. Hay dos clases: máscara de imagen y clip path. Antes ambas se resolvían pintando en superficies intermedias con modo de mezcla DstIn. Ahora la máscara de imagen se pinta una vez, se cachea y se pasa a clipShader, sin superficie de por medio. La de clip path ni siquiera necesita convertirse en imagen: se construye el SkPath y va directo a clipPath.
Lo que ahora funciona y antes no
Los contextos de capa 3D dependían poco de TextureMapper y de OpenGL, así que se trasladaron casi tal cual, con SkPath para los clips. De paso se corrigió el orden en Z, que en TextureMapper siempre estuvo mal: en una caja que intersecta un plano girado, el compositor antiguo la pintaba plana contra el plano y perdía la intersección, mientras que el nuevo la parte y esconde la mitad que queda detrás.
Los modos de mezcla son nuevos de verdad. TextureMapper no los soportaba y con Skia basta con activar la propiedad correspondiente en SkPaint, lo que hizo pasar varios tests de layout. El último frente fue el batched painting: tres pruebas de composición de MotionMark daban resultados mucho peores porque muchas capas pequeñas saturaban la cola de comandos de Ganesh, que acumula operaciones GL antes de enviarlas a la GPU.
Los números que acompañan al post están tomados con WPE y renderizado por GPU en una Raspberry Pi 4, comparando TextureMapper en la revisión 312400 con el compositor Skia en la 313600. En la prueba de círculos con mezcla, la puntuación alta de TextureMapper corresponde a no hacer el trabajo, porque los modos de mezcla no existían.
Para quien empaquete o despliegue WPE WebKit y WebKitGTK, la versión 2.54 trae este compositor de serie. El resultado no es un salto de rendimiento, es menos código propio que arrastrar y un conjunto de funciones que ahora se comportan como se espera en páginas reales. Las notas de la versión de WPE WebKit y el anuncio de WebKitGTK 2.54.0 tienen el detalle de APIs nuevas del ciclo.
