Re: RFR: [WIP] 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v6]
On Mon, 23 May 2022 20:44:47 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked >> without having a layout calculation in between, the old (wrong) size is used >> to calculcate the total estimate. This happens e.g. when the size is changed >> in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache >> containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional > commit since the last revision: > > Try to keep visible cells at their original position when improving the > estimate. > This reduces annoying effects when re-layouting cells without relevant > changes. > > This should not be done when we don't have a valid estimate yet/anymore, > or when the absoluteOffset is set to infinity (which may happen if the > position is set to infinity, which is the case in some calls in Skin > classes). To give some background: the reason for this PR is to fix (real or perceived) regression after https://bugs.openjdk.java.net/browse/JDK-8089589 was fixed. The original problem was this: in case a ListView contains items with different heights, the scrollbar can show weird jumps as it considers all cells to have the same height. The "easy" solution to this would be to pre-calculate the height of all cells, but that would be a potential performance issue. The approach taken in JDK-8089589 is to gradually improve the information about the different sizes of the cells, and it fixes the weird jumps (at the very least, it avoids jumping upwards when scrolling down and vice versa). However, this gradual improvements can cause other visual disturbances. Initially, we improved the parameters whenever a layoutChildren was invoked. However, this leads to undesired effects in case layoutChildren is invoked again after a specific goal is asked (e.g. scroll to a cell with a specific index). A consequence of the gradual improvement is that the algorithm realizes the first cell need to move upwards or downwards a bit, but that will destroy the state where a cell should be positioned exactly at a given position. The latest commit fixes this, by modifying the parameters (absoluteOffset and position) in such a way that they lead to improvements, yet keep the visible cells intact. This broke a number of tests, as there are cases where keeping these cells intact is not what we want. When there is no cached estimate, or when the absoluteOffset has a bogus value, we do not want to maintain the previous situation. I'm moving this PR to draft until I have more confirmation about the (perceived) stability. - PR: https://git.openjdk.java.net/jfx/pull/712
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v6]
> When the size of a ListCell is changed and a scrollTo method is invoked > without having a layout calculation in between, the old (wrong) size is used > to calculcate the total estimate. This happens e.g. when the size is changed > in the `updateItem` method. > This PR will immediately resize the cell and sets the new value in the cache > containing the cellsizes. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Try to keep visible cells at their original position when improving the estimate. This reduces annoying effects when re-layouting cells without relevant changes. This should not be done when we don't have a valid estimate yet/anymore, or when the absoluteOffset is set to infinity (which may happen if the position is set to infinity, which is the case in some calls in Skin classes). - Changes: - all: https://git.openjdk.java.net/jfx/pull/712/files - new: https://git.openjdk.java.net/jfx/pull/712/files/aa08ba26..c7d722d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=712=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx=712=04-05 Stats: 121 lines in 2 files changed: 75 ins; 29 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/712/head:pull/712 PR: https://git.openjdk.java.net/jfx/pull/712
Integrated: JDK-8286256 : Update libxml2 to 2.9.14
On Tue, 17 May 2022 12:32:17 GMT, Hima Bindu Meda wrote: > Updated libxml to version 2.9.14.As mentioned in UPDATING.txt, configured for > windows , linux and Mac platforms and updated the files accordingly. > > Updated libxslt to version 1.1.35. Generated the config.h files for windows , > Mac and linux platforms and updated accordingly. > > Verified the build on all the platforms and sanity testing looks fine.No > regressions observed. This pull request has now been integrated. Changeset: d6770034 Author:Hima Bindu Meda Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/d6770034a66a294b8740875c28871f2b4677aef2 Stats: 21664 lines in 81 files changed: 4429 ins; 4294 del; 12941 mod 8286256: Update libxml2 to 2.9.14 8286257: Update libxslt to 1.1.35 Reviewed-by: kcr, jvos - PR: https://git.openjdk.java.net/jfx/pull/797
Re: RFR: JDK-8286256 : Update libxml2 to 2.9.14 [v4]
On Wed, 18 May 2022 13:39:12 GMT, Hima Bindu Meda wrote: >> Updated libxml to version 2.9.14.As mentioned in UPDATING.txt, configured >> for windows , linux and Mac platforms and updated the files accordingly. >> >> Updated libxslt to version 1.1.35. Generated the config.h files for windows >> , Mac and linux platforms and updated accordingly. >> >> Verified the build on all the platforms and sanity testing looks fine.No >> regressions observed. > > Hima Bindu Meda has updated the pull request incrementally with one > additional commit since the last revision: > > Space correction works with our new build approach. - Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/797
Re: @font-face question
Hi,
After further investigation, I think there's a bug that font-family is not
working (defining a font family name).
Because regardless of the font-family I use, the font name within the font
is used.
It's openjfx 17.0.2
-- Thiago.
Em sex., 20 de mai. de 2022 às 18:06, Thiago Milczarek Sayão <
thiago.sa...@gmail.com> escreveu:
> Hi,
>
> I want to have one font that is "regular" and a variation of the same font
> as "bold", used when specified "-fx-font-weight: bold".
>
> @font-face {
> font-family: 'Gotham Condensed';
> src: url('../fonts/GothamCondensed-Book.otf');
> }
>
> @font-face {
> font-family: 'Gotham Condensed Bold';
> src: url('../fonts/GothamCondensed-Bold.otf');
> }
>
>
> .text {
> -fx-font-family: 'Gotham Condensed';
> }
>
> I have searched online and there are many variations such as:
>
> - @font-face "font-family" is ignored and you have to use the real font
> name;
> - If you use 'Bold' as a suffix, javafx will use it as bold;
> - you have to specify "font-weight: bold" on the @font-face
>
> The last one is what seems that the CSS specs says, but does not seem to
> work.
>
> Is it possible?
>
> Thanks.
>
>
