¡Muy reptiliano!
Añade uno rotado unos 60 grados en sentido antihorario 180 grados sobre el eje y y tendrás los ojos de un resucitado
Añade una imagen especular que ha sido rotada sobre el eje y para obtener dos imágenes (ojos)
Vamos Discourse un rex
sí, no puedo sacarme esto de la cabeza y definitivamente necesito salir más
¡He puesto un cargador de monociclo aquí! https://unicyclist.com
¡Genial!
La animación original fue mía solo con CSS, y le pedí a Gemini que la “convirtiera” (por así decirlo) en SVG.
En la pantalla de carga de https://unicyclist.com, la barra de carga parece extenderse más allá del fondo.
Gracias. Un usuario informó de esto. Hubo algunas peculiaridades de SVG (?) que hicieron que la imagen apareciera… rara al subirla a una publicación, pero no en la pantalla de carga.
Por ejemplo, esta versión anterior:
Se ve completamente rota aquí, incluso cuando hacemos clic en ella (muestra una barra de carga doble…).
Pero se ve bien cuando se usa como pantalla de bienvenida (splash screen).
Pregunté sin pensar a Gemini que lo “arreglara”, lo que creó el SVG que publiqué y se ve bien, aunque aparentemente ciertos usuarios tienen un problema con la barra de progreso. Supongo que esto es lo que ves:
Yo no tengo ningún problema en Chrome/Firefox de Windows ni en Android/Chrome.
No sé si existe algún tipo de relación entre Discourse y estos fallos.
Así que, para mantener el tema, además de las animaciones no CSS, ¿hay algo a tener en cuenta cuando queremos usar un SVG animado para una pantalla de bienvenida?
Utilizo clipPaths en mis SVG para evitar que los elementos se desborden.
Quizás instruir a Gemini de la siguiente manera sería efectivo:
La barra de carga en este SVG se está extendiendo más allá del fondo. Por favor, modifícala para asegurar que permanezca dentro de los límites del fondo usando un clipPath.
Muchas gracias por la función, yo también lo he intentado, todavía no estoy del todo satisfecho, pero estoy arreglándolo 
He abierto por separado una implementación preliminar relacionada, pero la idea general es simplemente un posible complemento a esta funcionalidad:
El enfoque actual con un solo SVG que utiliza var(--primary), var(--secondary) y var(--tertiary) sigue siendo la opción más limpia y sencilla para la mayoría de los sitios, especialmente cuando el mismo SVG solo necesita adaptar sus colores.
El caso de uso que estaba explorando es un caso límite en el que una pantalla de bienvenida en modo oscuro requiere un recurso genuinamente diferente o un tratamiento óptico distinto, en lugar de simplemente recolorear el mismo SVG. Por ejemplo, un encabezado oscuro para usuarios registrados podría funcionar mejor con un tratamiento de logotipo/fondo transparente específico, mientras que la vista de inicio de sesión o pantalla de bienvenida para usuarios anónimos podría necesitar un fondo de carbón ligeramente diferente o un SVG ajustado para lograr un mejor contraste.
Por lo tanto, la idea no es reemplazar el enfoque actual basado en variables, sino proporcionar una salida de emergencia para sitios donde el arte de la pantalla de bienvenida en modo oscuro realmente necesita diferir del arte de la pantalla de bienvenida en modo claro/por defecto.
Agradecemos sus comentarios sobre si esto debería implementarse como una configuración separada llamada splash_screen_image_dark, o si el enfoque actual de un solo SVG con variables de color debe seguir siendo la única ruta admitida.
Inicialmente intenté usar SVG animado para la pantalla de presentación. Aunque esto funciona en escritorio, descubrí que en dispositivos móviles, animar rutas complejas o elementos internos del SVG directamente, provoca retrasos e incluso detiene la animación.
Para garantizar una experiencia fluida, trasladé la lógica de animación a un contenedor HTML estándar (div) que envuelve al SVG. Al aplicar las animaciones CSS (transform, scale, opacity) al contenedor div en lugar de al SVG, los navegadores móviles pueden utilizar la aceleración por hardware de manera mucho más eficiente sin retrasos.
Me pregunto si la función podría ampliarse para incluir el formato WebP animado o si está estrictamente vinculada a las transformaciones de CSS.
Quiero decir, los archivos GIF son pesados, pero WebP es un estándar común sin pérdida de calidad en la actualidad. Logro que animaciones de 5 segundos a 200x200 píxeles y 15 FPS ocupen entre 50 y 100 KB. Incluso se puede reducir más a 2 o 3 segundos en un bucle.
¿Es posible adaptarse a las variantes de modo oscuro/claro?
Cada vez que cambio el SVG, la interfaz de usuario informa un error durante la carga, pero el archivo está ahí y funciona sin problemas.
Respondi a mí mismo porque estaba siendo un idiota. Solo hay que hacer referencia a las variables CSS del esquema de colores de Discourse en el SVG, y la animación se renderizará para modo claro/oscuro según sea necesario.
Veo que se mencionó el tamaño. ¿Hay planes para poder soportar una versión algo más grande de la animación de inicio?
Estoy recortando todo el espacio en blanco alrededor de la animación, así que espero que eso cree la impresión de una imagen más grande.
