Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I'd also like to point out that if you are rounding in your rendering anywhere, you are now likely either introducing blurriness again, or something is getting scaled incorrectly.

Some things will be blurry, but no worse than having the compositor do it. Other things will not be blurry, and that's a huge huge benefit.

> artifacts or error build-up

Integer multiples risk artifacts too, if the program is actually supposed to be rendering in high resolution. Error build-up I'm not sure should be a big worry when you can have 53 bits of precision for a window a couple thousand pixels across.

> As you describe, this is the "easily solved" way

I'm not sure you understood what I meant. I was saying that when possible the compositor should round the window to the nearest pixel, then have the client render at that resolution, so then the compositor would not do any scaling at all.



>Some things will be blurry, but no worse than having the compositor do it. Other things will not be blurry, and that's a huge huge benefit.

This is the same trade-off as you would get without it.

The precision isn't an issue, the error build-up is with rounding and it becomes particularly problematic when you have subsurfaces.

As I have said in another sibling comment, if you don't want the compositor to do any scaling, then don't enable scaling in the compositor.


> This is the same trade-off as you would get without it.

Using the compositor method makes everything blurry. It's not the same trade-off.

> then don't enable scaling in the compositor.

Turning up the font size as you suggested is not at all a proper solution.

I want to pass fractional scaling on to the program whenever possible. If it can't handle it, then 2x followed by shrinking can be the fallback.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: