On Fri, 9 Oct 2020 01:06:54 GMT, Kevin Rushforth wrote:
>> It seems that many people are interested, so I pushed the change.
>> I don't understand how to proceed with the review on Github correctly, so if
>> I have anything to do, please comment.
>>
>> java
>> for(int to=cu
> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Addressed review comments
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/43/files
- new: https://git.open
On Thu, 8 Oct 2020 22:21:06 GMT, Kevin Rushforth wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Change range after clamping
>
> modules/javafx.graphics/src/main/native-prism-d3d/D3DLight.cc line 64:
>
>> 62: }
>> 6
On Thu, 8 Oct 2020 22:20:17 GMT, Kevin Rushforth wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Change range after clamping
>
> modules/javafx.graphics/src/main/native-prism-d3d/D3DLight.cc line 49:
>
>> 47: at
On Wed, 7 Oct 2020 21:14:14 GMT, yosbits
wrote:
>> **The next implementation will probably have a good balance between space
>> and time.**
>> Unless you do something like delete the even or odd indexes
>> The space efficiency is very high.
>>
>> Currently being tested.
>>
>> Java
>> @Ov
On Thu, 8 Oct 2020 22:08:16 GMT, Kevin Rushforth wrote:
>> In that case, it seems like a generally useful optimization (not just at
>> initialization) to send down `maxRange` as 0
>> whenever `ca`, `la`, and `qa` are all at their default values.
>
> Actually, my above comment is wrong. A `maxRan
On Thu, 24 Sep 2020 02:46:31 GMT, Nir Lisker wrote:
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264
>
> Nir Lisker has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Change range after clamping
tests/system/src/test/java/test/javafx/
On Thu, 24 Sep 2020 02:46:31 GMT, Nir Lisker wrote:
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264
>
> Nir Lisker has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Change range after clamping
The public API and implementation looks
On Fri, 7 Aug 2020 22:30:39 GMT, Kevin Rushforth wrote:
>> The only impact this has is that the range will be maximal instead of 0.
>> When these reach the shader, they will run the
>> lighting computation as opposed to skipping it. I'm not sure if this will
>> have any performance impact thoug
On Thu, 8 Oct 2020 16:11:46 GMT, Kevin Rushforth wrote:
> Simple patch to remove the obsolete `.hgignore` file.
This pull request has now been integrated.
Changeset: a56ba63b
Author:Kevin Rushforth
URL: https://git.openjdk.java.net/jfx/commit/a56ba63b
Stats: 73 lines in 1 file ch
On Thu, 8 Oct 2020 16:11:46 GMT, Kevin Rushforth wrote:
> Simple patch to remove the obsolete `.hgignore` file.
Marked as reviewed by jvos (Reviewer).
-
PR: https://git.openjdk.java.net/jfx/pull/316
On Thu, 8 Oct 2020 16:19:52 GMT, Kevin Rushforth wrote:
>> When connecting via Remote Desktop to a Windows 10 machine ans starting a
>> JavaFX application, the D3D pipeline is used
>> successfully. After closing the the Remote Desktop session and reconnecting,
>> the D3D requests fail with an
>
On Thu, 8 Oct 2020 16:07:08 GMT, Oliver Schmidtmer
wrote:
> When connecting via Remote Desktop to a Windows 10 machine ans starting a
> JavaFX application, the D3D pipeline is used
> successfully. After closing the the Remote Desktop session and reconnecting,
> the D3D requests fail with an
>
When connecting via Remote Desktop to a Windows 10 machine ans starting a
JavaFX application, the D3D pipeline is used
successfully. After closing the the Remote Desktop session and reconnecting,
the D3D requests fail with an
D3DERR_DEVICEREMOVED HResult, and the application contents are not ren
Simple patch to remove the obsolete `.hgignore` file.
-
Commit messages:
- 8254255: Remove obsolete .hgignore file
Changes: https://git.openjdk.java.net/jfx/pull/316/files
Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=316&range=00
Issue: https://bugs.openjdk.java.net/brow
ahh .. yeah, that's working, thanks :) Except that now it continues
with web testing as first, and I don't know how to exclude that,
something like
gradlew --continue test -x :web:test
just stops again after the base failure ..
But don't bother - it's the end of the working day and I
I see. In that case, the following will run follow-on tests:
gradlew --continue test
That's what I usually do for a full test run.
-- Kevin
On 10/8/2020 7:42 AM, Jeanette Winzenburg wrote:
thanks for the quick answer :)
Sounds like I wasn't clear enough, though (did mean unit tests): what
thanks for the quick answer :)
Sounds like I wasn't clear enough, though (did mean unit tests): what
I'm puzzled about is that the unit tests of a dependent project (f.i.
controls) is _not_ run if the base has test failures.
-- Jeanette
Zitat von Kevin Rushforth :
"gradlew test" is suff
"gradlew test" is sufficient to run the headless tests (e.g., the ones
in base, graphics, controls, etc). To run the headful tests, there are
two additional gradle options:
-PFULL_TEST=true
-PUSE_ROBOT=true
The first enables headless tests (which are in the systemTests project).
The second ad
The first enables headless tests (which are in the systemTests project)
s/headless/headful/
-- Kevin
On 10/8/2020 7:28 AM, Kevin Rushforth wrote:
"gradlew test" is sufficient to run the headless tests (e.g., the ones
in base, graphics, controls, etc). To run the headful tests, there are
With
./gradlew test
I expect that tests of all projects are run (and think I have seen
that expected behavior, but who knows ;), at least those projects with
changes that might effect the tests.
Since today (?), it looks like it stops after running base tests if
there's a failure in
On Thu, 8 Oct 2020 11:35:15 GMT, Eric Bresie
wrote:
>>> What OS are you using? (I'm running a test on Ubuntu 18.04)
>>
>> I also have 18.04.
>
> Does the
> [documentation](https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX)
> need updating to reflect the
> change?
The Wiki doesn'
On Thu, 8 Oct 2020 11:31:21 GMT, Eric Bresie
wrote:
>> Marked as reviewed by arapte (Reviewer).
>
> Does the
> [documentation](https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX)
> need updating to reflect the
> change?
Not directly as a result of this PR, since we don't list the
On Tue, 6 Oct 2020 13:14:05 GMT, Ambarish Rapte wrote:
>> Marked as reviewed by jvos (Reviewer).
>
>> What OS are you using? (I'm running a test on Ubuntu 18.04)
>
> I also have 18.04.
Does the
[documentation](https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX)
need updating to re
On Wed, 7 Oct 2020 12:54:20 GMT, Ambarish Rapte wrote:
>> Kevin Rushforth has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now
>> contains two commits:
>> - Merge branch 'master' into 8252192-vs2019-16.7.2
>> - 8252192: Update to Visual Studio
On Wed, 30 Sep 2020 11:46:24 GMT, Florian Kirmaier
wrote:
>> It's based on the discussion of my previous PR:
>> https://github.com/openjdk/jfx/pull/71
>>
>> I Added test utility class copied from JMemoryBuddy and used it to simplify
>> 4 of the existing unit tests.
>>
>> It's a direct copy o
On Sat, 3 Oct 2020 16:00:48 GMT, Florian Kirmaier wrote:
>> It's based on the discussion of my previous PR:
>> https://github.com/openjdk/jfx/pull/71
>>
>> I Added test utility class copied from JMemoryBuddy and used it to simplify
>> 4 of the existing unit tests.
>>
>> It's a direct copy of
27 matches
Mail list logo