c++ - que - webkit caracteristicas

Optimizando el rendimiento de la animación en WebKit en Linux

Question

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

Fondo

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

Sin embargo, estamos intentando usar WebKit puro para representar estas animaciones utilizando WebKitGTK + en Python y compilando WebKit en un navegador simplista desde la fuente.

Estado actual

En ambas aplicaciones de webkit "puras", las animaciones son mucho más lentas que en Chromium, lo que nos hace rascarnos la cabeza para responder a lo que es exactamente diferente entre las 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 de gráficos que es independiente de WebKit y Web Core. , basado en lo que hemos leído.

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

Me estoy preguntando ...

1. ¿Es correcta nuestra suposición sobre el componente gráfico separado?
2. ¿Qué opciones existen para que podamos optimizar el rendimiento de la animación CSS en un navegador WebKit "puro" como el nuestro?

Answer 1

De acuerdo con el artículo de Guil Hernández , las animaciones de CSS, las transformaciones y las transiciones no son automáticamente aceleradas por GPU, y en su lugar se ejecutan desde el motor de renderización de software más lento del navegador. Entonces, ¿qué es exactamente lo que obliga al navegador a cambiar al modo GPU? Muchos navegadores proporcionan aceleración de GPU por medio de ciertas reglas de CSS.

Ejemplo:

.cube {
   -webkit-transform: translate3d(250px,250px,250px)
   rotate3d(250px,250px,250px,-120deg)
   scale3d(0.5, 0.5, 0.5);
}

Answer 2

No estoy seguro de poder ayudarlo con su proyecto, pero una de las cosas que aprendí últimamente es que podemos acelerar las funciones de CSS con uso intensivo de gráficos descargándolos a la GPU para un mejor rendimiento de renderizado en el navegador.

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

Digamos que desea colocar su DOM con una posición absoluta y elevarlo por encima del contenedor principal. En lugar de eso, puedes usar -webkit-transform: translate3d(10px,10px,10px); Eso se resolverá en una representación 3D incluso si no animamos el elemento en absoluto. Incluso si establece valores de cero, seguirá activando la aceleración de gráficos.

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

Ahora hablemos de los conceptos básicos de CSS

Debe saber que lo más importante acerca de cómo los navegadores LEEN sus selectores de CSS, es que los leen 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, las ID son las más eficientes, dejando los universales menos. Por lo tanto, puede volver a escribir su código CSS reemplazando los globales (cuando no son realmente necesarios) con ID .

Otra forma de ralentizar el navegador es agregar el selector global por adelantado. (div # my-div) Algo que Chrome está haciendo de forma predeterminada en el modo de inspección. Eso ralentizará GRATAMENTE su navegador .

Por mucho, el peor de los casos son los selectores descendientes . 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 limpio son los selectores de CSS3 (: last-child). Incluso si esos selectores nos ayudan y hacen nuestra vida más fácil, destruyen su navegador. Es posible que no veas ninguna diferencia en el rendimiento en una aplicación a pequeña escala, pero cuando las introduzcas en aplicaciones empresariales, notarás que están ralentizando tu representación.

Así que para resumir. Acabo de decirles que reemplazar todos sus selectores con ID y aplicar estilo en cada elemento individual por ID hará que su aplicación sea súper rápida, pero por otro lado será un poco tonto. Sería extremadamente difícil de mantener y también no semántico. Por lo tanto, debería considerar reemplazar la mayoría de los selectores con ID, pero no sacrifique la semántica / mantenibilidad por CSS eficiente

También puedes ver una prueba interesante here .

Ahora que lo pienso, debería comenzar con lo básico de CSS. Bueno, espero haberte ayudado un poco con tu proyecto. Aclamaciones