-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sprite atlas bleeding with blade renderer #12352
Comments
I think this may be related to #11056 (probably the same cause), though the issues described are a bit different. This is one of the more extreme cases I got while using Zed: |
i am having this issue as well |
I'm not able to see it on my platform. It would help to get a GPU capture with RenderDoc and share it somewhere. |
Thanks for the reply. I've used RenderDoc to generate two different captures (one at 100% scaling and another at 125%, where the issue is clearer). |
Awktually, a better idea - it's caused by incomplete handling (in gpui) of the fractional scaling. MacOS users/devices tend to not use/enable it as much, I suppose, hence the issue wasn't detected earlier. |
But it also happens when display scale is 100%? My initial guess was that vulkan and metal sample textures differently (0,0 at the corner of the pixel vs in the center of it) but I haven't had time to dig into whether that is the case. |
No, the pixel center logic is exactly the same between them, this shouldn't be a difference here (for context, the only API where it's different is DX9). Do you have a RenderDoc capture with 100% scaling by any chance? My expectation is that all coordinates that the vertex shaders operate on would be exactly on the pixel boundaries in this case. For example, in "bleeding_125scaling" capture that @apricotbucket28 provided, I see Y vertex output absolute coordinates being The exact data is coming from |
Related to #12352 (and old issue #643) This fixes visual glitches that could happen when rendering icons on Linux and Windows (and in the Blade backend) ![image](https://github.com/user-attachments/assets/02646d1d-d35b-48be-89c9-189416510cf2) ![image](https://github.com/user-attachments/assets/ccf99867-25d2-40fb-8735-c540f8cf793a) ![image](https://github.com/user-attachments/assets/8d1124a3-669e-4be5-8b46-5dc2df14a28a) Release Notes: - Linux: Fixed visual glitches when rendering icons.
I think I see what's happening in there. The layout is done in the coordinate system that doesn't match the screen. All coordinates get multiplied by let scale_factor = self.scale_factor();
let bounds = bounds.scale(scale_factor); In the content coordinates, we have primitives that are placed on the edge of the pixels. After multiplication, we get coordinates that end with .0, .25, .5, and .75. Before these go into the But that's only half of the problem. Even if ".5" was rasterized consistently, we'd still have another problem: if the pixel center happens to be too close to the primitive boundary, then the interpolated texture coordinate at this pixel will be too close to the atlas region boundary. Therefore, sampling this texel linearly will include the neighbors.
|
More concretely, here is a solution I'm thinking:
|
Sounds like that might actually fix the squiggly lines changing with display scale too! |
Thanks for looking into this! My knowledge with graphics is little to none, and what you're describing seems like a much better solution. |
This is now included in today's |
Check for existing issues
Describe the bug / provide steps to reproduce it
Sporadically appears and disappears. May appear in one window but not another within the same Zed instance. Similar to #643
Environment
Zed: v1.0.0 (Zed Dev e19339b)
OS: Linux 1.0.0
Memory: 30.9 GiB
Architecture: x86_64
If applicable, add mockups / screenshots to help explain present your vision of the feature
No response
If applicable, attach your
~/Library/Logs/Zed/Zed.log
file to this issue.No response
The text was updated successfully, but these errors were encountered: