Re: RFR: 8169501: GIF animation is too fast

[Bhawesh Choudhary]

On Thu, 23 Jul 2020 17:42:57 GMT, Kevin Rushforth  wrote:

>> issue is caused by the threshold value for frame duration used by javaFx 
>> before it gets normalized. JavaFx is using
>> threshold value 10 while other browser (Safari, Firefox) is using 50 due to 
>> which, value between 10 and 50 don't get
>> normalized and animation runs at faster speed. To fix the issue change frame 
>> duration normalization value to <= 50.
>> Safari : https://bugs.webkit.org/show_bug.cgi?id=14413 Firefox : 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=386269
>
> This is pending response to comments above.

10ms![10ms](https://user-images.githubusercontent.com/4208131/93172831-3c9fcb80-f749-11ea-93ee-46b58ecff4c3.gif)
 
11ms![11ms](https://user-images.githubusercontent.com/4208131/93172833-3dd0f880-f749-11ea-8fa7-5cf2f3cfdcdc.gif)
 12ms![12ms](https://user-images.githubusercontent.com/4208131/93172834-3e698f00-f749-11ea-92ae-24b3087758d2.gif)
 15ms![15ms](https://user-images.githubusercontent.com/4208131/93172836-3e698f00-f749-11ea-9b9b-15c5f21dd5af.gif)
__
19ms![19ms](https://user-images.githubusercontent.com/4208131/93172837-3f022580-f749-11ea-84be-7adc712bf230.gif)
 20ms![20ms](https://user-images.githubusercontent.com/4208131/93172839-3f9abc00-f749-11ea-8d5d-98b4ae131546.gif)
 21ms![21ms](https://user-images.githubusercontent.com/4208131/93172841-3f9abc00-f749-11ea-9b50-0cb5aa56b525.gif)
 40ms![40ms](https://user-images.githubusercontent.com/4208131/93172843-40335280-f749-11ea-8572-5bcfae11e28f.gif)
 
 __
75ms![75ms](https://user-images.githubusercontent.com/4208131/93172846-40cbe900-f749-11ea-8cc2-e20d2ce74947.gif)

Original![gif](https://user-images.githubusercontent.com/4208131/93172848-41647f80-f749-11ea-88a9-429fa956e428.gif)



Without the fix, gif animation speed matches for all interval gifs with all 
other browser (Which includes firefox,
safari, chrome). Only animation speed for gif file which is attached in issue 
doesn't match. javafx webkit plays it
faster. Imageview plays everything at its original speed. No clamping happens 
here.

-

PR: https://git.openjdk.java.net/jfx/pull/221

Re: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v2]

[Kevin Rushforth]

On Mon, 14 Sep 2020 11:22:42 GMT, Nir Lisker  wrote:

>> Kevin Rushforth has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Fixed URL to WEBKIT-MEDIA-STUBS.md
>
> Additional comments:
> 
> 1. "Use Unix-style (LF) line endings not DOS-style (CRLF)" needs a comma 
> before "not".
> 2. "Line width is no more than 120 characters" I remember that it was 130 or 
> 135 somewhere.
> 3. "Wildcard imports (import foo.bar.baz.*) are forbidden" Junit imports use 
> them extensively.
> 4. `./gradlew all test` will cause failure on webkit tests if it was not 
> built.

Regarding your additional comments:

> * "Use Unix-style (LF) line endings not DOS-style (CRLF)" needs a comma 
> before "not".

Fixed.

> * "Line width is no more than 120 characters" I remember that it was 130 or 
> 135 somewhere.

You're probably remembering an old version, but it's been 120 for a while now.

> * "Wildcard imports (import foo.bar.baz.*) are forbidden" Junit imports use 
> them extensively.

Fixed to add an exception for wildcard static imports in tests.

> * `./gradlew all test` will cause failure on webkit tests if it was not built.

Added a note about this and a pointer to the [Web 
Testing](WEBKIT-MEDIA-STUBS.md) doc.

-

PR: https://git.openjdk.java.net/jfx/pull/303

Re: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v2]

[Kevin Rushforth]

> This PR updates the `CONTRIBUTING.md` guide to address the following:
> 
> 1. Clarify the process for adding new features / API changes, specifically 
> that they must be discussed on the mailing
> list as the first step. 2. Add a link to the mailing list in the section 
> regarding contributing bug fixes.
> 3. Remove the text about cross-linking the PR and JBS issue, and add a note 
> that the Skara tooling takes care of this
> 4. Remove the section about manually resolving the JBS issue, and add a note 
> that the Skara bot automatically does this
> when the PR is integrated. 5. Suggest the use of the "/reviewers 2" and 
> "/csr" commands when appropriate
> 6. Update the note regarding which JDK(s) to use.

Kevin Rushforth has updated the pull request incrementally with one additional 
commit since the last revision:

  Fixed URL to WEBKIT-MEDIA-STUBS.md

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/303/files
  - new: https://git.openjdk.java.net/jfx/pull/303/files/9840ffea..becd269f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/303.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/303/head:pull/303

PR: https://git.openjdk.java.net/jfx/pull/303

RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes

[Kevin Rushforth]

This PR updates the `CONTRIBUTING.md` guide to address the following:

1. Clarify the process for adding new features / API changes, specifically that 
they must be discussed on the mailing
list as the first step. 2. Add a link to the mailing list in the section 
regarding contributing bug fixes.
3. Remove the text about cross-linking the PR and JBS issue, and add a note 
that the Skara tooling takes care of this
4. Remove the section about manually resolving the JBS issue, and add a note 
that the Skara bot automatically does this
when the PR is integrated. 5. Suggest the use of the "/reviewers 2" and "/csr" 
commands when appropriate
6. Update the note regarding which JDK(s) to use.

-

Commit messages:
 - Address review comments
 - Address review comments + additional fixes
 - 8231601: Update CONTRIBUTING.md to clarify process for contributing features 
plus Skara changes

Changes: https://git.openjdk.java.net/jfx/pull/303/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8231601
  Stats: 100 lines in 1 file changed: 50 ins; 25 del; 25 mod
  Patch: https://git.openjdk.java.net/jfx/pull/303.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/303/head:pull/303

PR: https://git.openjdk.java.net/jfx/pull/303

Re: Media Player Failure When Speakers Not Present

[Kevin Rushforth]

That's still the right place to report bugs. You can find this in the 
project README [1] on GItHub.


-- Kevin

[1] https://github.com/openjdk/jfx#issue-tracking


On 9/14/2020 1:27 PM, omnip...@gmail.com wrote:

I am a little confused. The url you sent appears to be for Java SE bug 
reporting and I thought that JavaFX as OpenJFX is not part of the Java SE 
distribution. If so then this may not be where I report my issue.

  


Ken

  

  


From: Nir Lisker 
Sent: September 14, 2020 4:19 PM
To: omnip...@gmail.com
Cc: openjfx-dev@openjdk.java.net Mailing 
Subject: Re: Media Player Failure When Speakers Not Present

  


PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will
submit a bug report.

  


bugreport.java.com 

  


On Mon, Sep 14, 2020 at 11:03 PM mailto:omnip...@gmail.com> 
> wrote:

While I am still looking for where I can file this problem I thought I'd
bring it to the list. A program I use in my course plays a short video. Have
used it for a few years and it works fine. EXCEPT, if there is not a
connected audio out device such as speakers or headphones. The video does
not play and there is no stack trace or any other indication of a problem.
Stage opens fine but the media control does nothing and the scene appears
empty. Discovered when I used a machine that did not have speakers plugged
into it. Expected behaviour was just to see the video without sound. It is
possible that this bug has been around since the introduction of the Media /
Media Player control.



I assume the code works like "Hi M. PCaudio, what are you connected to?"
"I'm not connected to anything, M. Media Player" "That's OK M. PCAudio, I'll
just wait forever or just give up and do nothing".



Or, it can just be a crazy Xeon based Windows machine that is giving grief
to OpenJFX. Using Java 14 and OpenJFX 16-ea+1.



Ken Fogel



PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will
submit a bug report.

Re: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes

[Kevin Rushforth]

On Mon, 14 Sep 2020 10:18:05 GMT, Nir Lisker  wrote:

>> This PR updates the `CONTRIBUTING.md` guide to address the following:
>> 
>> 1. Clarify the process for adding new features / API changes, specifically 
>> that they must be discussed on the mailing
>> list as the first step. 2. Add a link to the mailing list in the section 
>> regarding contributing bug fixes.
>> 3. Remove the text about cross-linking the PR and JBS issue, and add a note 
>> that the Skara tooling takes care of this
>> 4. Remove the section about manually resolving the JBS issue, and add a note 
>> that the Skara bot automatically does this
>> when the PR is integrated. 5. Suggest the use of the "/reviewers 2" and 
>> "/csr" commands when appropriate
>> 6. Update the note regarding which JDK(s) to use.
>
> CONTRIBUTING.md line 18:
> 
>> 16: 
>> 17:
>> 18: All new feature requests, including any API changes, need prior 
>> discussion on the
>> [openjfx-dev](mailto:openjfx-dev@openjdk.java.net) mailing list, even if 
>> there is already an open
> 
> I think that the mailing list link shouldn't be to a `mailto` protocol as 
> these aren't always configured in the
> browser, and in any case, since the intention is to have a discussion, the 
> user should be advised to register to the
> list and not send a one-time mail. So I suggest to redirect to
> https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev.

Fixed.

> CONTRIBUTING.md line 19:
> 
>> 17:
>> 18: All new feature requests, including any API changes, need prior 
>> discussion on the
>> [openjfx-dev](mailto:openjfx-dev@openjdk.java.net) mailing list, even if 
>> there is already an open 19: [JBS
>> issue](https://bugs.openjdk.java.net). See the [New features / API 
>> additions](#new-features--api-additions) section at
>> the end of this guide for more information.
> 
> Also for the link under "Bug reports". I think that the issue list link 
> should direct to a JavaFX search like
> `https://bugs.openjdk.java.net/issues/?jql=component %3D javafx order by 
> updated DESC` to make it easier to search.

Fixed (I included a link to a filter the first time, where it suggests to 
search for already-reported issues).

> CONTRIBUTING.md line 24:
> 
>> 22: ---
>> 23:
>> 24: If you have a bug fix or new feature that you would like to contribute 
>> to OpenJFX, please find or open an issue
>> about it first. Talk about what you would like to do on the 
>> [openjfx-dev](mailto:openjfx-dev@openjdk.java.net) mailing
>> list. It may be that somebody is already working on it, or that there are 
>> particular issues that you should know about
>> before implementing the change. Feature requests, in particular, must be 
>> discussed ahead of time and will require
>> significant effort on your part.
> 
> "please find or open an issue about it first"
> Shouldn't a discussion happen before a feature is submitted in JBS? Or do we 
> close as "won't fix" if the feature is
> rejected?

I think I'll remove the comment about "please find or open an issue about it 
first" and just say:

If you have a bug fix or new feature that you would like to contribute to 
OpenJFX, please talk about what you would
like to do...

> CONTRIBUTING.md line 100:
> 
>> 98: Please adhere to the general guideline that you should never force 
>> push
>> 99: to a publicly shared branch. Once you have opened your pull request, 
>> you
>> 100: should consider your branch publicly shared. Instead of force 
>> pushing
> 
> Minor: this whole paragraph is filled with git terminology like squash, 
> rebase, force push... Maybe a link to the git
> docs could help.

I added a pointer to the GitHub help page here.

> CONTRIBUTING.md line 96:
> 
>> 94: TIP: prefix the pull request title with `WIP:` if you aren't yet
>> 95: ready for it to be reviewed. The Skara bot will not send an RFR
>> 96: email unless the title starts with a 7-digit bug ID.
> 
> I'm pretty sure it doesn't send RFR mails on draft issues regardless of the 
> title. I create all my PRs as draft to make
> sure everything is correct, and only then transition. I've never seen a 
> premature RFR mail, though it could be a
> natural delay of he bot.

I updated the doc to mention Draft PRs

-

PR: https://git.openjdk.java.net/jfx/pull/303

Re: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes

[Nir Lisker]

On Sat, 12 Sep 2020 17:16:38 GMT, Kevin Rushforth  wrote:

> This PR updates the `CONTRIBUTING.md` guide to address the following:
> 
> 1. Clarify the process for adding new features / API changes, specifically 
> that they must be discussed on the mailing
> list as the first step. 2. Add a link to the mailing list in the section 
> regarding contributing bug fixes.
> 3. Remove the text about cross-linking the PR and JBS issue, and add a note 
> that the Skara tooling takes care of this
> 4. Remove the section about manually resolving the JBS issue, and add a note 
> that the Skara bot automatically does this
> when the PR is integrated. 5. Suggest the use of the "/reviewers 2" and 
> "/csr" commands when appropriate
> 6. Update the note regarding which JDK(s) to use.

Additional comments:

1. "Use Unix-style (LF) line endings not DOS-style (CRLF)" needs a comma before 
"not".
2. "Line width is no more than 120 characters" I remember that it was 130 or 
135 somewhere.
3. "Wildcard imports (import foo.bar.baz.*) are forbidden" Junit imports use 
them extensively.
4. `./gradlew all test` will cause failure on webkit tests if it was not built.

CONTRIBUTING.md line 18:

> 16: 
> 17:
> 18: All new feature requests, including any API changes, need prior 
> discussion on the
> [openjfx-dev](mailto:openjfx-dev@openjdk.java.net) mailing list, even if 
> there is already an open

I think that the mailing list link shouldn't be to a `mailto` protocol as these 
aren't always configured in the
browser, and in any case, since the intention is to have a discussion, the user 
should be advised to register to the
list and not send a one-time mail. So I suggest to redirect to
https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev.

CONTRIBUTING.md line 19:

> 17:
> 18: All new feature requests, including any API changes, need prior 
> discussion on the
> [openjfx-dev](mailto:openjfx-dev@openjdk.java.net) mailing list, even if 
> there is already an open 19: [JBS
> issue](https://bugs.openjdk.java.net). See the [New features / API 
> additions](#new-features--api-additions) section at
> the end of this guide for more information.

Also for the link under "Bug reports". I think that the issue list link should 
direct to a JavaFX search like
`https://bugs.openjdk.java.net/issues/?jql=component %3D javafx order by 
updated DESC` to make it easier to search.

CONTRIBUTING.md line 24:

> 22: ---
> 23:
> 24: If you have a bug fix or new feature that you would like to contribute to 
> OpenJFX, please find or open an issue
> about it first. Talk about what you would like to do on the 
> [openjfx-dev](mailto:openjfx-dev@openjdk.java.net) mailing
> list. It may be that somebody is already working on it, or that there are 
> particular issues that you should know about
> before implementing the change. Feature requests, in particular, must be 
> discussed ahead of time and will require
> significant effort on your part.

"please find or open an issue about it first"
Shouldn't a discussion happen before a feature is submitted in JBS? Or do we 
close as "won't fix" if the feature is
rejected?

CONTRIBUTING.md line 24:

> 22: ---
> 23:
> 24: If you have a bug fix or new feature that you would like to contribute to 
> OpenJFX, please find or open an issue
> about it first. Talk about what you would like to do on the 
> [openjfx-dev](mailto:openjfx-dev@openjdk.java.net) mailing
> list. It may be that somebody is already working on it, or that there are 
> particular issues that you should know about
> before implementing the change. Feature requests, in particular, must be 
> discussed ahead of time and will require
> significant effort on your part.

Same comment on the "openjfx-dev" link.

CONTRIBUTING.md line 88:

> 86: of the PR title and check for whitespace errors. Once that passes,
> 87: it will automatically send a Request For Review (RFR) email to the
> 88: [openjfx-dev](mailto:openjfx-dev@openjdk.java.net) mailing list.

Same comment on the "openjfx-dev" link.

CONTRIBUTING.md line 96:

> 94: TIP: prefix the pull request title with `WIP:` if you aren't yet
> 95: ready for it to be reviewed. The Skara bot will not send an RFR
> 96: email unless the title starts with a 7-digit bug ID.

I'm pretty sure it doesn't send RFR mails on draft issues regardless of the 
title. I create all my PRs as draft to make
sure everything is correct, and only then transition. I've never seen a 
premature RFR mail, though it could be a
natural delay of he bot.

CONTRIBUTING.md line 100:

> 98: Please adhere to the general guideline that you should never force 
> push
> 99: to a publicly shared branch. Once you have opened your pull request, 
> you
> 100: should consider your branch publicly shared. Instead of force pushing

Minor: this whole paragraph is filled with git terminology like squash, rebase, 
force push... 

Re: Media Player Failure When Speakers Not Present

[Nir Lisker]

The issues database is the same for all OpenJDK projects, including JDK and
OpenJFX. When you submit the issue, it is triaged internally and
transferred to the public JBS at https://bugs.openjdk.java.net.

On Mon, Sep 14, 2020 at 11:27 PM  wrote:

> I am a little confused. The url you sent appears to be for Java SE bug
> reporting and I thought that JavaFX as OpenJFX is not part of the Java SE
> distribution. If so then this may not be where I report my issue.
>
>
>
> Ken
>
>
>
>
>
> *From:* Nir Lisker 
> *Sent:* September 14, 2020 4:19 PM
> *To:* omnip...@gmail.com
> *Cc:* openjfx-dev@openjdk.java.net Mailing 
> *Subject:* Re: Media Player Failure When Speakers Not Present
>
>
>
> PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will
> submit a bug report.
>
>
>
> bugreport.java.com
>
>
>
> On Mon, Sep 14, 2020 at 11:03 PM  wrote:
>
> While I am still looking for where I can file this problem I thought I'd
> bring it to the list. A program I use in my course plays a short video.
> Have
> used it for a few years and it works fine. EXCEPT, if there is not a
> connected audio out device such as speakers or headphones. The video does
> not play and there is no stack trace or any other indication of a problem.
> Stage opens fine but the media control does nothing and the scene appears
> empty. Discovered when I used a machine that did not have speakers plugged
> into it. Expected behaviour was just to see the video without sound. It is
> possible that this bug has been around since the introduction of the Media
> /
> Media Player control.
>
>
>
> I assume the code works like "Hi M. PCaudio, what are you connected to?"
> "I'm not connected to anything, M. Media Player" "That's OK M. PCAudio,
> I'll
> just wait forever or just give up and do nothing".
>
>
>
> Or, it can just be a crazy Xeon based Windows machine that is giving grief
> to OpenJFX. Using Java 14 and OpenJFX 16-ea+1.
>
>
>
> Ken Fogel
>
>
>
> PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will
> submit a bug report.
>
>
>

Re: Media Player Failure When Speakers Not Present

[Michael Paus]

The URL is correct. JavaFX is still tracked by the normal JDK bug 
tracking system.


Am 14.09.20 um 22:27 schrieb omnip...@gmail.com:

I am a little confused. The url you sent appears to be for Java SE bug 
reporting and I thought that JavaFX as OpenJFX is not part of the Java SE 
distribution. If so then this may not be where I report my issue.

  


Ken

  

  


From: Nir Lisker 
Sent: September 14, 2020 4:19 PM
To: omnip...@gmail.com
Cc: openjfx-dev@openjdk.java.net Mailing 
Subject: Re: Media Player Failure When Speakers Not Present

  


PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will
submit a bug report.

  


bugreport.java.com 

  


On Mon, Sep 14, 2020 at 11:03 PM mailto:omnip...@gmail.com> 
> wrote:

While I am still looking for where I can file this problem I thought I'd
bring it to the list. A program I use in my course plays a short video. Have
used it for a few years and it works fine. EXCEPT, if there is not a
connected audio out device such as speakers or headphones. The video does
not play and there is no stack trace or any other indication of a problem.
Stage opens fine but the media control does nothing and the scene appears
empty. Discovered when I used a machine that did not have speakers plugged
into it. Expected behaviour was just to see the video without sound. It is
possible that this bug has been around since the introduction of the Media /
Media Player control.



I assume the code works like "Hi M. PCaudio, what are you connected to?"
"I'm not connected to anything, M. Media Player" "That's OK M. PCAudio, I'll
just wait forever or just give up and do nothing".



Or, it can just be a crazy Xeon based Windows machine that is giving grief
to OpenJFX. Using Java 14 and OpenJFX 16-ea+1.



Ken Fogel



PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will
submit a bug report.

RE: Media Player Failure When Speakers Not Present

[omniprof]

I am a little confused. The url you sent appears to be for Java SE bug 
reporting and I thought that JavaFX as OpenJFX is not part of the Java SE 
distribution. If so then this may not be where I report my issue.

 

Ken

 

 

From: Nir Lisker  
Sent: September 14, 2020 4:19 PM
To: omnip...@gmail.com
Cc: openjfx-dev@openjdk.java.net Mailing 
Subject: Re: Media Player Failure When Speakers Not Present

 

PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will
submit a bug report.  

 

bugreport.java.com  

 

On Mon, Sep 14, 2020 at 11:03 PM mailto:omnip...@gmail.com> > wrote:

While I am still looking for where I can file this problem I thought I'd
bring it to the list. A program I use in my course plays a short video. Have
used it for a few years and it works fine. EXCEPT, if there is not a
connected audio out device such as speakers or headphones. The video does
not play and there is no stack trace or any other indication of a problem.
Stage opens fine but the media control does nothing and the scene appears
empty. Discovered when I used a machine that did not have speakers plugged
into it. Expected behaviour was just to see the video without sound. It is
possible that this bug has been around since the introduction of the Media /
Media Player control. 



I assume the code works like "Hi M. PCaudio, what are you connected to?"
"I'm not connected to anything, M. Media Player" "That's OK M. PCAudio, I'll
just wait forever or just give up and do nothing".



Or, it can just be a crazy Xeon based Windows machine that is giving grief
to OpenJFX. Using Java 14 and OpenJFX 16-ea+1.



Ken Fogel



PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will
submit a bug report.

Re: Media Player Failure When Speakers Not Present

[Nir Lisker]

>
> PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will
> submit a bug report.
>

bugreport.java.com

On Mon, Sep 14, 2020 at 11:03 PM  wrote:

> While I am still looking for where I can file this problem I thought I'd
> bring it to the list. A program I use in my course plays a short video.
> Have
> used it for a few years and it works fine. EXCEPT, if there is not a
> connected audio out device such as speakers or headphones. The video does
> not play and there is no stack trace or any other indication of a problem.
> Stage opens fine but the media control does nothing and the scene appears
> empty. Discovered when I used a machine that did not have speakers plugged
> into it. Expected behaviour was just to see the video without sound. It is
> possible that this bug has been around since the introduction of the Media
> /
> Media Player control.
>
>
>
> I assume the code works like "Hi M. PCaudio, what are you connected to?"
> "I'm not connected to anything, M. Media Player" "That's OK M. PCAudio,
> I'll
> just wait forever or just give up and do nothing".
>
>
>
> Or, it can just be a crazy Xeon based Windows machine that is giving grief
> to OpenJFX. Using Java 14 and OpenJFX 16-ea+1.
>
>
>
> Ken Fogel
>
>
>
> PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will
> submit a bug report.
>
>
>
>

Media Player Failure When Speakers Not Present

[omniprof]

While I am still looking for where I can file this problem I thought I'd
bring it to the list. A program I use in my course plays a short video. Have
used it for a few years and it works fine. EXCEPT, if there is not a
connected audio out device such as speakers or headphones. The video does
not play and there is no stack trace or any other indication of a problem.
Stage opens fine but the media control does nothing and the scene appears
empty. Discovered when I used a machine that did not have speakers plugged
into it. Expected behaviour was just to see the video without sound. It is
possible that this bug has been around since the introduction of the Media /
Media Player control. 

 

I assume the code works like "Hi M. PCaudio, what are you connected to?"
"I'm not connected to anything, M. Media Player" "That's OK M. PCAudio, I'll
just wait forever or just give up and do nothing".

 

Or, it can just be a crazy Xeon based Windows machine that is giving grief
to OpenJFX. Using Java 14 and OpenJFX 16-ea+1.

 

Ken Fogel

 

PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will
submit a bug report.

 

Re: RFR: 8197991: Selecting many items in a TableView is very slow

[yosbits]

On Mon, 14 Sep 2020 10:03:59 GMT, Ajit Ghaisas  wrote:

>> Any progress with having this merged?
>
> This is a very good attempt to improve selection performance. I have few 
> review comments.
> I ran the manual test that you have provided. It does show the improvement.
> Can you please provide an automated test along with your fix?

The reviewer didn't point out that the
There's a little bit of wastage left in the toArray(), so I'm going to push a 
modified version.

-

PR: https://git.openjdk.java.net/jfx/pull/127

Re: RFR: 8218973: SVG with masking is not rendering image with mask effect [v12]

[Bhawesh Choudhary]

On Fri, 11 Sep 2020 00:13:48 GMT, Kevin Rushforth  wrote:

>> Bhawesh Choudhary has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Added unit test for strokes
>
> modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java
>  line 524:
> 
>> 522: }
>> 523: if (isFill) {
>> 524: g1.fill(shape);
> 
> This will call the slower `fill(Shape)` method in all cases rather than the 
> specialized `fillRect` or `fillRoundRect`
> method. Given all the other things that are done to draw a shape with a clip 
> mask, I suspect that this is fine. One
> thing to consider is to pass in an enum instead of a boolean. The enum could 
> say whether to use the specialized calls
> or the generic `fill` call. It's probably not worth the effort to make this 
> change.

other than paths only RoundRectangle2D is passed to this function. Shape can be 
checked if it is an instance of
RoundRectangle2D and faster draw api can be called. added the same along with 
enum private to this class.

> modules/javafx.web/src/test/java/test/javafx/scene/web/SVGTest.java line 164:
> 
>> 162: final WebPage webPage = WebEngineShim.getPage(getEngine());
>> 163: assertNotNull(webPage);
>> 164: final BufferedImage img = WebPageShim.paint(webPage, 0, 0, 
>> 200, 200);
> 
> This is added to the (preexisting) problem of calling `paint` on the wrong 
> thread. In this case, it doesn't seem to
> cause any additional problems, and other tests in this same class do it, so 
> we can fix this in the follow-on issue that
> is already filed, 
> [JDK-8252596](https://bugs.openjdk.java.net/browse/JDK-8252596).

moved tests to system test. also consolidated all tests into one.

-

PR: https://git.openjdk.java.net/jfx/pull/213

Re: RFR: 8218973: SVG with masking is not rendering image with mask effect [v12]

[Bhawesh Choudhary]

On Fri, 11 Sep 2020 00:10:29 GMT, Kevin Rushforth  wrote:

>> Bhawesh Choudhary has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Added unit test for strokes
>
> modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java
>  line 447:
> 
>> 445: public void setClip(int cx, int cy, int cw, int ch, WCImage 
>> maskImage) {
>> 446: setClip(new Rectangle(cx, cy, cw, ch));
>> 447: state.setClipMaskImage(maskImage);
> 
> Should all of the other variants of setClip (the ones that don't take a 
> maskImage) set the clipMaskImage to null?
> Otherwise it seems that it might not be reset to null in all cases.

added setting of null to maskImage for all the overloads of setClip where mask 
image is not present.

> modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java
>  line 520:
> 
>> 518: state.apply(g1);
>> 519: g1.setPaint(paint);
>> 520: if(stroke != null) {
> 
> Minor: there should be a space after the `if`.

Fixed

-

PR: https://git.openjdk.java.net/jfx/pull/213

Re: RFR: 8218973: SVG with masking is not rendering image with mask effect [v7]

[Bhawesh Choudhary]

On Fri, 11 Sep 2020 06:48:35 GMT, Bhawesh Choudhary  
wrote:

>> This question is still outstanding. It seems like the call to `setCTM` is 
>> either needed before all of the `setGradient`
>> calls or none of them. Can you comment?
>
> i believe setCTM call is needed for none of them. it is a workaround i have 
> added till i have more concrete fix. also
> please note that this workaround is needed only in cases where ui scaling is 
> more than 1.

Removed the workaround and added right fix. `setCTM` call is not needed in any 
of the case.

-

PR: https://git.openjdk.java.net/jfx/pull/213

Re: RFR: 8218973: SVG with masking is not rendering image with mask effect [v13]

[Bhawesh Choudhary]

> 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 to WCGraphicsPrismContext.java 
>  While rendering in
> WCGraphicsPrismContext.java if image clip mask is available, use it for 
> rendering using MaskTextureGraphics interface
> otherwise use usual way of rendering.

Bhawesh Choudhary has updated the pull request incrementally with one 
additional commit since the last revision:

  Updates as per review comments

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/213/files
  - new: https://git.openjdk.java.net/jfx/pull/213/files/ed2dd092..f26f03df

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=213&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=213&range=11-12

  Stats: 336 lines in 6 files changed: 173 ins; 152 del; 11 mod
  Patch: https://git.openjdk.java.net/jfx/pull/213.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/213/head:pull/213

PR: https://git.openjdk.java.net/jfx/pull/213

Re: RFR: 8197991: Selecting many items in a TableView is very slow

[Ajit Ghaisas]

On Wed, 26 Feb 2020 07:37:06 GMT, yosbits 
 wrote:

> https://bugs.openjdk.java.net/browse/JDK-8197991
> 
> The performance of the selectAll and selectRange methods of the 
> MultiSelectionModel class has been greatly improved.
> 
> This greatly improves the response when selecting multiple items in ListView 
> and TableView.
> 
> However, in TreeView / TreeTableView, the improvement effect is hidden mainly 
> due to the design problem of the cache of
> TreeUtil.getTreeItem ().
> Reference value of the number of data that can be handled within 3 seconds of 
> processing time (before-> after)
> 
> ListView
> * selectAll: 400_000-> 10_000_000
> * selectRange: 7_000-> 70_000
> 
> TableView
> * selectAll: 8_000-> 700_000
> * selectRange: 7_000-> 50_000
> 
> 
> You can see performance improvements in the following applications:
> 
> 
>  SelectListViewTest.java
> import javafx.application.Application;
> import javafx.collections.ObservableList;
> import javafx.scene.Scene;
> import javafx.scene.control.Button;
> import javafx.scene.control.ListView;
> import javafx.scene.control.SelectionMode;
> import javafx.scene.layout.BorderPane;
> import javafx.scene.layout.VBox;
> import javafx.stage.Stage;
> 
> public class SelectListViewTest extends Application {
>   final int ROW_COUNT = 70_000;
> //final int ROW_COUNT = 400_000;
> //final int ROW_COUNT = 10_000_000;
> //final int ROW_COUNT = 7_000;
> 
>   @Override
> public void start(Stage stage) {
>   ListView listView = new ListView<>();
>   listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE);
> 
> 
>   ObservableList items = listView.getItems();
>   for(int i=0; i   String rec = String.valueOf(i);
>   items.add(rec);
>   }
> BorderPane root = new BorderPane(listView);
>   Button selectAll = new Button("selectAll");
>   Button clearSelection = new Button("clearSelection");
>   Button selectToStart = new Button("selectToStart");
>   Button selectToEnd = new Button("selectToEnd");
>   Button selectPrevious = new Button("selectPrevious");
>   Button selectNext= new Button("selectNext");
> 
>   selectAll.setFocusTraversable(true);
>   clearSelection.setFocusTraversable(true);
>   selectToStart.setFocusTraversable(true);
>   selectToEnd.setFocusTraversable(true);
>   selectPrevious.setFocusTraversable(true);
>   selectNext.setFocusTraversable(true);
> 
> root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, 
> selectPrevious, selectNext, clearSelection));
> stage.setScene(new Scene(root, 600, 600));
> 
> selectAll.setOnAction((e)->selectAll(listView));
> clearSelection.setOnAction((e)->clearSelection(listView));
> selectToStart.setOnAction((e)->selectToStart(listView));
> selectToEnd.setOnAction((e)->selectToLast(listView));
> selectPrevious.setOnAction((e)->selectPrevious(listView));
> selectNext.setOnAction((e)->selectNext(listView));
> 
> stage.show();
> }
> 
>   private void selectAll(ListView listView) {
>   long t = System.currentTimeMillis();
>   listView.getSelectionModel().selectAll();
>   System.out.println("time:"+ (System.currentTimeMillis() - t));
>   }
>   private void clearSelection(ListView listView) {
>   long t = System.currentTimeMillis();
>   listView.getSelectionModel().clearSelection();
>   System.out.println("time:"+ (System.currentTimeMillis() - t));
>   }
>   private void selectToStart(ListView listView) {
>   long t = System.currentTimeMillis();
>   listView.getSelectionModel().selectRange(0, 
> listView.getSelectionModel().getSelectedIndex());
>   System.out.println("time:"+ (System.currentTimeMillis() - t));
>   }
>   private void selectToLast(ListView listView) {
>   long t = System.currentTimeMillis();
>   
> listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(),
>  listView.getItems().size());
>   System.out.println("time:"+ (System.currentTimeMillis() - t));
>   }
> 
>   private void selectPrevious(ListView listView) {
>   long t = System.currentTimeMillis();
>   listView.getSelectionModel().selectPrevious();
>   System.out.println("time:"+ (System.currentTimeMillis() - t));
>   }
> 
>   private void selectNext(ListView listView) {
>   long t = System.currentTimeMillis();
>   listView.getSelectionModel().selectNext();
>   System.out.println("time:"+ (System.currentTimeMillis() - t));
>   }
> public static void main(String[] args) {
>   Application.launch(args);
>   }
> }
> 
>  SelectTableViewTest.java
> import javafx.application.Application;
> import javafx.beans.property.SimpleStri

Re: RFR: 8197991: Selecting many items in a TableView is very slow

[Ajit Ghaisas]

On Mon, 7 Sep 2020 18:14:03 GMT, Timm 
 wrote:

>> @aghaisas can you also review this?
>
> Any progress with having this merged?

This is a very good attempt to improve selection performance. I have few review 
comments.
I ran the manual test that you have provided. It does show the improvement.
Can you please provide an automated test along with your fix?

-

PR: https://git.openjdk.java.net/jfx/pull/127

RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper

[yosbits]

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 BitSet, it is 
possible to reduce the CPU load in a wide range
of use cases.

The test is done with the following command.

* gradle base: test
* gradle controls: test

-

Commit messages:
 - 8253086: Optimization of removeAll and retainAll of ObservableListWrapper

Changes: https://git.openjdk.java.net/jfx/pull/305/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=305&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253086
  Stats: 26 lines in 1 file changed: 6 ins; 10 del; 10 mod
  Patch: https://git.openjdk.java.net/jfx/pull/305.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/305/head:pull/305

PR: https://git.openjdk.java.net/jfx/pull/305

Integrated: 8252547: Correct transformations docs in Node

[Nir Lisker]

On Mon, 31 Aug 2020 23:28:51 GMT, Nir Lisker  wrote:

> Correction to the order of transforms specified in the docs of `Node`.

This pull request has now been integrated.

Changeset: d6dee348
Author:Nir Lisker 
URL:   https://git.openjdk.java.net/jfx/commit/d6dee348
Stats: 45 lines in 1 file changed: 12 ins; 15 del; 18 mod

8252547: Correct transformations docs in Node

Reviewed-by: kcr, arapte

-

PR: https://git.openjdk.java.net/jfx/pull/293

Re: RFR: 8252236: TabPane - initial select tab not working properly

[Jeanette Winzenburg]

On Mon, 14 Sep 2020 07:09:01 GMT, Ambarish Rapte  wrote:

>> the issue is that the header of the selected tab is not always visible (or 
>> kept visible, see report for details)
>> 
>> - initially
>> - after changing side
>> - after resizing stage/tabPane
>> 
>> Fixed in TabPaneSkin to notify its TabHeaderArea (== collaborator that is 
>> responsible for layout the tabs) whenever its
>> scroll might need an update.
>> Added tests that fail before and pass after the fix.
>
> In a bid to find more scenarios like you did mention description, I observed 
> two more scenarios when selected tab does
> not stay in view. 1. Inserting tabs before or removing tabs after selected 
> tab or moving the selected tab, causes the
> selected tab to go out of view. 2. Rotating TabPane can also take the 
> selected tab out of view. I am little doubtful if
> it a legitimate issue. The rotations I tried clipped TabPane and TabPane 
> header.  I think rotation issue can be kept
> out of scope of this issue, can be filed as a follow on. I leave to it to you 
> to take a call.
> About 1, I did quickly verify that it gets fixed by adding 
> `invalidateScrollOffset();` call in
> `TabHeaderArea.removeTab()`, `TabHeaderArea.addTab()` and  
> `TabHeaderArea.moveTab()`. Also If we fix it here, then bug
> summary might need a change. It currently reflects only initial tab.

good catch and many thanks for the evaluation - now all I'll have to do is to 
write tests to catch them :) Will also
update the bug summary as you suggest.

Agree, that the second can be regarded as off scope, as it seems to effect both 
header and content - will not do
anything in this fix.

-

PR: https://git.openjdk.java.net/jfx/pull/300

Re: RFR: 8240499: Enforce whitespace checking for additional source files

[Johan Vos]

On Fri, 11 Sep 2020 13:21:29 GMT, Kevin Rushforth  wrote:

> The `.jcheck/conf` file is configured to check the same set of files as the 
> old HG jcheck, namely files with the
> following extensions:
> .java, .c, .h, .cpp, .hpp
> 
> The Skara git jcheck allows us to evolve the rules for white space checking 
> compatibly.
> 
> This PR adds the following additional file extensions to the list of source 
> files that need to be kept whitespace-clean:
> 
> .cc, .css, .frag, .fxml, .g4, .gradle, .groovy, .hlsl, .jsl, .m, .metal, 
> .mm, .stg, .vert
> 
> For ease of review, I have done the initial push as 2 commits. The first 
> modifies the `.jcheck/conf` file and
> `tools/scripts/checkWhiteSpace` script to add the additional extensions. The 
> second fixes the whitespace errors in the
> (39) files among those with the newly added extensions.

Tested this with before/after tests, and it works as expected.

-

Marked as reviewed by jvos (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/301

Re: RFR: 8252547: Correct transformations docs in Node [v5]

[Ambarish Rapte]

On Sat, 12 Sep 2020 15:21:35 GMT, Nir Lisker  wrote:

>> Correction to the order of transforms specified in the docs of `Node`.
>
> Nir Lisker has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Replaced a link

change looks good to me, javadoc built with no problem.

-

Marked as reviewed by arapte (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/293

Re: RFR: 8252236: TabPane - initial select tab not working properly

[Ambarish Rapte]

On Thu, 10 Sep 2020 12:03:34 GMT, Jeanette Winzenburg  
wrote:

> the issue is that the header of the selected tab is not always visible (or 
> kept visible, see report for details)
> 
> - initially
> - after changing side
> - after resizing stage/tabPane
> 
> Fixed in TabPaneSkin to notify its TabHeaderArea (== collaborator that is 
> responsible for layout the tabs) whenever its
> scroll might need an update.
> Added tests that fail before and pass after the fix.

In a bid to find more scenarios like you did mention description, I observed 
two more scenarios when selected tab does
not stay in view. 1. Inserting tabs before or removing tabs after selected tab 
or moving the selected tab, causes the
selected tab to go out of view. 2. Rotating TabPane can also take the selected 
tab out of view. I am little doubtful if
it a legitimate issue. The rotations I tried clipped TabPane and TabPane 
header.  I think rotation issue can be kept
out of scope of this issue, can be filed as a follow on. I leave to it to you 
to take a call.

About 1, I did quickly verify that it gets fixed by adding 
`invalidateScrollOffset();` call in
`TabHeaderArea.removeTab()`, `TabHeaderArea.addTab()` and  
`TabHeaderArea.moveTab()`. Also If we fix it here, then bug
summary might need a change. It currently reflects only initial tab.

-

PR: https://git.openjdk.java.net/jfx/pull/300