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
> 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:
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: }
>>
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:
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
>>
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
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
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
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
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
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
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=316=00
Issue:
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 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
"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
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
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
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
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
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
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
On Wed, 7 Oct 2020 18:34:23 GMT, yosbits
wrote:
>> I plan to push changes that remain compatible, respecting the judgment of
>> the project leader, but I would like to point
>> out the following:
>> There seems to be a problem with the reproduction code as follows.
>>
>> * If there are
> https://bugs.openjdk.java.net/browse/JDK-8253086
>
> ObservableListWrapper.java
> * public boolean removeAll(Collection c)
> * public boolean retainAll(Collection c)
>
> These two methods use BitSet, but it doesn't make sense.
> By rewriting to the equivalent behavior that does not use
29 matches
Mail list logo
