Problemas gráficos en Linux

En Linux, Tauri renderiza a través de WebKitGTK. En algunas configuraciones, casi siempre con GPU de NVIDIA, WebKitGTK y el controlador gráfico no coinciden y obtienes desde una ventana en blanco hasta problemas sutiles de renderizado. Esta página recopila los síntomas conocidos y las soluciones alternativas. Consulta tauri-apps/tauri#9394 para ver los informes originales.

Síntomas comunes

• La ventana se abre pero permanece en blanco.
• La ventana parpadea, especialmente al cambiar de tamaño.
• La aplicación se cierra al cambiar de tamaño sin una salida de error útil.
• La consola muestra AcceleratedSurfaceDMABuf was unable to construct a complete framebuffer.
• La consola muestra Gdk-Message: Error 71 (Protocol error) dispatching to Wayland display.

La mayoría de estos provienen de que el renderizador DMABUF de WebKitGTK solicita formatos de buffer que el controlador de NVIDIA no proporciona. Consulta el rastreador de errores de WebKitGTK y los foros de NVIDIA para ver la discusión previa.

Soluciones alternativas

Prueba estas en orden. Las primeras mantienen la aceleración por hardware.

1. Asegúrate de que la configuración de modo de kernel (KMS) esté activada. Los controladores de NVIDIA anteriores a la versión 545 a menudo necesitan nvidia_drm.modeset=1 como parámetro del kernel.
2. Establece __NV_DISABLE_EXPLICIT_SYNC=1. Esto a menudo soluciona el bloqueo del Error 71 de Wayland sin un costo de rendimiento.
3. Establece WEBKIT_DISABLE_DMABUF_RENDERER=1. Soluciona el error de framebuffer de DMABUF y el bloqueo del Error 71, a costa de la ruta de renderizado más rápida.
4. Establece WEBKIT_DISABLE_COMPOSITING_MODE=1. Último recurso para el cierre silencioso al cambiar de tamaño. Esto deshabilita por completo la composición acelerada.

Puedes establecer estos valores en tu terminal para probar, o establecerlos en main() antes de que se cree el webview para que los usuarios no tengan que hacerlo:

fn main() {
  // Workaround for WebKitGTK on NVIDIA, see tauri-apps/tauri#9394
  #[cfg(target_os = "linux")]
  std::env::set_var("WEBKIT_DISABLE_DMABUF_RENDERER", "1");

  tauri::Builder::default()
    // ...
}

Solo envía una anulación incondicional como esta si has verificado que tu aplicación está afectada. Desactiva una ruta más rápida para todos, incluidos los usuarios en configuraciones que funcionan correctamente.

Fallos silenciosos: WebGL y canvas

No todos los problemas provocan un cierre o muestran un error. El contenido de WebGL y canvas puede terminar silenciosamente en una ruta lenta mientras que el resto de la aplicación parece estar bien. Dos cosas hacen que esto sea difícil de detectar desde el interior de tu frontend:

• La creación del contexto WebGL2 tiene éxito incluso cuando el resultado está respaldado por un rasterizador por software o una ruta de presentación lenta. No hay ningún error que capturar.
• WebKitGTK enmascara la cadena del renderizador WebGL para la protección contra huellas digitales (fingerprinting). WEBGL_debug_renderer_info reporta Apple GPU en todas las máquinas Linux, por lo que no puedes verificar qué hay realmente detrás del contexto.

En la práctica, esto se manifiesta como una alta latencia de entrada o tasas de fotogramas bajas en vistas con mucho uso de WebGL (emuladores de terminal, editores, mapas, gráficos), mientras que el mismo código es rápido en un navegador normal. Si tu aplicación tiene una ruta de renderizado WebGL, dale una opción de respaldo que no sea WebGL en Linux y considera exponer una configuración para que los usuarios puedan cambiarla, en lugar de confiar en lo que te indique el contexto.