Re: Re: JavaFX snapping and scale
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 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. >
Re: [External] : Aw: Re: JavaFX snapping and scale
By the time it is rendered, it will be transformed into the scaled space. So the actual coordinate in screen space will be 13. -- Kevin On 10/1/2021 7:26 AM, Marius Hanl wrote: Thanks for your answer. Then one more question: How is a non-integer value rendered then? Say we have snapped x value of 10.4 (scale 1.25). As we can just render on a whole pixel, what will happen? - Marius *Gesendet:* Dienstag, 28. September 2021 um 01:57 Uhr *Von:* "Kevin Rushforth" *An:* openjfx-dev@openjdk.java.net *Betreff:* Re: JavaFX snapping and scale The basic idea behind snapping to pixel boundaries (which is optional, but on by default) is that 2D primitives will look more crisp if they are rendered on whole pixel boundaries. When there is no HiDPI involved, the operation of snapping to a pixel boundary can be done with a simple floor, round, or ceil operation (depending on what you are snapping). When there is a HIDPI scale involved, the value in user space needs to be chosen such that the transformed value ends up on a pixel boundary. That's why you will see snapped values that aren't on integer boundaries when the HiDPI scale is, say 1.25. In the case you ran into, the problem might be that the snapping isn't happening in the right place in the computation. Also, it seems quite possible that the clipping isn't being calculated correctly with respect to pixel snapping. You can take a look at JDK-8211294 [1] which was fixed by PR #308 [2] for a recent example of a HiDPI bug affecting ScrollPane that was fixed. There are a couple of follow-on issues that came out of that issue, although I suspect they aren't relevant to the bug you are looking at. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8211294 <https://bugs.openjdk.java.net/browse/JDK-8211294> [2] https://github.com/openjdk/jfx/pull/308 <https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/308__;!!ACWV5N9M2RV99hQ!YDG10_6aLWHF6oDpo3JIKfgBDwkjcbFb75u8jaIuZp0zCY0tmAExinA93yn4H6gdZzIT$> On 9/27/2021 2:41 AM, Marius Hanl wrote: > I recently tried to fix "TableView: visual glitch at borders on > horizontal scrolling". > Ticket: [1]https://bugs.openjdk.java.net/browse/JDK-8218745 <https://bugs.openjdk.java.net/browse/JDK-8218745> > PR: [2]https://github.com/openjdk/jfx/pull/630 <https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/630__;!!ACWV5N9M2RV99hQ!YDG10_6aLWHF6oDpo3JIKfgBDwkjcbFb75u8jaIuZp0zCY0tmAExinA93yn4H8fP3AKI$> > > As also written in the PR I have problems understanding the > snapping/scaling of JavaFX. > Here in short what I found out: > - Snapping fixed the issue for a scale of 1 or 2, but not for a scale > like 1.25 or 1.5 > --- Also VirtualFlow is the only occurence where we set the layoutX of > a clip (might be the problem?) > - This visual glitch only happens sometimes when the x value is a > decimal number, e.g. 12.66 (never when it's a round number like 13) > - Math.round(..) or a cast to int fixed this (for all scales), but is > probably not the correct solution or maybe only fixing a symptom here > > Which leads to my question where may some of you can help me: > - How does JavaFX renders a node when e.g. x is a decimal number? How > many pixel are used then? > - And does a decimal number make sense (Why we e.g. don't round the > value), which looks like it works fine and doesn't result in visual > glitches > > Also information/insights about fixes made in the past which relates > with this are welcome. > I saw that there were quite some issues with a scale other then 1 in > the past. > > Note: If the result is that everything works as expected chances are > there might a generic problem with snapping/layout/rendering somewhere > then. > Any information are welcome and feel free to also have a look at the > PR. > > -- Marius > > References > > 1. https://bugs.openjdk.java.net/browse/JDK-8218745 <https://bugs.openjdk.java.net/browse/JDK-8218745> > 2. https://github.com/openjdk/jfx/pull/630 <https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/630__;!!ACWV5N9M2RV99hQ!YDG10_6aLWHF6oDpo3JIKfgBDwkjcbFb75u8jaIuZp0zCY0tmAExinA93yn4H8fP3AKI$>
Aw: Re: JavaFX snapping and scale
Thanks for your answer. Then one more question: How is a non-integer value rendered then? Say we have snapped x value of 10.4 (scale 1.25). As we can just render on a whole pixel, what will happen? - Marius Gesendet: Dienstag, 28. September 2021 um 01:57 Uhr Von: "Kevin Rushforth" An: openjfx-dev@openjdk.java.net Betreff: Re: JavaFX snapping and scale The basic idea behind snapping to pixel boundaries (which is optional, but on by default) is that 2D primitives will look more crisp if they are rendered on whole pixel boundaries. When there is no HiDPI involved, the operation of snapping to a pixel boundary can be done with a simple floor, round, or ceil operation (depending on what you are snapping). When there is a HIDPI scale involved, the value in user space needs to be chosen such that the transformed value ends up on a pixel boundary. That's why you will see snapped values that aren't on integer boundaries when the HiDPI scale is, say 1.25. In the case you ran into, the problem might be that the snapping isn't happening in the right place in the computation. Also, it seems quite possible that the clipping isn't being calculated correctly with respect to pixel snapping. You can take a look at JDK-8211294 [1] which was fixed by PR #308 [2] for a recent example of a HiDPI bug affecting ScrollPane that was fixed. There are a couple of follow-on issues that came out of that issue, although I suspect they aren't relevant to the bug you are looking at. -- Kevin [1] [1]https://bugs.openjdk.java.net/browse/JDK-8211294 [2] [2]https://github.com/openjdk/jfx/pull/308 On 9/27/2021 2:41 AM, Marius Hanl wrote: > I recently tried to fix "TableView: visual glitch at borders on > horizontal scrolling". > Ticket: [1][3]https://bugs.openjdk.java.net/browse/JDK-8218745 > PR: [2][4]https://github.com/openjdk/jfx/pull/630 > > As also written in the PR I have problems understanding the > snapping/scaling of JavaFX. > Here in short what I found out: > - Snapping fixed the issue for a scale of 1 or 2, but not for a scale > like 1.25 or 1.5 > --- Also VirtualFlow is the only occurence where we set the layoutX of > a clip (might be the problem?) > - This visual glitch only happens sometimes when the x value is a > decimal number, e.g. 12.66 (never when it's a round number like 13) > - Math.round(..) or a cast to int fixed this (for all scales), but is > probably not the correct solution or maybe only fixing a symptom here > > Which leads to my question where may some of you can help me: > - How does JavaFX renders a node when e.g. x is a decimal number? How > many pixel are used then? > - And does a decimal number make sense (Why we e.g. don't round the > value), which looks like it works fine and doesn't result in visual > glitches > > Also information/insights about fixes made in the past which relates > with this are welcome. > I saw that there were quite some issues with a scale other then 1 in > the past. > > Note: If the result is that everything works as expected chances are > there might a generic problem with snapping/layout/rendering somewhere > then. > Any information are welcome and feel free to also have a look at the > PR. > > -- Marius > > References > > 1. [5]https://bugs.openjdk.java.net/browse/JDK-8218745 > 2. [6]https://github.com/openjdk/jfx/pull/630 References 1. https://bugs.openjdk.java.net/browse/JDK-8211294 2. https://github.com/openjdk/jfx/pull/308 3. https://bugs.openjdk.java.net/browse/JDK-8218745 4. https://github.com/openjdk/jfx/pull/630 5. https://bugs.openjdk.java.net/browse/JDK-8218745 6. https://github.com/openjdk/jfx/pull/630
Re: JavaFX snapping and scale
The basic idea behind snapping to pixel boundaries (which is optional, but on by default) is that 2D primitives will look more crisp if they are rendered on whole pixel boundaries. When there is no HiDPI involved, the operation of snapping to a pixel boundary can be done with a simple floor, round, or ceil operation (depending on what you are snapping). When there is a HIDPI scale involved, the value in user space needs to be chosen such that the transformed value ends up on a pixel boundary. That's why you will see snapped values that aren't on integer boundaries when the HiDPI scale is, say 1.25. In the case you ran into, the problem might be that the snapping isn't happening in the right place in the computation. Also, it seems quite possible that the clipping isn't being calculated correctly with respect to pixel snapping. You can take a look at JDK-8211294 [1] which was fixed by PR #308 [2] for a recent example of a HiDPI bug affecting ScrollPane that was fixed. There are a couple of follow-on issues that came out of that issue, although I suspect they aren't relevant to the bug you are looking at. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8211294 [2] https://github.com/openjdk/jfx/pull/308 On 9/27/2021 2:41 AM, Marius Hanl wrote: I recently tried to fix "TableView: visual glitch at borders on horizontal scrolling". Ticket: [1]https://bugs.openjdk.java.net/browse/JDK-8218745 PR: [2]https://github.com/openjdk/jfx/pull/630 As also written in the PR I have problems understanding the snapping/scaling of JavaFX. Here in short what I found out: - Snapping fixed the issue for a scale of 1 or 2, but not for a scale like 1.25 or 1.5 --- Also VirtualFlow is the only occurence where we set the layoutX of a clip (might be the problem?) - This visual glitch only happens sometimes when the x value is a decimal number, e.g. 12.66 (never when it's a round number like 13) - Math.round(..) or a cast to int fixed this (for all scales), but is probably not the correct solution or maybe only fixing a symptom here Which leads to my question where may some of you can help me: - How does JavaFX renders a node when e.g. x is a decimal number? How many pixel are used then? - And does a decimal number make sense (Why we e.g. don't round the value), which looks like it works fine and doesn't result in visual glitches Also information/insights about fixes made in the past which relates with this are welcome. I saw that there were quite some issues with a scale other then 1 in the past. Note: If the result is that everything works as expected chances are there might a generic problem with snapping/layout/rendering somewhere then. Any information are welcome and feel free to also have a look at the PR. -- Marius References 1. https://bugs.openjdk.java.net/browse/JDK-8218745 2. https://github.com/openjdk/jfx/pull/630
