On Tue, 1 Sep 2026 16:02:21 GMT, Michael Strauß <[email protected]> wrote:
>>> I wonder, why do we even need the unsnapped setting? what is the use case? >> >> That is something I always asked myself as well. > >> * HBox 2 (snapped) gets 10.25 pixels >> * Child 1 gets 5 pixels >> * Child 2 gets 5 pixels >> * (empty space within border of 0.25 pixels) >> * Empty space location determined by alignment >> * LEFT: C1 C2 (0.25) >> * CENTER: (0.125) C1 C2 (0.125) >> * RIGHT: (0.25) C1 C2 > > It can't possibly work like that. You have a snapped HBox that is allocated > 10.25 pixels. Now, each of the two children must be allocated 5 pixels, as > otherwise they will be off-grid. If you allocate 5.0 pixels to C1, and 5.25 > pixels to C2, then the latter will be off-grid at its right edge. > > The remainder of 0.25 pixels can't possibly be anywhere else but at the right > edge of the allocated space: > 1. If the remainder is at the left edge of the allocation, then both children > will be offset 0.25 pixels relative to the grid. > 2. If it is between the children, then the left child will be aligned, but > the right child will be offset. > 3. This leaves the right edge as the only place where to insert the remainder. > > What confuses me is the following: You argue that we should just accept the > allocation that we receive from the parent. But then you also say that a > small portion of empty space should be inserted when the children can't fill > the allocation. I can't help but see a contradiction here. We can only choose > between two options: > > 1. A layout container accepts the allocation it has received, and lays out > its children so the assigned allocation is perfectly honored. If the > allocation is not snapped, this inevitably means that at least one child > can't be perfectly aligned to the grid. In the HBox scenario, it means that > we can perfectly align all children but the last, which needs to be that 0.25 > pixels wider in order to perfectly fill the allocation. > 2. Alternatively, we don't accept the allocation that was given to us, but > instead snap the allocation to the pixel grid. Only then will be be able to > perfectly align the children within that allocation. > I wonder, why do we even need the unsnapped setting? what is the use case? In theory, with a sufficiently high-DPI display, you don't need pixel snapping at all. The number of photons emitted from a perfectly-aligned hairline, and a hairline that straddles a pixel boundary, is the same. The only difference is that in the latter case, the photons are emitted from a more spread-out area. But once your DPI is so high that you can't see a difference between the two, there's no need for snapping. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2262#discussion_r3906042529
