Blur on moving elements
After a few months of being gone, this started showing up for me again. Not sure why.
It seems that while an element is transitioning, it blurs, and sometimes doesn't unblur.
Only happens when zoomed in larger than 100%. Only happens on Chromium browsers. Does not seem to consistently happen with the same elements from session to session.
Tested with TJS 0.22 and Edge 112.0.1722.39. I expect its probably a change Chrome made to how it handles things, but wanted to document this here in case there is something to be done about it. Example in the attached gif.
11 Replies
Yeah... This is going to be a tricky situation to resolve. My general understanding is that browsers that are Chromium based are not going to necessarily have the same features / performance tuning / rendering performance across the board with Chrome. IE Chrome based on configuration can have different optimization paths enabled than other Chromium browsers. This aspect could explain the differences you see between Chrome & Edge.
I mainly only test w/ Chrome and then a bit w/ Firefox.
One thing that can help in this case is to create an independent example that runs on the Svelte REPL that shows the rendering flaw. It certainly doesn't hurt trolling through any of the public bug list on the Chromium project. I don't think there is anything public for the Edge browser. If you can isolate the problem with the minimal amount of code even if Svelte is involved then it makes it easier to post a bug on the Chromium tracker or even try to contact anyone w/ the Edge team.
Are you using any
svelte-standard components like TJSSvgFolder?
---
Not related, but we'll potentially see this configuration difference w/ the launch of Chrome 113 which is enabling WebGPU by default, but not all Chromium browsers may enable the same built in features in follow up releases.I use some svelte standard components, but none in this particular application. I'll see if I can get a more solid repro case
Let me know when you can throw up a Svelte REPL example and I'll take a look. This particular case could come down to hardware configuration vs a specific issue in browser support. Getting an idea if this is a common occurrence across hardware configurations would be the next step to verify. This takes into account your experience for instance w/ the past blurring issue where it existed on my setup, but was more subtle vs pronounced.
Not related: For instance now that Svelte supports container queries I will be coming up w/ a REPL example that showcases this assumed Firefox flaw: https://bugzilla.mozilla.org/show_bug.cgi?id=1805945 vs the current demo which is more complex and requires a checkout of a repo / build / run loop.
The less code and easy way to run it via the REPL is better for getting more eyes on the potential problem.
I have not been able to repro this in a repl, but after doing some reformatting of styles in the system, it seems like at least some of it is because of sub-pixel rendering.
I have been using rem size units, and apparently some of the sizes resulted in fractions of pixels (such as 0.9 rem coming out to 14.4 pixels).
From what research I have been able to glean, this works out in firefox because firefox renderer just ignores sub-pixels.
Chrome renderer however has no way to handle them, which results in this blur, and gets worse if you have multiple layers.
Switching to px measurements has dramatically reduced the problem.
It's worth updating to the latest TRL version
0.1.2 and svelte-standard to 0.1.0 if you are using it. 0.0.22 is rather old. I couldn't immediately find which version accounted for the willChange removal from TJSPosition usage for that Chrome deficiency. I'd also install the latest Vite 4, Svelte 4, and svelte-preprocess for v4.
It's a bit strange that you are mentioning this is related to Svelte transitions which is not something that TRL should be concerned about from the willChange Chrome issue. Check and see if you see any willChange values in the inline styles of the elements or app div. If you see that then update to the latest TRL, etc and try again.
Yeah.. As you have updated the above post it's not clear that this has anything particularly to do with TRL or even Svelte. Potentially a browser quirk that is aggravated by your particular hardware configuration.Had a bit of a breakthrough.
I had a component called
ScrollingContainer. It contained a container <div> set to relative, and then a child content <div> set to absolute, with overflow: set to scroll. Then content had a slot into which I would put content in the parent component.
The problem is that on Chrome, the content was being blurred.
As it turns out, if I do the same thing WITHOUT using a slot, it's perfectly sharp.
Kinda glad slots are going away in Svelte 5.
Literally, all I do is change
<slot>Scrolling Content</slot>
To
<svelte:component this={content}/>Again this is something super weird and must be a particular hardware configuration that you run as otherwise this would be a findable bug / issue on the Svelte repo and reported / confirmed by many. IE I can't see how slots and the backing implementation would cause blurring itself. So some weird hardware / Chrome combination is occurring occassionaly, but pointing to X (slots in this case) is likely not the problem. It is odd though that changing things to
svelte:component does work on your box.
What is actionable though is creating a demo of what causes blurring on your box in the Svelte REPL. Of course I can check it out and others too, but perhaps adding that Svelte REPL example to an existing Chromium bug that relates to this general issue is reasonable.I'll take another shot at getting it working in REPL, though I wonder if it might just go away with Svelte 5.
Will probably be a bit though, because we are on crunch time at work, and between that and running my game, I am super sleep deprived. 😛
No pressure for you to look into this of course, you have done more than enough! Just sharing my discoveries as they happen for the sake of future generations.
Yeah, it's definitely a tricky phantom bug / issue. TRL uses lots of slots and I've never seen a problem. It could be a combination of CSS that you use in combination w/ hardware / browser issues. Slots in and of themselves "shouldn't" be the issue per se, but could be a knock on effect with other aspects that cause things to go awry with your hardware / browser combination.
TRL
0.3.0 with a full conversion to Svelte 5 will only use snippets, so slots will be a thing of the past.I suspect it is some edge case where my particular css / html makes something bad happen,. And probably not Svelte or TRL's fault, given that it always worked in Firefox.
Heh heh... Time to upgrade the home dev box and then never see this class of issues again.. That is one way to make it go away. ;P