Totally Kai, I get that. I understand what you are saying and it makes perfect sense. I was just illustrating why this feature is useful, and pointing the fact that is very common in rendering. I am in fact surprised to see that it’s hardly a case considered in existing real-time APIs and the hardware, whereas it seems to be the most basic case (although I agree this is arguable). Jasper, I will edit my original post with an image to illustrate the problem. But the idea is that some glyphs are rendered right at the edge of the texture. And so those pixels get eventually duplicated.

…

On 6 May 2023, at 02:06, Kai Ninomiya ***@***.***> wrote: The difficulty here is that the actual behavior is out of our control. This is a hardware feature, and we only get the access provided by the underlying APIs Vulkan/Metal/D3D12. It's common in native APIs to have undefined behavior when you do things that aren't allowed - for example attempting to filter non-filterable texture formats, which is how we ended up inventing the "unfilterable"/"non-filtering" validation system in WebGPU. So in order to add this we would need a complete picture of when clamp-to-border is both (1) well-defined in each backend and (2) consistent across all backends, and a way to disallow any texture sampling that would cause undefined behavior. — Reply to this email directly, view it on GitHub <#1305 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A34XQORTPIGGRHJKBPPU3TTXEWIZPANCNFSM4U3JNCVA>. You are receiving this because you commented.

Resurrect clamp-to-border #1305

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions