On Wed, 13 May 2020 12:29:03 GMT, Kevin Rushforth wrote:
>> I agree that these methods are better suited there, but I'm not sure the
>> same epsilon value will be suitable for other
>> places that will want to use these. That value is somewhat arbitrary anyway
>> I think.
>
> Either is fine
On Wed, 13 May 2020 00:38:03 GMT, Nir Lisker wrote:
>> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/MultiLoopClipEnvelope.java
>> line 48:
>>
>>> 47:
>>> 48: protected boolean autoReverse() {
>>> 49: return autoReverse;
>>
>> I would suggest the name to
On Wed, 13 May 2020 11:20:25 GMT, Jeanette Winzenburg
wrote:
>> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinDisposeContractTest.java
>> line 159:
>>
>>> 158: {TreeTableView.class, },
>>> 159: {TreeView.class, },
>>> 160: };
>>
>>
On Wed, 13 May 2020 23:42:40 GMT, Nir Lisker wrote:
>> If this were an even remotely representative use case, then no, the
>> performance hit would not be OK. The test was
>> designed as an artificial "worst-case" stress test: a single mesh with a
>> large number of very large (window-sized)
On Sat, 25 Apr 2020 17:07:21 GMT, Kevin Rushforth wrote:
> We should make sure that we aren't seeing any significant performance drop
> when rendering spheres (at a couple
> different tessellation levels) or boxes.
I missed this. Do you mean that the test should create a mesh of a sphere
On Thu, 7 May 2020 08:50:23 GMT, Ambarish Rapte wrote:
>> Mostly refactoring in preparation of the upcoming fixes. The changes might
>> look like a lot, but it's mostly rearranging
>> of methods. Summery of changes:
>> ### Animation
>> * Added `isNearZero` and `areNearEqual` methods that deal
On Wed, 13 May 2020 00:17:17 GMT, Nir Lisker wrote:
>> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/shared/ClipEnvelope.java
>> line 46:
>>
>>> 45: */
>>> 46: public abstract class ClipEnvelope {
>>> 47:
>>
>> I think the removal of line 46 was unintended change.
>
> I
On Wed, 13 May 2020 09:22:20 GMT, Rony G. Flatscher
wrote:
>> Doc addition for the CSR:
>> =
>> The following text was added to the [Introduction to
>>
> some skins have not been guarding themselves against multiple calls to
> dispose (see issue for details)
>
> Fixed by backing out off dispose if skinnable is null. Added test
> (parameterized in control class) for all controls in
> the controls package. Those that failed for the misbehaving
On Wed, 13 May 2020 10:09:40 GMT, Ambarish Rapte wrote:
>> Jeanette Winzenburg has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> cleanup
>>
>> - corrected incorrect bug id in commented
>> - removed unrelated test change from
On Tue, 12 May 2020 12:21:14 GMT, Ajit Ghaisas wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java
>> line 485:
>>
>>> 484: }
>>> 485:
>>> 486: if (focusedMenu != null && focusedMenuIndex != -1) {
>>
>> don't quite understand why this
On Fri, 8 May 2020 11:25:03 GMT, Jose Pereda wrote:
> There is a visual glitch when the scrollbar controls are laid out on touch
> enabled devices.
>
> The first time they are laid out in the wrong location (20 px from right or
> bottom), while the next passes are correct
> (8 px from right
On Mon, 11 May 2020 04:51:51 GMT, Ambarish Rapte wrote:
>> Jeanette Winzenburg has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> cleanup
>>
>> - corrected incorrect bug id in commented
>> - removed unrelated test change from
On Wed, 6 May 2020 11:46:27 GMT, Jeanette Winzenburg
wrote:
>> some skins have not been guarding themselves against multiple calls to
>> dispose (see issue for details)
>>
>> Fixed by backing out off dispose if skinnable is null. Added test
>> (parameterized in control class) for all
On Wed, 13 May 2020 09:38:23 GMT, Jose Pereda wrote:
>> There is a visual glitch when the scrollbar controls are laid out on touch
>> enabled devices.
>>
>> The first time they are laid out in the wrong location (20 px from right or
>> bottom), while the next passes are correct
>> (8 px from
On Wed, 6 May 2020 11:46:27 GMT, Jeanette Winzenburg
wrote:
>> some skins have not been guarding themselves against multiple calls to
>> dispose (see issue for details)
>>
>> Fixed by backing out off dispose if skinnable is null. Added test
>> (parameterized in control class) for all
On Wed, 13 May 2020 09:14:02 GMT, Ajit Ghaisas wrote:
>> Jose Pereda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Apply code formatting
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
> line
> There is a visual glitch when the scrollbar controls are laid out on touch
> enabled devices.
>
> The first time they are laid out in the wrong location (20 px from right or
> bottom), while the next passes are correct
> (8 px from right or bottom).
> The reason for this glitch is the use of
On Tue, 12 May 2020 17:33:06 GMT, Rony G. Flatscher
wrote:
>> Suggested CSR:
>>
>> Summary
>> ===
>> Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if
>> the script engine
>> implements the javax.script.Compilable interface to speed up execution. In
>> case
On Fri, 8 May 2020 11:25:03 GMT, Jose Pereda wrote:
> There is a visual glitch when the scrollbar controls are laid out on touch
> enabled devices.
>
> The first time they are laid out in the wrong location (20 px from right or
> bottom), while the next passes are correct
> (8 px from right
Having proper and consistent Multitouch support on all platforms is
certainly
an interesting goal, especially if your development is targeting a
mobile platform. If one
could test the input behavior already on the desktop, this would be an
enormous time saver because the turn-around times
> This WIP adds the ability for a fallback in case compilation of scripts
> fails, in which case a warning gets issued
> about this fact and evaluation of the script will be done without
> compilation. Because of the fallback scripts get
> compiled with this version by default. It extends PR 187
Hi John,
the model class used by your TableView is called “SimpleImmutableEntry”. The
middle part of this name should be enough to tell you what the problem is :-)
Solution: create your own custom model class and provide setters and getters
for “key” and “value”. Then the TableView will write
Nobody is biting... so is anyone else out there interested in using HID
touchscreens with JavaFX on OSX (or any other plaform) without using a
third party driver?
On Fri, May 8, 2020 at 4:18 AM jfx user2 wrote:
> Multitouch display support JavaFX on Windows, iOS, and Android seems
>
Turns out that I partially misunderstood the use of Path2D in
GraphicsContext. I had been using appendSVGPath for nearly everything and
within a single beginPath/closePath. Under those circumstances
converting GraphicsContext.path from Path2D to Path (using code from
25 matches
Mail list logo
