I have tested on Linux (Fedora 31) only.
It works as intended (with one test failure due to 15-ea+4 being too old now).
UPDATE_STUB_CACHE suggests there is some magic available to help manage the
stub cache.
But as I could not find anything about it, that section in the documentation
may need
On Thu, 30 Apr 2020 18:56:40 GMT, Jesper Skov
wrote:
> I have tested on Linux (Fedora 31) only.
> It works as intended (with one test failure due to 15-ea+4 being too old now).
>
> UPDATE_STUB_CACHE suggests there is some magic available to help manage the
> stub cache.
> But as I could not
On Thu, 30 Apr 2020 18:56:40 GMT, Jesper Skov
wrote:
> I have tested on Linux (Fedora 31) only.
> It works as intended (with one test failure due to 15-ea+4 being too old now).
>
> UPDATE_STUB_CACHE suggests there is some magic available to help manage the
> stub cache.
> But as I could not
On Thu, 30 Apr 2020 20:10:19 GMT, Kevin Rushforth wrote:
>> I have tested on Linux (Fedora 31) only.
>> It works as intended (with one test failure due to 15-ea+4 being too old
>> now).
>>
>> UPDATE_STUB_CACHE suggests there is some magic available to help manage the
>> stub cache.
>> But as
On Thu, 30 Apr 2020 19:51:26 GMT, Kevin Rushforth wrote:
>> I have tested on Linux (Fedora 31) only.
>> It works as intended (with one test failure due to 15-ea+4 being too old
>> now).
>>
>> UPDATE_STUB_CACHE suggests there is some magic available to help manage the
>> stub cache.
>> But as
if this is confirmed I can update the page.
On Tue, Apr 14, 2020 at 1:18 PM Florian Kirmaier
wrote:
> Hi everyone,
>
> it seems to me, that the newest JDK for Mac (MacOSX10.15.sdk) doesn't work
> to build JavaFX.
> It works for me with 10.14 but not with 10.15.
> Can anyone confirm this?
> It
I would say that for doubles, the minimum step size is the one given by ulp
= Math.ulp(double). Then the double case should behave like the
integer case where the ulp is 1 I think.
So, for the angle case of [0, 360), if we are at 360 - ulp, incrementing by
N * ulp will get us to (N-1) * ulp.
On
They're related. 32767x1137x4 = 149024316.
It would help to know what your app might be doing. Although it could
be a bug in JavaFX, it seems more likely that a canvas/image or cached
group or something is a bit bigger than reasonable.
I think I've seen such errors in my app before I
On 5/10/20 3:52 PM, John Hendrikx wrote:
They're related. 32767x1137x4 = 149024316.
It would help to know what your app might be doing. Although it could
be a bug in JavaFX, it seems more likely that a canvas/image or cached
group or something is a bit bigger than reasonable.
I think
On 5/7/20 3:44 PM, Kevin Rushforth wrote:
This suggests that there might be a memory leak (possibly in uploading
painter which I see you are using). Is this easily reproducible?
I tried doing software rendering just to see if it made any difference.
I don't know if it fixed any of the
> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp
> in WebKit was not implemented, so masking
> doesn't take place at all while rendering SVGRect. to fix this issue add
> implementation of function clipToImageBuffer()
> in GraphicsContextJava.cpp and send clip image
> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp
> in WebKit was not implemented, so masking
> doesn't take place at all while rendering SVGRect. to fix this issue add
> implementation of function clipToImageBuffer()
> in GraphicsContextJava.cpp and send clip image
On Fri, 8 May 2020 18:50:57 GMT, Kevin Rushforth wrote:
>> I wasn't aware of PR #73, I only saw the (very old) issue in the JDK Bug
>> System and started to look into the issue.
>> The fact that two different people start to look into the same issue shows
>> it is important however :-).
>>
On Fri, 8 May 2020 23:37:51 GMT, Kevin Rushforth wrote:
>> Bhawesh Choudhary has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Moved Printing drawing path to non MaskTextureGraphics interface
>
>
On Fri, 1 May 2020 14:42:34 GMT, Kevin Rushforth wrote:
>> Ambarish Rapte has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review-update: change test name
>
>
> Issue:
> When tabs are permuted as mentioned in the issue description as,
> 1. TabPane.getTabs().setAll(tab0, tab1)
> 2. TabPane.getTabs().setAll(tab0, tab1, tab2, tab3);
> the tab headers do not get permuted in same order as `TabPane.getTabs()`.
>
> => tab headers should be shown in order as
On Fri, 24 Apr 2020 00:58:30 GMT, Nir Lisker 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 with
On Fri, 8 May 2020 23:25:18 GMT, Kevin Rushforth wrote:
>> Bhawesh Choudhary has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Moved Printing drawing path to non MaskTextureGraphics interface
>
>
On Wed, 6 May 2020 20:37:10 GMT, Kevin Rushforth wrote:
> This is a toolchain upgrade on Windows from the current Visual Studio 2017
> (version 15.9.16) to Visual Studio 2019
> (version 16.5.3). This will match a recent upgrade done for JDK 15 -- see
>
19 matches
Mail list logo
