On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
On Wed, 29 Mar 2023 17:31:42 GMT, Michael Strauß wrote:
>>> > @andy-goryachev-oracle raises a good point about perhaps wanting to solve
>>> > this in a similar way for the various places where we need to do some
>>> > sort of iterative adjustment (such as here and in the eventual solution
>>>
On Wed, 29 Mar 2023 17:31:42 GMT, Michael Strauß wrote:
>>> > @andy-goryachev-oracle raises a good point about perhaps wanting to solve
>>> > this in a similar way for the various places where we need to do some
>>> > sort of iterative adjustment (such as here and in the eventual solution
>>>
On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
On Wed, 26 Apr 2023 18:37:20 GMT, Andy Goryachev wrote:
> > The min/max values are not strictly honored when snapping is on, they're
> > snapped first.
>
> [question]
>
> Here is a general question: in the case when min==max, in which direction
> should we snap? Could this question be answere
On Tue, 25 Apr 2023 18:38:43 GMT, John Hendrikx wrote:
> The min/max values are not strictly honored when snapping is on, they're
> snapped first.
[question]
Here is a general question: in the case when min==max, in which direction
should we snap? Could this question be answered all the time
On Wed, 29 Mar 2023 17:31:42 GMT, Michael Strauß wrote:
>>> > @andy-goryachev-oracle raises a good point about perhaps wanting to solve
>>> > this in a similar way for the various places where we need to do some
>>> > sort of iterative adjustment (such as here and in the eventual solution
>>>
On Tue, 25 Apr 2023 17:55:20 GMT, Andy Goryachev wrote:
> > It's logical width can take on any multiple of the physical pixel size
> > divided by the render scale, which is 1 / 1.5 = 0.66.
>
> No it cannot. Snapping imposes limitation on which logical coordinates are
> acceptable. What's more,
On Tue, 25 Apr 2023 07:49:29 GMT, John Hendrikx wrote:
> It's logical width can take on any multiple of the physical pixel size
> divided by the render scale, which is 1 / 1.5 = 0.66.
No it cannot. Snapping imposes limitation on which logical coordinates are
acceptable. What's more, the dist
On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
On Mon, 24 Apr 2023 18:05:50 GMT, Andy Goryachev wrote:
> Perhaps i did not emphasized one thing: I believe single pass algorithms
> would not work when all of the following are true:
>
> * min/max constraint(s)
> * grow property(ies) are set
> * fractional scale
> * snapping
>
> But then agai
On Mon, 24 Apr 2023 17:52:59 GMT, John Hendrikx wrote:
> I'm sorry, I don't quite see what you mean here, perhaps this is unique to
> the TableView layout.
It is not unique. The scenario I am trying to describe is when set[VH]Grow is
true, possibly for multiple nodes. With the fractional sca
On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
On Mon, 24 Apr 2023 16:30:02 GMT, Andy Goryachev wrote:
> > I think a single pass algorithm should be possible.
>
> In some simple cases, yes. But not in all possible cases.
>
> Let's consider one example, a layout similar to
> TableView.CONSTRAINED_RESIZE_POLICY_ALL_COLUMNS. When we need to d
On Sat, 22 Apr 2023 09:38:46 GMT, John Hendrikx wrote:
> I think a single pass algorithm should be possible.
In some simple cases, yes. But not in all possible cases.
Let's consider one example, a layout similar to
TableView.CONSTRAINED_RESIZE_POLICY_ALL_COLUMNS. When we need to distribute
On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
On Wed, 29 Mar 2023 17:31:42 GMT, Michael Strauß wrote:
>>> > @andy-goryachev-oracle raises a good point about perhaps wanting to solve
>>> > this in a similar way for the various places where we need to do some
>>> > sort of iterative adjustment (such as here and in the eventual solution
>>>
On Wed, 29 Mar 2023 21:01:30 GMT, John Hendrikx wrote:
> > Thank you very much @hjohn for your extensive review. Before addressing
> > your comments, I'd like to get some clarification (ideally also from
> > @kevinrushforth), because I am a bit confused by the discussion so far.
If we can reso
On Wed, 29 Mar 2023 10:20:12 GMT, John Hendrikx wrote:
>>> @andy-goryachev-oracle raises a good point about perhaps wanting to solve
>>> this in a similar way for the various places where we need to do some sort
>>> of iterative adjustment (such as here and in the eventual solution for
>>> JDK
On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
On Wed, 29 Mar 2023 10:20:12 GMT, John Hendrikx wrote:
>>> @andy-goryachev-oracle raises a good point about perhaps wanting to solve
>>> this in a similar way for the various places where we need to do some sort
>>> of iterative adjustment (such as here and in the eventual solution for
>>> JDK
On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
On Wed, 29 Mar 2023 07:33:19 GMT, Marius Hanl wrote:
> > @andy-goryachev-oracle raises a good point about perhaps wanting to solve
> > this in a similar way for the various places where we need to do some sort
> > of iterative adjustment (such as here and in the eventual solution for
> > JDK-8
On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
On Thu, 16 Mar 2023 19:41:07 GMT, Kevin Rushforth wrote:
> @andy-goryachev-oracle raises a good point about perhaps wanting to solve
> this in a similar way for the various places where we need to do some sort of
> iterative adjustment (such as here and in the eventual solution for
> JDK-82997
On Thu, 16 Mar 2023 19:19:06 GMT, Andy Goryachev wrote:
>> Michael Strauß has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 12 commits:
>>
>> - changes per review
>> - Merge branch 'master' into fixes/box-snap-to-pixel
>>
>>
On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
On Thu, 16 Mar 2023 19:15:25 GMT, Andy Goryachev wrote:
>> Michael Strauß has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 12 commits:
>>
>> - changes per review
>> - Merge branch 'master' into fixes/box-snap-to-pixel
>>
>>
On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
On Wed, 22 Sep 2021 18:48:13 GMT, Marius Hanl wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> boun
On Tue, 5 Jul 2022 22:16:55 GMT, Michael Strauß wrote:
>> Michael Strauß has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - revert snappedSum
>> - don't call snappedSum in hot loop
>
> I've expanded the documentation of the improved algo
> The children of HBox/VBox don't always pixel-snap to the same value as the
> container itself when a render scale other than 1 is used. This can lead to a
> visual glitch where the content bounds don't line up with the container
> bounds. In this case, the container will extend beyond its cont
On Sun, 11 Sep 2022 21:10:50 GMT, Marius Hanl wrote:
>> Michael Strauß has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 10 commits:
>>
>> - Merge branch 'openjdk:master' into fixes/box-snap-to-pixel
>> - revert snappedSum
>> - d
On Fri, 8 Jul 2022 23:12:50 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
> The children of HBox/VBox don't always pixel-snap to the same value as the
> container itself when a render scale other than 1 is used. This can lead to a
> visual glitch where the content bounds don't line up with the container
> bounds. In this case, the container will extend beyond its cont
On Sun, 3 Jul 2022 15:01:19 GMT, Michael Strauß wrote:
>> The children of HBox/VBox don't always pixel-snap to the same value as the
>> container itself when a render scale other than 1 is used. This can lead to
>> a visual glitch where the content bounds don't line up with the container
>> bo
> The children of HBox/VBox don't always pixel-snap to the same value as the
> container itself when a render scale other than 1 is used. This can lead to a
> visual glitch where the content bounds don't line up with the container
> bounds. In this case, the container will extend beyond its cont
> The children of HBox/VBox don't always pixel-snap to the same value as the
> container itself when a render scale other than 1 is used. This can lead to a
> visual glitch where the content bounds don't line up with the container
> bounds. In this case, the container will extend beyond its cont
> The children of HBox/VBox don't always pixel-snap to the same value as the
> container itself when a render scale other than 1 is used. This can lead to a
> visual glitch where the content bounds don't line up with the container
> bounds. In this case, the container will extend beyond its cont
42 matches
Mail list logo
