Very reptilian!
Add one rotated about 60 degrees counter clockwise 180 degrees about the y axis and you the eyes of a resurrected
Add a mirror image that has been rotated about the y axis so two images (eyes)
Go Discourse a rex
yep, can’t get this out of my head and definitely need to get out more
I’ve set a unicycle loader here! https://unicyclist.com
Neat!
The original animation was by me with CSS only, and I asked Gemini to “convert” it (so to speak) to SVG.
On the loading screen of https://unicyclist.com , the loading bar seems to extend beyond the background.
Thank you. A user reported this. There were some SVG quirks (?) that made the image appears… Weird, when uploaded to a post, but not on the loading screen.
For example, this olders version:
Looks completely broken here, even when we click on it (it shows a double loading bar…).
But looks fine when used as a splash screen.
I brainlessly asked Gemini to “fix it”, which created the SVG I posted and looks OK, yet apparently certain users have an issue regardint the progress bar. I suppose this is what you see:
I don’t have any issue on Windows Chrome/Firefox or Android/Chrome.
I don’t know if there’s any kind of relationship between Discourse and those glitches.
So, to stay in topic, besides non-CSS animations, are there some things to be aware of when we want to use an animated SVG for a splash screen?
I utilize clipPaths in my SVGs to prevent elements from overflowing.
Perhaps instructing Gemini in the following manner would be effective:
The loading bar in this SVG is extending beyond the background. Please modify it to ensure it remains within the confines of the background using a clipPath.
I opened a related draft implementation separately, but the broader idea is simply a possible follow-up to this feature:
The current single-SVG approach with var(--primary), var(--secondary), and var(--tertiary) is still the clean/simple path for most sites, especially where the same SVG just needs to adapt its colours.
The use case I was exploring is the edge case where a dark-mode splash needs a genuinely different asset or optical treatment, rather than just recolouring the same SVG. For example, a logged-in dark header may work best with one transparent logo/background treatment, while the anonymous login/splash view may need a slightly different charcoal background or adjusted SVG for better contrast.
So the idea is not to replace the current variable-based approach, but to provide an escape hatch for sites where the dark splash artwork really does need to differ from the light/default splash artwork.
Feedback welcome on whether this belongs as a separate splash_screen_image_dark setting, or whether the existing single-SVG + colour-variable approach should remain the only supported route.
I initially tried to use animated SVG for the splash screen. While this works on desktop, I found that on mobile, animating complex paths or SVG-internal elements directly, results in lagging and even animation stopping.
To ensure a smooth experience, I shifted the animation logic to a standard HTML container (div) wrapped around the SVG. By applying the CSS animations (transform, scale, opacity) to the div wrapper instead of the SVG, mobile browsers can use hardware acceleration much more efficiently without lagging.
해당 함수를 애니메이션 WebP 형식으로 확장할 수 있는지, 아니면 CSS 변환에 엄격하게 종속되어 있는지 궁금합니다.
GIF 파일은 용량이 크지만, WebP는 요즘 손실 없는(무손실) 표준 형식으로 널리 사용되고 있습니다. 200x200px 크기의 15FPS 애니메이션을 5초 길이로 만들면 50/100kb 수준으로 압축됩니다. 루프를 2~3초로 줄이면 용량을 더 이상으로 줄일 수도 있습니다.
다크/라이트 모드 변형을 지원할 수 있을까요?
SVG를 변경할 때마다 업로드 중 UI에서 오류가 보고되지만, 실제로는 파일이 존재하며 정상적으로 작동합니다.
아까 제가 좀 멍청하게 굴어서 스스로 답글을 달았네요. SVG에서 Discourse의 색상 스킴 CSS 변수를 참조하기만 하면, 라이트/다크 모드에 필요한 애니메이션이 자동으로 렌더링됩니다.
크기에 대한 언급이 있었던 것 같아요. 스플래시 애니메이션을 좀 더 큰 버전으로 지원할 계획이 있나요?
애니메이션 주변의 빈 공간을 잘라내서, 더 큰 이미지의 인상을 줄 수 있기를 바랍니다.
