Optimización del rendimiento de la animación en WebKit en Linux

¿Cómo se optimiza un navegador WebKit compilado para aprovechar al máximo la GPU?

Antecedentes

Mi equipo y yo estamos trabajando en la configuración de un Linux box (CentOS) para mostrar HTML a pantalla completa con animaciones suaves y basadas en CSS. La caja tiene una potencia de GPU y CPU más que adecuada y es capaz de reproducir estas animaciones fácilmente en Chromium.

Sin embargo, estamos intentando usar pure WebKit para renderizar estas animaciones usando WebKitGTK + en Python y compilando WebKit a un navegador simplista desde el código fuente.

Situación actual

En ambas aplicaciones webkit "puras", las animaciones son mucho más lentas que en Chromium, lo que nos está haciendo rascarnos la cabeza para responder qué exactamente es diferente entre los dos. Entendemos que Chromium usa Blink, una bifurcación de WebKit, y actualmente creemos que la diferencia en el rendimiento se debe al hecho de que Chromium, Safari y otros navegadores basados en WebKit utilizan cada uno su propio componente gráfico que es independiente de WebKit y Web Core en sí, basado en lo que hemos leído.

Sería genial si pudiéramos personalizar nuestra compilación de WebKit para realizar incluso la mitad de las especificaciones de lo que estamos viendo en Chromium, pero no estamos seguros de por dónde empezar.

Me pregunto...

  1. ¿Es correcta nuestra suposición sobre el componente gráfico separado?
  2. ¿Qué opciones existen para optimizar el rendimiento de animación CSS en un WebKit" puro" navegador como el nuestro?
Author: Adam Grant, 2018-01-30
Source

2 answers

No estoy seguro de si puedo ayudarlo con su Proyecto, pero una de las cosas que he aprendido últimamente es que podemos acelerar por hardware las características CSS intensivas en gráficos descargándolas a la GPU para un mejor rendimiento de renderizado en el navegador.

En este momento la mayoría de los navegadores modernos se entregan con aceleración de hardware. Lo usarán cuando véase que el DOM se beneficiará de ello. Un indicador fuerte es la transformación 3D.

Permite digamos que quieres colocar tu DOM con una posición absoluta y levantarla por encima del contenedor padre. En lugar de eso, podría usar -webkit-transform: translate3d(10px,10px,10px); Que se resolverá en un renderizado 3D incluso si no animamos el elemento en absoluto. Incluso si establece valores cero, todavía activará la aceleración gráfica.

TIP Si ve algún parpadeo, intente agregar -webkit-backface-visibility: hidden; y -webkit-perspective: 1000;

Ahora hablemos de los conceptos básicos de CSS

Usted debe saber que los más importantes la cosa acerca de cómo los navegadores LEEN sus selectores CSS, es que los leen de de derecha a izquierda. Eso significa que en el selector ul > li img[alt="test.png"] lo primero que se interpreta es img[alt="test.png"]. La primera parte también se conoce como el"selector de teclas".

Así que lo primero es lo primero, los ID son los más eficientes, dejando los universales los menos. Por lo que podría reescribir su código CSS reemplazando los globales (cuando no son realmente necesarios) con IDs.

Otra forma de ralentizar su para bajar el navegador se agrega el selector global por adelantado. (div#my-div) Algo que Chrome está haciendo por defecto en el modo de inspección. Eso ralentizará enormemente tu navegador.

Con mucho, el peor de los casos son los selectores descendentes. Incluso un selector que falla (cuando su selector no coincide con nada) es mejor que html body div ul li a { }

Una cosa más, que es extremadamente útil y limpia son los selectores CSS3 (:last-child). Incluso si esos selectores nos ayudan y hacer nuestra vida más fácil, rasgan su navegador hacia abajo. Es posible que no vea ninguna diferencia en el rendimiento de una aplicación a pequeña escala, pero cuando las introduzca en Aplicaciones empresariales, notará que están ralentizando su procesamiento.

Para resumir. Acabo de decirte que reemplazar todos tus selectores con IDs y aplicar estilo a cada elemento por ID hará que tu aplicación sea súper rápida, pero por otro lado será un poco tonta. Sería extremadamente difícil de mantener y también no semántica. Por lo tanto, debe considerar reemplazar la mayoría de los selectores con IDs, pero no sacrifique semántica / mantenibilidad por CSS eficiente

También se puede comprobar una prueba interesante aquí.

Ahora que lo pienso, debería comenzar con los conceptos básicos de CSS. Bueno, espero haberte ayudado aunque sea un poco con tu Proyecto. Salud

 3
Author: Giannis Faropoulos,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-02-12 23:06:58

De acuerdo con Artículo de Guil Hernandez Las animaciones, transformaciones y transiciones CSS no se aceleran automáticamente por GPU, sino que se ejecutan desde el motor de renderizado de software más lento del navegador. Entonces, ¿qué obliga exactamente al navegador a cambiar al modo GPU? Muchos navegadores proporcionan aceleración de GPU por medio de ciertas reglas CSS.

Ejemplo: 

.cube {
   -webkit-transform: translate3d(250px,250px,250px)
   rotate3d(250px,250px,250px,-120deg)
   scale3d(0.5, 0.5, 0.5);
}
 1
Author: user5377037,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-02-14 14:13:12