No, we don't always render at integer coordinates. If you place a control at 10,10 and disable pixel snapping, it'll end up at 12.5,12.5 (with 125% scaling) in render coordinates.
The process of coloring pixels on the output texture based on triangle polygons is called rasterization. For each pixel, the rasterizer determines whether it's inside of the polygon to be drawn. If the pixel is inside, it will be colored according to the output of a shader program; if it's not inside, it will be unaffected. More precisely, a pixel is inside of a polygon if its center point is inside of the polygon. So we do render at non-integer coordinates, but it's the Direct3D/OpenGL/etc. rasterization rules that decide whether or not a pixel will appear on the output texture. Regarding the PR: that's a solution for a different problem. On Tue, Sep 28, 2021 at 5:53 PM Marius Hanl <mariush...@web.de> wrote: > > Thanks for your reply. > > Does that mean that we will always render at a round number, e.g. 13, never > on a decimal number? > Because then I'm wondering how we can render at a decimal number given we > can't split a pixel. > > If this actually fixes the problem it might be worth a revisit. > Can I try this out as is? > If so and it actually fixes my problem/makes it a lot easier this PR will > probably get more attention and can benefit from it. >
