Re: Updating printers while application is running?

[Philip Race]

On 6/8/22 11:34 AM, Tobias Oelgarte wrote:


I don't know if there is an common event available in the Java2D 
backend to detect added/removed printers directly. So far i could not 
see anything like that.




I am referring to windows native code we have in Java 2D.
It is completely invisible at the API level of Java 2D.

Every PrintService instance should implement the equals() [1] method 
to determine uniqueness. This could be used to compare/intersect the 
observable set of printers hold by 
javafx.print.Printer#getAllPrinters() against the array of 
PrintService instances exposed by 
PrintServiceLookup.getPrintServices(...). That way it should be 
possible to detect if a printer was removed or added. It could also be 
used to update the default printer property (on access and/or 
periodically).




Well yes, there's got to be a comparison.  No one said "I don't know 
what to do here" ..



-phil.

[1] 
https://docs.oracle.com/en/java/javase/18/docs/api/java.desktop/javax/print/PrintService.html#equals(java.lang.Object)


On 07.06.22 21:44, Philip Race wrote:

Ahem .. well .. I guess we (I) forgot to get back to that.

Since the current implementation on Windows wraps the Java 2D 
printing code
and it registers with windows to be told about changes in printers 
then the
calls being made in the method with that comment would (well, should) 
provide

the updated printers ..

The comment was (I think) referring to the need to know when there 
was actually

a change there to avoid perpetual re-creation.

If the 2D side is working as expected I'll see if there's something I 
can do along the lines
of a quick check every time that the number of underlying printers is 
the same and then if not it is worthwhile,

coupled with a refresh every 2 minutes so it should never get too stale.

-phil.

On 6/7/22 11:39 AM, Tobias Oelgarte wrote:
Is there some way to update the ObservableSet of Printers once the 
Application is running? Calling Printer.getAllPrinters() always 
returns the same OberservableSet and it does not change - ever. [1]


We have an JavaFx based application running under Windows 10/11 that 
is used to print on wireless printers, that are not always 
available. Having to restart the the application every time a 
printer goes away or comes available is a serious pain for the users.


Is there any kind of workaround?

I doubt it will be fixed in the near future, since this comment is 
from 6 years ago [2]:


    // This is static. Eventually I want it to be dynamic, but first
    // it needs to be enhanced to only create new instances where
    // there really has been a change, which will be rare.

[1] 
https://stackoverflow.com/questions/38470568/javafx-doesnt-detect-changes-of-available-printers


[2] 
https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java#L99

Re: Updating printers while application is running?

[Philip Race]

Ahem .. well .. I guess we (I) forgot to get back to that.

Since the current implementation on Windows wraps the Java 2D printing code
and it registers with windows to be told about changes in printers then the
calls being made in the method with that comment would (well, should) 
provide

the updated printers ..

The comment was (I think) referring to the need to know when there was 
actually

a change there to avoid perpetual re-creation.

If the 2D side is working as expected I'll see if there's something I 
can do along the lines
of a quick check every time that the number of underlying printers is 
the same and then if not it is worthwhile,

coupled with a refresh every 2 minutes so it should never get too stale.

-phil.

On 6/7/22 11:39 AM, Tobias Oelgarte wrote:
Is there some way to update the ObservableSet of Printers once the 
Application is running? Calling Printer.getAllPrinters() always 
returns the same OberservableSet and it does not change - ever. [1]


We have an JavaFx based application running under Windows 10/11 that 
is used to print on wireless printers, that are not always available. 
Having to restart the the application every time a printer goes away 
or comes available is a serious pain for the users.


Is there any kind of workaround?

I doubt it will be fixed in the near future, since this comment is 
from 6 years ago [2]:


    // This is static. Eventually I want it to be dynamic, but first
    // it needs to be enhanced to only create new instances where
    // there really has been a change, which will be rare.

[1] 
https://stackoverflow.com/questions/38470568/javafx-doesnt-detect-changes-of-available-printers


[2] 
https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java#L99

Re: Question about fatal JavaFX crashes

[Philip Race]

I have at least seen  JIT compiler crashes like this in other unrelated 
cases ..


in theory you can use an option like

-XX:CompileCommand=exclude,javafx/scene/control/TableView$5::onChanged

although I am very unsure about the syntax for the last part of it 
especially with what looks like
some anonymous method or lambda expression. I can almost guarantee that 
my example is wrong.


Excluding the whole of TableView might be easier to specify but will 
slow you down a lot.


-phil.


On 3/18/22 10:37 AM, Kevin Rushforth wrote:
Thanks, Phil. That was my take as well. I don't see how this can be a 
JavaFX bug given where it is crashing. FWIW, I haven't ever seen 
anything like this.


-- Kevin


On 3/18/2022 10:25 AM, Philip Race wrote:
I think it is probable that this is a hotspot VM problem in the C2 
JIT compiler code.


I've moved your bug report to hotspot : 
https://bugs.openjdk.java.net/browse/JDK-8283386

The interesting question isn't about which version of FX used to work.
It is what was the last working version of the JDK.
It looks a bit like a JDK 17 bug from the evidence so far so if
you were running FX 17 on JDK 17 GA you maybe have picked up a later 
update release  of JDK 17 along with FX 18 ??


Regardless this doesn't look like an FX bug.
But unless you can actually provide a test case, or, by luck the 
hotspot folks recognise the issue,

I don't know what can/will happen.

-phil.

On 3/18/22 7:08 AM, Daniel Peintner wrote:

Hi John, all,

Thanks for your detailed reply.
I submitted a bug report with detailed information.

- Run a different Java version
I tried different versions and vendors with the same result.
* OpenJDK 17.0.1
* Zulu 17.0.2
* I wanted to check also JDK18-ea but gradle does not yet support it



- Try switching to a different GC
- Use different VM options (are you using anything special?)
- Anything else that is not often used, non-standard or experimental,
try going to a more common setup


I use no specific setting, all is default.
I have been reading that the -client flag might help in some cases but
unfortunately this flag is no longer taken into account for 64bit JVMS.

Thanks,

-- Daniel





--John

On 18/03/2022 09:43, Daniel Peintner wrote:

Hello,

I take the liberty to ask on the email reflector if there are other

people

with similar problems.

Since updating my application to JavaFX18 I get random fatal crashes.
Unfortunately it is not predictable but after some time the app 
crashes

with "EXCEPTION_ACCESS_VIOLATION".

The hs_error_pidX reports the following.


---  T H R E A D  ---

Current thread (0x016be9c9b410):  JavaThread "C2 CompilerThread0"
daemon [_thread_in_native, id=3068,
stack(0x00393e80,0x00393e90)]

Current CompileTask:
C2:10515286 18185   4

  javafx.scene.control.TableView$5::onChanged

(1049 bytes)


Am I the only one seeing this?
I am not sure if this relates to changing JavaFX 17 to 18 or 
whether it

makes it just more likely.

It seems to be related to 
"javafx.scene.control.TableView$5::onChanged"

since all crashes show this line.

Having said that, I cannot provide a test-case since it happens 
all of a

sudden and sometimes after hours using the application.

I am open to any feedback or input on how to proceed best.

Thanks!

-- Daniel

Re: Question about fatal JavaFX crashes

[Philip Race]

I think it is probable that this is a hotspot VM problem in the C2 JIT 
compiler code.


I've moved your bug report to hotspot : 
https://bugs.openjdk.java.net/browse/JDK-8283386

The interesting question isn't about which version of FX used to work.
It is what was the last working version of the JDK.
It looks a bit like a JDK 17 bug from the evidence so far so if
you were running FX 17 on JDK 17 GA you maybe have picked up a later 
update release  of JDK 17 along with FX 18 ??


Regardless this doesn't look like an FX bug.
But unless you can actually provide a test case, or, by luck the hotspot 
folks recognise the issue,

I don't know what can/will happen.

-phil.

On 3/18/22 7:08 AM, Daniel Peintner wrote:

Hi John, all,

Thanks for your detailed reply.
I submitted a bug report with detailed information.

- Run a different Java version
I tried different versions and vendors with the same result.
* OpenJDK 17.0.1
* Zulu 17.0.2
* I wanted to check also JDK18-ea but gradle does not yet support it



- Try switching to a different GC
- Use different VM options (are you using anything special?)
- Anything else that is not often used, non-standard or experimental,
try going to a more common setup


I use no specific setting, all is default.
I have been reading that the -client flag might help in some cases but
unfortunately this flag is no longer taken into account for 64bit JVMS.

Thanks,

-- Daniel





--John

On 18/03/2022 09:43, Daniel Peintner wrote:

Hello,

I take the liberty to ask on the email reflector if there are other

people

with similar problems.

Since updating my application to JavaFX18 I get random fatal crashes.
Unfortunately it is not predictable but after some time the app crashes
with "EXCEPTION_ACCESS_VIOLATION".

The hs_error_pidX reports the following.


---  T H R E A D  ---

Current thread (0x016be9c9b410):  JavaThread "C2 CompilerThread0"
daemon [_thread_in_native, id=3068,
stack(0x00393e80,0x00393e90)]

Current CompileTask:
C2:10515286 18185   4

  javafx.scene.control.TableView$5::onChanged

(1049 bytes)


Am I the only one seeing this?
I am not sure if this relates to changing JavaFX 17 to 18 or whether it
makes it just more likely.

It seems to be related to "javafx.scene.control.TableView$5::onChanged"
since all crashes show this line.

Having said that, I cannot provide a test-case since it happens all of a
sudden and sometimes after hours using the application.

I am open to any feedback or input on how to proceed best.

Thanks!

-- Daniel

Re: Moving discussions to GitHub?

[Philip Race]

I am not sure that openjfx as an openjdk sponsored project can 
unilaterally decide this.

Nor sure that it makes sense either to be different.
And I've not felt the same disconnection you cite or have any idea why
this would be better or even match how we work.


-phil.

On 8/19/21 5:50 PM, Michael Strauß wrote:

With the GitHub Discussions feature now out of beta*, I'd like to
start a conversation on whether it could be a good idea for the
OpenJFX project to embrace it as the primary place to discuss and
interact with the broader community.

While I understand that mailing lists have a long tradition with
OpenJDK projects, I feel that they are not a great tool for building
and maintaining a community. It's pretty hard to search archived mails
and find relevant information or past discussions. Sure, you can do
it, but it's not very inviting and accessible.

It also seems to me that the mailing list is very disconnected from
the people actually using OpenJFX. Since most people already are on
GitHub, and most people interested in OpenJFX will find its GitHub
repository, it would also seem to be the most logical place to invite
people into the community and join our discussions.

After all, growing and maintaining a community is fundamental for
every open-source project to remain relevant.

* https://github.blog/2021-08-17-github-discussions-out-of-beta

Re: Enhancements for JavaFX 18

[Philip Race]

Well .. if you know you were the reporter, then it narrows down the JBS 
search from thousands to less than 10 :-)


https://bugs.openjdk.java.net/browse/JDK-8092298

Near as I can tell, that is an issue where we are comparing the FX use 
of DirectWrite with
unknown usage and configuration of some Windows bundled apps and maybe 
we aren't

even sure it is the same font ..  there was a lot of back and forth there.

-phil.

On 8/10/21 3:56 AM, Pedro Duque Vieira wrote:
I've filed the bug a long time ago so I can't remember exactly the bug 
ID or the title I gave it.


Do you want me to file a new one? Do you want me to attach sample 
images (I think you need to do some work around to attach images to a 
javafx bug report?)?


Thanks Philip

On Mon, Aug 9, 2021 at 4:06 PM Philip Race <mailto:philip.r...@oracle.com>> wrote:


That would be a separate piece of work.  I can't imagine much if
any overlap.
Is there a useful bug ID for what you are referring to ?
The glyph images come from DirectWrite on Windows so I am not sure
if there's something specific ..

-phil.

On 8/9/21 3:44 AM, Pedro Duque Vieira wrote:

Hi!

@Phil Race <mailto:philip.r...@oracle.com> If you're going to
tackle font rendering, would it also be possible to work on
Windows font rendering? I find that Windows font rendering is
generally much worse than Mac's.

One example is, for instance, trying to render "Segoe UI" (the
Windows default font) , or "Segoe UI Light"  font (or whatever
variant) with a big font size. The font appears pixelated..

Thanks,

+1. It is something I intend to get to for 18.


-phil.


On 8/4/21 1:10 PM, Kirill Grouchnikov wrote:
> May I humbly suggest fixing font rendering color fringe
issues on macOS


-- 
Pedro Duque Vieira - https://www.pixelduke.com

<https://www.pixelduke.com>




--
Pedro Duque Vieira - https://www.pixelduke.com <https://www.pixelduke.com>

Re: Enhancements for JavaFX 18

[Philip Race]

That would be a separate piece of work.  I can't imagine much if any 
overlap.

Is there a useful bug ID for what you are referring to ?
The glyph images come from DirectWrite on Windows so I am not sure if 
there's something specific ..


-phil.

On 8/9/21 3:44 AM, Pedro Duque Vieira wrote:

Hi!

@Phil Race  If you're going to tackle 
font rendering, would it also be possible to work on Windows font 
rendering? I find that Windows font rendering is generally much worse 
than Mac's.


One example is, for instance, trying to render "Segoe UI" (the Windows 
default font) , or "Segoe UI Light"  font (or whatever variant) with a 
big font size. The font appears pixelated..


Thanks,

+1. It is something I intend to get to for 18.


-phil.


On 8/4/21 1:10 PM, Kirill Grouchnikov wrote:
> May I humbly suggest fixing font rendering color fringe issues
on macOS


--
Pedro Duque Vieira - https://www.pixelduke.com 

Re: Please remove me from your mailing list

[Philip Race]

Unsubscribing is "self-service.
Visit https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
and look near the bottom of the page for the section labelled
"To unsubscribe from openjfx-dev, get a password reminder,
or change your subscription options enter your subscription email address:"
and enter your email address in the field and follow instructions on
subsequent pages to unsubscribe.

-phil.


On 8/5/21 10:08 AM, Yango França de Freitas wrote:

me too


Em qui., 5 de ago. de 2021 às 12:41, Jacopo Benincasa <
mantheprogram...@gmail.com> escreveu:


Please remove me from your mailing list.

Re: Enhancements for JavaFX 18

[Philip Race]

+1. It is something I intend to get to for 18.

-phil.

On 8/4/21 1:10 PM, Kirill Grouchnikov wrote:

May I humbly suggest fixing font rendering color fringe issues on macOS

On Wed, Aug 4, 2021 at 3:54 PM Sebastian Stenzel <
sebastian.sten...@gmail.com> wrote:


+1 for a proper system tray api


Am 04.08.2021 um 16:47 schrieb Scott Palmer :

+1 to that.

I would also like to see some progress with system tray support and

microphone & webcam access.

Scott


On Aug 4, 2021, at 7:07 AM, Jeanette Winzenburg <

faste...@swingempire.de> wrote:


my suggestion would be the longstanding commit-edit-on-focus-lost -

solved by an enhancement to the editing api on virtualized controls

-- Jeanette

Zitat von Kevin Rushforth :


Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes

and enhancement requests for JavaFX 18. It's the summer, so there may be
delays as some people are out at various times (including me), but I would
like to get some of the outstanding enhancement requests moving over the
next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the

binary incompatible API change)

JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to

proceed)

* Undecorated interactive stage style (still in early discussion, but

the concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on

openjfx-dev rather than a reply to this thread.

-- Kevin

Re: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3]

[Philip Race]

Yes .. we still need to deal with it until it is actually removed. Its 
going to be here for all the life of

JDK 17 LTS which I expect FX will want to support for all that time.

-phil.

On 6/25/21 6:42 PM, Eric Bresie wrote:

security manager

That’s not the same security manager being discussed as being deprecated for 
Java 17 and beyond is it?

Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)


On June 25, 2021 at 4:20:03 PM CDT, Kevin Rushforth mailto:k...@openjdk.java.net)> wrote:
On Thu, 24 Jun 2021 23:00:42 GMT, Phil Race mailto:p...@openjdk.org)> wrote:

Overall the new API and functionality looks good, and fills a void that was 
discussed [in this 
thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-May/023292.html)
 a couple years ago.

General comments:

The first, which is the one we had been discussing, is where the URL is a valid 
file URL, but the program can't write to it, either because we are running with 
a security manager and the application doesn't have permission, or because we 
can't write to the output file (e.g., the path doesn't exist or is read-only).

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

Re: Command Line Tools for Xcode 12.4 → 12.5

[Philip Race]

FWIW this is why I
1) Don't let macOS upgrade my xcode tools automatically
2) Let someone else trail blaze  :-), unless I am ready to do the work 
to make the upgraded tools work.


-phil.

On 6/16/21 9:27 AM, John Neffenger wrote:

Just a heads-up about using the latest Xcode 12.5 ...

Re: [External] : Re: Dependencies on java.desktop

[Philip Race]

Did someone mention my name ?

Implementing FX printing on top of 2D printing was always a pragmatic 
way of delivering in FX 8.

Never something that was done because we wanted to for any reason.

A new native implementation will still cost the same amount of work that 
we put off in JDK 8.

So it needs to be prioritised.

But note that I think it can be done one platform at a time.
So if we did a Windows print implementation javafx.graphics might no 
longer require it on Windows

(at least for printing) but would still need it on macOS.

This is the right long term answer rather than @ConditionalFeature.

-phil.


On 5/18/21 2:40 PM, Kevin Rushforth wrote:
As noted in the thread you quoted below, removing the dependency on 
java.desktop from javafx.base isn't a particularly hard problem, and 
is tracked by JDK-8240844 [1]. And even though it will require a spec 
change (meaning a CSR), it doesn't result in any loss of 
functionality, since in order to usefully do anything with the 
JavaBeanX classes requires java.desktop anyway.


Removing the dependency on java.desktop from javafx.graphics is a 
larger issue because of printing. There is also an implementation 
dependency on the Desktop class to implement 
HostServices::showDocument that would need to be redone. And of course 
it depends on the above (eliminating the dependency from javafx.base) 
being done first.


For printing we would need to do one of two things:

1. Eliminate the implementation dependency on the Java2D printing 
code. This is a large effort, but would preserve existing functionality.


2. Make the JavaFX Printing function "optional" (i.e., make it a 
"ConditionalFeature"), such that if java.desktop is not present, 
printing doesn't work (all of the printing APIs would throw an 
UnsupportedOperationException if java.desktop is not available). An 
application that wants to do printing would need to include java.desktop.


Option 1 would be my preferred approach, but as mentioned above it's a 
lot of work. Option 2 would need a spec change, and I'm not convinced 
we want to do it. If there are enough other developers who would want 
this, we could open it up for discussion for some future version (not 
JavaFX 17).


Phil might have some thoughts on this.

-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8240844


On 5/18/2021 10:45 AM, Tom Schindl wrote:
Uff - I'd like to revisit this topic. As I did some jlink stuff for 
our applications adding java.desktop once more bugged me.


I guess the first thing to do is to file a JIRA-Ticket but it really 
starts to bug me to include java.desktop although I don't plan to use 
printing (and I guess > 90% of the JavaFX don't use the printing API 
either but produce PDFs or whatever) and Java-Beans.


Tom

Am 27.03.18 um 14:26 schrieb Kevin Rushforth:

Hi Tom,

Yes, this is an unfortunate dependency. It is "only" an 
implementation dependency, meaning that nothing in the public API 
depends on java.desktop (which is why we don't "requires transient 
java.desktop"), so it should be possible to remove this dependency 
in the future. As noted, it is only there because Java Beans is part 
of the java.desktop module.


In the interim, your suggestion of "requires static java.base" could 
be the way to go. It would need a spec change to the JavaFX beans 
adapter classes documenting that they would throw an 
UnsupportedOperationException if java.desktop was not present at 
runtime, along with a recommendation that applications needing that 
functionality should add "requires java.desktop" to their own 
module-info.java.


Note that this would only help non-graphical JavaFX applications 
that use javafx.base for its collections, properties, and bindings, 
since javafx.graphics requires java.desktop in a way that currently 
cannot easily be made optional (not without reimplementing printing 
support anyway).


-- Kevin


Tom Schindl wrote:

Hi,

Anyone else has an opinion on that? Is require static the way to go?

Tom

On 21.03.18 23:23, Tom Schindl wrote:

Hi,

I always thought the JavaFX-Codebase should be able to run with 
just the
java.base module but I was browsing the codebase a bit and was 
suprised

(or rather shocked) that even the base-module requires java.desktop.

If I get it correct this because of the java.beans (provided by the
adapters) stuff is found in there. Why hasn't the requires there not
defined as:

requires static java.desktop;

Tom

Re: AArch64 naming conventions

[Philip Race]

FWIW I think on the JDK side folks are converging on aarch64
And also using that name as the "CPU" field in JBS (the alternative 
there being 'arm').

I'd find it easier if it was consistent across all these places.

-phil

On 4/19/21 1:06 PM, Johan Vos wrote:

Recently, we introduced the option (or are introducing the options) to
build OpenJFX for 64-bit ARM CPU's on Mac, Windows and Linux.
However, those 3 platforms use different approaches to deal with this
arch-specific options.
Since the PR's for windows and linux are currently still open, it might be
a good opportunity to decide on a standard approach for dealing with
architecture names in both the build.gradle as well as the
platform-specific gradle files.

We have to take into account that the different external libraries we
include have their own wishes for accepting CPU architecture info, so even
if we standardize internally on a specific name, conversions will still be
needed when invoking e.g. building media libraries.

See https://github.com/openjdk/jfx/pull/439 for the windows general build
PR and https://github.com/openjdk/jfx/pull/467 for the Linux media PR.

I am personally not really happy myself with how I deal with it in PR #467,
as I would like to have a single "TARGET_ARCH" parameter that specifies the
target architecture (also in case we are cross-compiling), rather than
doing specific checks on different locations -- but that require a bigger
refactory and I'd like to hear more opinions before doing that.

I am very open to naming conventions (e.g. arm64 or aarch64), but I can
imagine different people have different opinions.

- Johan

Re: Not really a nice comment but a real issue?

[Philip Race]

I am informed that, for no reason given, the corporate IT folks will not 
allow attachment upload.


Attempts over the years to persuade them otherwise have failed.

The best suggestion is you upload it somewhere else and include the link 
in the bug report and

the Oracle reviewer can grab it.

I've suggested we add that suggestion - at least to the FAQ item about 
attachments - if not

more prominently.

https://bugs.java.com/bugdatabase/faq.do#faq-7

-phil.

On 3/19/21 12:37 PM, Philip Race wrote:
Interesting that there's no way to add an attachment (image or 
otherwise).

I'll ask why that can't be made possible.

-phil.

On 3/19/21 12:23 PM, John Neffenger wrote:

On 3/19/21 11:05 AM, Philip Race wrote:
If this was important to him I don't understand why just a blog post 
and not a bug report ..


If I had to guess, it might be because, in the age of GitHub, this is 
not what people expect when they try to report a bug:


Report a Bug or Request a Feature
https://bugreport.java.com/bugreport/

There are two main problems:

1. You can't attach images.

Re: Not really a nice comment but a real issue?

[Philip Race]

It was a P4 enhancement. I've made it a bug .. this or the new one 
should be closed as a dup.
Normally I'd close the new one but not so clear here. I'll leave it to 
Kevin to choose.


-phil.

On 3/20/21 11:54 AM, Philip Race wrote:


Ah, I missed that. And with that, I've now found Gary's bug : 
https://bugs.openjdk.java.net/browse/JDK-8239138


-phil.

On 3/20/21 10:36 AM, Pedro Duque Vieira wrote:

Hi Philip,

Gary Bentley is the blog owner and author of the post. Scott Palmer 
is commenting on Gary Bentley's blog post.
I was talking about Gary Bentley's comment to Scott Palmer's asking 
why he didn't file an issue.


*Scott Palme*r: "/It’s Open Source… submit an issue and a pull 
request to at least fix the performance."/

And Gary Bentley the author of the blog replied:
*Gary Bentley*:".../I did raise this issue at the time, I raised a 
bug./"/.
                      "...There is a rendering issue with WebView in 
13+ versions that I also need to raise."/



Cheers,

On Sat, Mar 20, 2021 at 5:12 PM Philip Race <mailto:philip.r...@oracle.com>> wrote:


Actually the way I read it, Scott Palmer added a comment with a
link to the 2014 change that *introduced* the problem.
No one is saying they reported this performance issue in 2014.

-phil.

On 3/20/21 7:37 AM, Pedro Duque Vieira wrote:

Back to the discussion on why did the blog poster not raise an
issue for the problems he mentioned...

Just FYI (in case you didn't see his recents comments), it
appears he did. He says he did it in a recent comment on his
blog post (yesterday):

https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/#comment-464

<https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/#comment-464>.
He says he filed an issue in 2014.

Cheers,


-- 
Pedro Duque Vieira - https://www.pixelduke.com

<https://www.pixelduke.com>




--
Pedro Duque Vieira - https://www.pixelduke.com 
<https://www.pixelduke.com>

Re: Not really a nice comment but a real issue?

[Philip Race]

Ah, I missed that. And with that, I've now found Gary's bug : 
https://bugs.openjdk.java.net/browse/JDK-8239138


-phil.

On 3/20/21 10:36 AM, Pedro Duque Vieira wrote:

Hi Philip,

Gary Bentley is the blog owner and author of the post. Scott Palmer is 
commenting on Gary Bentley's blog post.
I was talking about Gary Bentley's comment to Scott Palmer's asking 
why he didn't file an issue.


*Scott Palme*r: "/It’s Open Source… submit an issue and a pull request 
to at least fix the performance."/

And Gary Bentley the author of the blog replied:
*Gary Bentley*:".../I did raise this issue at the time, I raised a 
bug./"/.
                      "...There is a rendering issue with WebView in 
13+ versions that I also need to raise."/



Cheers,

On Sat, Mar 20, 2021 at 5:12 PM Philip Race <mailto:philip.r...@oracle.com>> wrote:


Actually the way I read it, Scott Palmer added a comment with a
link to the 2014 change that *introduced* the problem.
No one is saying they reported this performance issue in 2014.

-phil.

On 3/20/21 7:37 AM, Pedro Duque Vieira wrote:

Back to the discussion on why did the blog poster not raise an
issue for the problems he mentioned...

Just FYI (in case you didn't see his recents comments), it
appears he did. He says he did it in a recent comment on his blog
post (yesterday):

https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/#comment-464

<https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/#comment-464>.
He says he filed an issue in 2014.

Cheers,


-- 
Pedro Duque Vieira - https://www.pixelduke.com

<https://www.pixelduke.com>




--
Pedro Duque Vieira - https://www.pixelduke.com <https://www.pixelduke.com>

Re: Not really a nice comment but a real issue?

[Philip Race]

Oracle has a very different mind set about privacy than Google or Facebook.
It might be very hard to convince the powers that be to add a "please 
sell my personal information" checkbox ..


-phil.

On 3/20/21 8:16 AM, Abossolo Foh Guy wrote:

I'm surprised credit is considered important ... .


You're right, but for some of your external contributors it's a 
business model useful to communicate with their employers or patrons. 
I tried to explain it in a Twitter post but without success :) GitHub 
is like a vitrine where one can see the community working. To be 
credited in the reprository is personnal satisfaction but it's also 
like receiving "java-coins", a win-win strategy without additional 
work from the owner since a gauge shows each contributor activity.



But FX never used the github bug tracker. ...
https://github.com/javafxports/openjdk-jfx, did. A really amazing 
experience ! The new repository closed this first open window :(


Guy.

------ 



Le 2021-03-19 20:37, Philip Race a écrit :
Interesting that there's no way to add an attachment (image or 
otherwise).

I'll ask why that can't be made possible.

I'm surprised credit is considered important but I think that the
current way of doing things is
more focused on protecting privacy of bug reporters and that they
might instead want their email addresses advertised
will quickly run into problems getting past that.
There's even an assurance on the bug submission form that your
personal info won't be shared.

But FX never used the github bug tracker. It should never have been
possible to submit bugs there.


-phil.

On 3/19/21 12:23 PM, John Neffenger wrote:

On 3/19/21 11:05 AM, Philip Race wrote:
If this was important to him I don't understand why just a blog 
post and not a bug report ..


If I had to guess, it might be because, in the age of GitHub, this 
is not what people expect when they try to report a bug:


Report a Bug or Request a Feature
https://bugreport.java.com/bugreport/

There are two main problems:

1. You can't attach images.

2. You don't get credit.

I speak from experience. I spent five years frustrated with a JavaFX 
font bug, but it was only when I could properly format a report and 
include images that I bothered to open this issue:


Reduce color fringes in FreeType subpixel rendering
https://github.com/javafxports/openjdk-jfx/issues/229

Formatting and images shouldn't matter, but two other people tried 
to report that bug using the Oracle Web form, and both were closed 
as "Not an Issue." You can send images later by e-mail, eventually, 
but that's not explained anywhere.


There was a brief window when the OpenJFX project accepted bug 
reports on GitHub, but now it's back to the Oracle Web form. That 
brief window is the reason I'm a contributor to the project now. I 
understand the need for gate-keeping. We just shouldn't be too 
surprised when people decide that the gate's too high.


I think Oracle could fix the two problems and keep the Web form, and 
we might get more quality bug reports instead of frustrated blog 
posts. I also think that it would help a lot to enable the JIRA 
markup[1] in the Java Bug System as Apache NetBeans has done. As an 
example, I can't imagine trying to report a bug like the following 
without formatting or in-line images:


Attaching JavaFX Javadoc and Sources
https://issues.apache.org/jira/browse/NETBEANS-3296

John

[1] 
https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all

Re: Not really a nice comment but a real issue?

[Philip Race]

Actually the way I read it, Scott Palmer added a comment with a link to 
the 2014 change that *introduced* the problem.

No one is saying they reported this performance issue in 2014.

-phil.

On 3/20/21 7:37 AM, Pedro Duque Vieira wrote:
Back to the discussion on why did the blog poster not raise an issue 
for the problems he mentioned...


Just FYI (in case you didn't see his recents comments), it appears he 
did. He says he did it in a recent comment on his blog post 
(yesterday): 
https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/#comment-464 
.

He says he filed an issue in 2014.

Cheers,


--
Pedro Duque Vieira - https://www.pixelduke.com 

Re: Not really a nice comment but a real issue?

[Philip Race]

Interesting that there's no way to add an attachment (image or otherwise).
I'll ask why that can't be made possible.

I'm surprised credit is considered important but I think that the 
current way of doing things is
more focused on protecting privacy of bug reporters and that they might 
instead want their email addresses advertised

will quickly run into problems getting past that.
There's even an assurance on the bug submission form that your personal 
info won't be shared.


But FX never used the github bug tracker. It should never have been 
possible to submit bugs there.



-phil.

On 3/19/21 12:23 PM, John Neffenger wrote:

On 3/19/21 11:05 AM, Philip Race wrote:
If this was important to him I don't understand why just a blog post 
and not a bug report ..


If I had to guess, it might be because, in the age of GitHub, this is 
not what people expect when they try to report a bug:


Report a Bug or Request a Feature
https://bugreport.java.com/bugreport/

There are two main problems:

1. You can't attach images.

2. You don't get credit.

I speak from experience. I spent five years frustrated with a JavaFX 
font bug, but it was only when I could properly format a report and 
include images that I bothered to open this issue:


Reduce color fringes in FreeType subpixel rendering
https://github.com/javafxports/openjdk-jfx/issues/229

Formatting and images shouldn't matter, but two other people tried to 
report that bug using the Oracle Web form, and both were closed as 
"Not an Issue." You can send images later by e-mail, eventually, but 
that's not explained anywhere.


There was a brief window when the OpenJFX project accepted bug reports 
on GitHub, but now it's back to the Oracle Web form. That brief window 
is the reason I'm a contributor to the project now. I understand the 
need for gate-keeping. We just shouldn't be too surprised when people 
decide that the gate's too high.


I think Oracle could fix the two problems and keep the Web form, and 
we might get more quality bug reports instead of frustrated blog 
posts. I also think that it would help a lot to enable the JIRA 
markup[1] in the Java Bug System as Apache NetBeans has done. As an 
example, I can't imagine trying to report a bug like the following 
without formatting or in-line images:


Attaching JavaFX Javadoc and Sources
https://issues.apache.org/jira/browse/NETBEANS-3296

John

[1] 
https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all

Re: Not really a nice comment but a real issue?

[Philip Race]

Sadly it has taken > 1 year for his blog post to reach the right audience.
If this was important to him I don't understand why just a blog post and 
not a bug report ..

The buffering at least seems like a quick fix.

-phil.

On 3/19/21 9:34 AM, Dirk Lemmermann wrote:

I took the liberty of informing the author of the blog. It was hard not to 
comment on the tone he used ….. but we all know that never leads to anything. 
Let the facts speak for themselves and they tell him that he was heard and his 
findings resulted in tickets and hopefully fixes soon.

Dirk


On Mar 19, 2021, at 5:29 PM, Kevin Rushforth  wrote:

https://bugs.openjdk.java.net/browse/JDK-8263886

On 3/19/2021 9:17 AM, Kevin Rushforth wrote:

That's an interesting idea about looking at the HTTP response headers and 
checking to see whether the file has changed. If it could be done in such a way 
that it minimizes overhead, it might be the best of both worlds. I'll file an 
RFE to look into that...not sure we'll get time to do it, though, so if someone 
from the community wants to take it, that would help.

Regarding an "opt out" mechanism, If someone wants to propose an API to do that, we'd be happy to 
consider it (as with the above, it will be more likely to get done if someone volunteers to drive it to 
completion). The main question I can think of that would need to be answered is: what should be the 
granularity of the new boolean attribute? Global (probably on Platform then)? Per Scene? Per Region (which 
would also need to be on the Scene with Region overriding it)? Another is around what the behavior should be 
of setting it from "false" back to the (default) "true".

-- Kevin


On 3/19/2021 9:08 AM, Richard Bair wrote:

Hey everybody!

These all sound like really good points. I agree with Pedro that the ability to 
auto-reload (especially during development) is a really great thing, but I 
agree with the blog post and Clemens that in production this can be problematic 
depending on the location of the source CSS file, and in any event does 
introduce some performance overhead that would be nice to avoid.

Could JavaFX look at response headers when loading CSS over HTTP/S to determine 
whether the CSS file can be cached and then maintain a local cache for such CSS 
files? That would resolve one particular issue where CSS is loaded remotely. 
Could JavaFX use a different mechanism for watching the CSS files when loaded 
from disk so that it isn’t re-read every time but only when a change had been 
detected? I think both of those enhancements could probably be done while 
remaining consistent with the existing semantics. Add the Bug fix in that Kevin 
mentioned and I think most of the practical problems raised by the blog post 
would be fixed.

Cheers
Richard


On Mar 19, 2021, at 8:34 AM, Pedro Duque Vieira  
wrote:

In the blog post he makes it sounds like it isn't good for anything to have
that. That it is just a bug, something that wasn't well thought through and
reviewed or a pointless feature. Which I totally disagree with. I think it
can be very interesting to take advantage of that.

I think the performance problem he measured was more about the buffering
issue than about dynamically reloading the stylesheet whenever there's a
change. But yeah, this might have a performance impact. If there is indeed
a considerable impact, perhaps we could have a flag to opt out of this
feature. That way we can have the best of both worlds and not have this
feature impact the apps performance in production.

Cheers,


A good feature during development is not necessarily a good feature during

production, especially if it (apparently) has a significant performance
impact.
But I see your point.

On 19-3-2021 15:32, Pedro Duque Vieira wrote:

Hi

I actually totally disagree with his conclusion.

In fact, I'd say, that's one of the hidden gems of JavaFX!
Check out CSSFX and this video

https://www.youtube.com/watch?v=RELKg32xEWU

to understand the advantages of this feature (ScenicView has also
integrated CSSFX to take advantage of this).

Think about the productivity boost of tweaking your UI at runtime and not
having to go through the cycle: tweak UI -> compile -> run -> (No that's
not it) -> close app -> tweak UI again -> compile again -> run again ->

(No

that's not it again) -> [repeat till infinity]

Also think about the potential for adding tools that build on top of this
feature. Tools like firebug or features from Chrome developer tools, etc,
that they use on the web to debug / tweak UIs during runtime.

Cheers,



On 19-3-2021 14:29, Clement Levallois wrote:

Hi all,

I just came across this blog post which complains about a badly

implemented stream reader in JavaFX. The general tone is not nice, but I
figured this could be useful to the developers maintaining this area:

https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/

Best regards,

Clement
PS: I landed on this blog post because I was searching for some

pointers

Re: Request to backport to JavaFX 11 (11.0.10)

[Philip Race]

Kevin is out until Monday, but you can have a thumbs up from me if that 
counts.


-phil.

On 11/25/20, 8:54 AM, Johan Vos wrote:

Hi Kevin,

I request permission to backport the following issues to JavaFX 11 (for
JavaFX 11.0.10)

JDK-8177945: Single cell selection flickers when adding data to TableView
JDK-8199592: Control labels truncated at certain DPI scaling levels

Both patches apply clean.

- Johan

Re: CFV: New OpenJFX Committer: Pankaj Bansal

[Philip Race]

Vote: yes

-phil.

Re: [jfx15] RFR: Request to sync July 2020 CPU changes into jfx

[Philip Race]

+1

-phil

On 7/14/20, 10:10 AM, Johan Vos wrote:

Approved.

On Tue, Jul 14, 2020 at 6:12 PM Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:


Johan and Phil,

I request approval to sync changes from to the just-released July
2020
CPU release into the 'jfx15' branch of the 'jfx' repo. Here is the
aggregate set of changes for the fixes:

https://github.com/kevinrushforth/jfx/compare/e2d1c02...cpu-2007-sync

NOTE: Since this is an integration of already-reviewed fixes into the
jfx15 branch of the jfx repo, I will push it directly rather than
via a
pull request.

-- Kevin

Re: OpenJFX: Follow HiDPI Scaling Settings in Fedora Workstation 32 (Gnome)

[Philip Race]

Although we only support integer scaling on Linux you have 200% which should 
work.
So sounds like it could be a breaking change in Fedora, where it passes around 
/ defines
the scale in some new setting and doesn't set the old ones needed for 
compatibility.



 (either via gsettings or the GDI_SCALE  env variable)


GDK_SCALE, not GDI_SCALE

-phil



On 6/18/20, 5:12 AM, Kevin Rushforth wrote:
We will need a new bug ID for this (we never reuse a bug ID for which 
a commit has been pushed). You can file a new bug, mentioning 
JDK-8137050 in the Description, at:


https://bugreport.java.com/

Question for other Linux users on this list: are any of you using a 
Linux machine with Hi-DPI scaling? Is it detecting it properly or do 
you have to set the scaling property (either via gsettings or the 
GDI_SCALE env variable)  yourself?


-- Kevin


On 6/18/2020 1:51 AM, wurstsem...@mailbox.org wrote:

Dear OpenJFX Developers,

on Fedora 32 Workstation (Gnome) the AppImage from Cryptomator
(cryptomator.org) does not follow the system-wide scale settings from
Gnome Settings.

*System Setup
Linux: Fedora Workstation 32 (Gnome)
Hardware: Dell XPS 13 with HiDPI (200 % scaling)
Cryptomator version: 1.5.5-x86_64 AppImage

*Expected Behavior
App window should scale according to system-wide settings.

*Actual Behavior
App window scales at 100 %.

*Two workarounds exist:
$gsettings set org.gnome.desktop.interface scaling-factor 2
$GDK_SCALE=2 ./cryptomator-1.5.5-x86_64.AppImage

According to the developers from Cryptomator (see
https://github.com/cryptomator/cryptomator/issues/1242#issuecomment-643095195 


) this is a bug which was intended to be fixed with
https://bugs.openjdk.java.net/browse/JDK-8137050. However, the bug
still occurs in OpenJFX 14.0.1 and 11.

I am happy to help if anything is unclear. Please re-open the bug JDK-
8137050 and make OpenJFX follow the system-wide scaling settings in
Gnome.

Thank you!

wurstsemmel

Re: CFV: New OpenJFX Reviewer: Nir Lisker

[Philip Race]

Vote: yes.

-phil.

Re: CFV: New OpenJFX Committer: Jose Pereda

[Philip Race]

Vote: yes

-phil

Re: CFV: New OpenJFX Committer: Jeanette Winzenburg

[Philip Race]

Vote: yes

-phil

Re: Arabic letters are not displayed correctly in MacOS 10.15.3

[Philip Race]

From https://jdk.java.net/15/ ?

-phil.

On 5/29/20, 5:53 AM, Abu Abdullah wrote:

openjdk version "15-ea" 2020-09-15
OpenJDK Runtime Environment (build 15-ea+24-1168)
OpenJDK 64-Bit Server VM (build 15-ea+24-1168, mixed mode, sharing)

Re: Arabic letters are not displayed correctly in MacOS 10.15.3

[Philip Race]

On 5/29/20, 5:38 AM, Kevin Rushforth wrote:



CoreText note: Client requested name ".ArabicUIText-Regular", it will
get Times-Roman rather than the intended font. All system UI font
access should be through proper APIs such as
CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].

I can see in the console this message:

What JDK are you running? This looks like it is caused by 
https://bugs.openjdk.java.net/browse/JDK-8244621 which affects JDKs 
built with Xcode 11 / MacOSX SDK 10.15.


That message would only appear from the JDK side if you do something to 
execute
some Java 2D code *and* - as Kevin said have a JDK from somewhere that 
is also using

that newest Xcode.

But I haven't heard anything from Abu that says his app uses Swing 
Interop for example ...


Abu: does it ? And where did you get JDK ?

BTW I should add that because this message says .ArabicUIText-Regular" I 
am expecting
that you'll be reporting you are running with Arabic as the preferred 
system language ..


-phil.

Re: Arabic letters are not displayed correctly in MacOS 10.15.3

[Philip Race]

The interesting thing about you seeing :

I can see in the console this message:
CoreText note: Client requested name ".ArabicUIText-Regular", it will
get Times-Roman rather than the intended font. All system UI font
access should be through proper APIs such as
CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].


Is that this message should be *prevented* by the very fix that I see as 
introducing the problem.

So I don't understand that at all.

So I think there are a few variables here.

1. The version of macOS

2. The version of Xcode / SDK used to create the build.
I am not sure what the version on Maven used but I'm sure its not 
the same

version I am using.

3. The system locale as set by preferred language + region.
   What is this for you ?

-phil.

On 5/28/20, 11:09 PM, Abu Abdullah wrote:

On Fri, May 29, 2020 at 9:46 AM Philip Race  wrote:

Ok. you said in the first post :

im using jfx 15-ea-5 on MacOS 10.15.3

Where did you get that build ?

from maven


org.openjfx
javafx-controls
15-ea+5
mac

Re: Arabic letters are not displayed correctly in MacOS 10.15.3

[Philip Race]

Ok. you said in the first post :

im using jfx 15-ea-5 on MacOS 10.15.3

Where did you get that build ?

-phil

On 5/28/20, 5:50 PM, Abu Abdullah wrote:

On Fri, May 29, 2020 at 1:21 AM Philip Race  wrote:

Looks like this is not a Catalina problem. It is a regression in openjfx 14 on 
macOS.
And it is caused by https://bugs.openjdk.java.net/browse/JDK-8234916

I can see in the console this message:
CoreText note: Client requested name ".ArabicUIText-Regular", it will
get Times-Roman rather than the intended font. All system UI font
access should be through proper APIs such as
CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].


We have filed a new bug : https://bugs.openjdk.java.net/browse/JDK-8246104

Thank you

i can see a comment about the differences between Windows and mac. To
me, the difference is about the font type. in Windows it is Tahoma, in
Mac it seems Times-Roman

Re: Arabic letters are not displayed correctly in MacOS 10.15.3

[Philip Race]

Looks like this is not a Catalina problem. It is a regression in openjfx 
14 on macOS.

And it is caused by https://bugs.openjdk.java.net/browse/JDK-8234916

We have filed a new bug : https://bugs.openjdk.java.net/browse/JDK-8246104

-phil.

On 5/27/20, 9:00 AM, Abu Abdullah wrote:

On Wed, May 27, 2020 at 7:53 PM Philip Race  wrote:

Is Latin displaying correctly for you ?

yes, the GUI contains just few words in English which seems to be OK


I can't see anything at all in that screen shot that looks likely to be
correct,
but I also don't know if it is supposed to be entirely Arabic or a
mixture of scripts,
although clearly it is all laid out RTL.

entirely in Arabic. please find snap shot on how it should be (taken in Windows)
https://ibb.co/bv74qnK


In an arm-wavy sort of way, it looks like there's a mismatch between
the selected font and the glyph ids.  whether its the font that's wrong
or the id is impossible to say ..

I tried that as well. nothing changes if i changed the font using the tinkertool

Re: Arabic letters are not displayed correctly in MacOS 10.15.3

[Philip Race]

>  I tried that as well. nothing changes if i changed the font using 
the tinkertool


Not sure what you did but it is probably more complex than that.
Arabic is likely supported by one of the cascading fallback fonts macOS 
reports,

although it could be via a primary if locale is Arabic.

-phil.

On 5/27/20, 9:00 AM, Abu Abdullah wrote:

On Wed, May 27, 2020 at 7:53 PM Philip Race  wrote:

Is Latin displaying correctly for you ?

yes, the GUI contains just few words in English which seems to be OK


I can't see anything at all in that screen shot that looks likely to be
correct,
but I also don't know if it is supposed to be entirely Arabic or a
mixture of scripts,
although clearly it is all laid out RTL.

entirely in Arabic. please find snap shot on how it should be (taken in Windows)
https://ibb.co/bv74qnK


In an arm-wavy sort of way, it looks like there's a mismatch between
the selected font and the glyph ids.  whether its the font that's wrong
or the id is impossible to say ..

I tried that as well. nothing changes if i changed the font using the tinkertool

Re: Arabic letters are not displayed correctly in MacOS 10.15.3

[Philip Race]

Is Latin displaying correctly for you ?
I can't see anything at all in that screen shot that looks likely to be 
correct,
but I also don't know if it is supposed to be entirely Arabic or a 
mixture of scripts,

although clearly it is all laid out RTL.

In an arm-wavy sort of way, it looks like there's a mismatch between
the selected font and the glyph ids.  whether its the font that's wrong
or the id is impossible to say ..

-phil.

On 5/27/20, 12:50 AM, Abu Abdullah wrote:

Hi,

i have started testing my app using Javafx on MacOS 10.15.3 and arabic
letters are not displayed correctly. only title bar is correct. the
rest are just random characters (not arabic). please have a look at
the snapshot:
https://ibb.co/Yk6m3Pj

im using jfx 15-ea-5 on MacOS 10.15.3

normal swing application is working fine without issues

Re: Font rendering issue on macOS - cut off characters

[Philip Race]

I completely forgot we had that report.
I think it describes all the same things discussed here.

So it is a catalina issue, not a regression, and it
is retina & non-retina, but the various consequences
are more apparent on non-retina, and only on non-retina
are we seeing the cut-off glyphs.

Hmm. Some of the glyphs are grey scale. I wonder
if all of the glyphs are grey scale but in LCD format and something
unintended is happening during rendering with sub-pixel
positioning ? I think we could inadvertently introduce what
is being seen here if we shifted a greyscale 3x oversampled image.
Or maybe something changed in the way macOS is providing subpixel 
positions, which varies according to font size.

We actually cache glyphs rendered at sub-pixel positions so the
final rendering step likely isn't where the (main) problem is
introduced.

-phil.

On 5/25/20, 12:31 PM, proje...@saring.de wrote:

Sounds like the same bug I've already reported to the OpenJFX project: 
https://bugs.openjdk.java.net/browse/JDK-8236689
It occurred for me the first time after updating to macOS 10.15 / Catalina and 
only on non-retina displays.

Unfortunately there was no progress on this bug yet.

Bye, Stefan

Re: Font rendering issue on macOS - cut off characters

[Philip Race]

Mmm .. it can't be the same bug even if the effect is similar.
We don't use freetype on macOS, that's for Linux.

Can you check your display's settings ?

https://spin.atomicobject.com/2018/08/24/macbook-pro-external-monitor-display-problem/

I have a Dell U2412M and it has a menu similar to what he sees and macOS 
for me defaults to RGB,
and selecting YPbYr results in a LOT more problems than text because I 
don't think macOS is
changing the signal when I do - I am connected via displayport too FWIW 
but have an old mac (2015)

and an old OS (10.13.6),

BTW I found the incident (bug report) and I see it is submitted as an FX 
regression

in 14.0.1 when I haven't seen any reason to suggest this is the case.
Isn't everyone seeing it just when they move to catalina ?

Can anyone say if they definitely see it on a built-in retina display too ?

You might also want to check what color profile is set in System 
settings -> Display -> Color.


-phil.


On 5/25/20, 9:44 AM, John Neffenger wrote:

On 5/24/20 4:27 PM, Rob Nikander wrote:
You can see the shaved “o” characters there, but I’m just talking 
about the colors now. Is that normal?


No. I think it's a bug.

See my comment dated May 20, 2020, on the old GitHub issue that 
reported the same bug on Linux in 2018 and was fixed for JavaFX 12.


Yes, it does look as if macOS now has the same problem ...
https://github.com/javafxports/openjdk-jfx/issues/229#issuecomment-631797333 



Dirk Lemmermann opened a new bug report, but I don't know the JDK Bug 
System number yet. I would like see whether I can come up with a fix, 
but I can't say when I'll get to it.


John

Re: Font rendering issue on macOS - cut off characters

[Philip Race]

On 5/24/20, 3:25 PM, Rob Nikander wrote:



On May 24, 2020, at 4:47 PM, Philip Race  wrote:

Should I understand 10.15.4 is the only version of macOS you've tried ?
Not some earlier version of Catalina for example ?

Yes, it’s all I’ve tried.


As to the cause ? I can only speculate. Rounding error in the bitmap size ?
Being over-written by the next glyph (d) - possibly due to some rounding issue 
again ?

If you display just "ao" does it all render ?
That might point to being over-written.

Yes, the “d” appears to be overwriting it. I put the following in a Label: "o 
od o od o od, o od o od o od”. The isolated “o”s are fine, but 4 of 6 of the “o”s 
next to the “d”s are shaved off.

Does JavaFX have its own text rendering engine? It’s not deferring to CoreText 
on macOS?


core text generates all glyph image and all information about it.
But FX uses its own OpenGL code to render the provided glyphs.



The text render seems to have other problems compared to native apps. There is 
a barely-visible color in anti-aliased pixels. It’s so faint I can barely see 
it, but it gives me an unpleasant feeling,


That's likely LCD sub-pixel text. Its normal to see it if you squint. 
Not new.
macOS has been moving away from it but people with non-retina displays 
have lamented its passing.


https://osxdaily.com/2018/09/26/fix-blurry-thin-fonts-text-macos-mojave/

FX still requests LCD tho'. Although it is not clear how long macOS will 
continue to provide it.


-phil.


  like my eyes are having trouble focusing. The macOS has a utility program 
called Digital Color Meter, which lets you see zoomed pixels of the screen. 
Using that, I can see clearly see that while native black on white text is 
black with anti-aliased pixels appearing some shade of gray, as you’d expect; 
the JavaFX black-on-white text has non gray colors in the anti-aliased pixels.

I thought high res screens still used anti-aliasing for text. (?) I wonder if 
this is a fainter problem on retina screens as well. I have no way of checking 
at the moment.

Rob

Re: Font rendering issue on macOS - cut off characters

[Philip Race]

Should I understand 10.15.4 is the only version of macOS you've tried ?
Not some earlier version of Catalina for example ?

Folks *mostly* use retina so it is possible that if it is somewhat 
recently introduced it is specific to non-retina.


As to the cause ? I can only speculate. Rounding error in the bitmap size ?
Being over-written by the next glyph (d) - possibly due to some rounding 
issue again ?


If you display just "ao" does it all render ?
That might point to being over-written.

-phil.

On 5/24/20, 12:28 PM, Rob Nikander wrote:

Hello all,

I just started experimenting with JavaFX and I notice a font rendering problem 
on macOS Catalina 10.15.4, an older (2012) MacBook Pro that does not have a 
“retina” display. As an example, if I create a `Label` with the default font 
and the text “aod”, then the “o” character looks like a “c”. The right side of 
the character is shaved off. Anyone know what is causing this and how to fix it?

Rob

Re: com.sun.javafx vs javafx (with example/request)

[Philip Race]

The current path is defined by the application - you - and yet you don't 
know what it is  ?

You do say
> I have other workarounds where I have to maintain a path as I’m 
drawing in the canvas


Why can't you do that ? No internal API digging.

-phil

On 5/8/20, 12:02 PM, jfx user2 wrote:

Ok, then please consider the GraphicsContext request that I’ve made.  It simply 
enables you to get the Path from the context without exposing com classes at 
all.  I have other workarounds where I have to maintain a path as I’m drawing 
in the canvas or I have to do hit testing on a non vector image to determine 
the path but these are way more expensive than simply creating a Path object 
from the Path2D that is already in the GraphicContext.  That path can be used 
in drag and drop scenarios, fast secondary rendering under heavy gc use, edge 
tracing, and the list goes on.

The same is true for the Shape class.  I’d like to request that the following 
be added to Shape:
public Path getPath() {
 return Shape.createFromGeomShape(getTransformedArea());
}

That’s it.  The underlying methods are there but the public api doesn’t expose 
them.  This gives you a vector outline of the Shape as Path.l on demand, not 
stored.

There are expensive workarounds for performing these tasks and I spent a long 
time trying... until I discovers the private apis already had the capability 
but simply did. It expose it.

I’d these are not supported, I’ll have to stick with reflection,  bytebuddy, or 
forking - non of which will be easily maintained or portable.

Ps I will post additional concerns over time.  The next one likely has to do 
with the mismatch between javafx canvas (gc) and other canvases such as svg, 
html2.  I think there is private api that would help in this case.


On May 8, 2020, at 2:41 PM, Kevin Rushforth  wrote:

Since Canvas is an immediate mode graphics API, I presume you are interested 
in the most recent drawing primitive? (we don't keep the composite shape for 
all drawing primitives -- that would be both too expensive and not really 
appropriate). How would you expect current rendering attributes (e.g., 
transforms) to affect the results? These are all questions that need to be 
addressed.

As for the bigger picture, we intentionally have a separate render graph with 
"peers" for each node, although some of the duplication of classes is 
historical (we used to have a looser decoupling before Prism became the only backend). 
Unless there is a compelling need, we are unlikely to consider changing this in the 
general case, but perhaps could look at specific cases if it made sense. This is a 
separate issue, though, from public API and the two shouldn't be conflated.

Btw, JavaFX has been fully open-sourced since 2013, although the design of 
Prism predates that.

-- Kevin



On 5/8/2020 10:43 AM, jfx user2 wrote:
Kevin, go easy please :0).  There is a need.

Access to the outline of the path in the canvas is great for edge following, 
node attachment points, animating around the non-rectangular border of what’s 
actually displayed, etc.

The other request that I haven’t posted yet is to do the same for Shape.   I’ve 
tested both of these enhancements and it works as desired.  I’ll post the 
second request soon.

But back to the bigger picture.  The requests that I’m making are only 
additions to return a path from javafx not com.  But there are other cases 
where geometry and convenience methods in com would be beneficial to the public 
api.  It also seems odd that there are two layers to begin with...  parallel 
apis often result in too much object creation or cpu overhead translating 
between them.  I’ll be more specific about these cases over time.   Part of my 
intention is to spark a discussion about the design since previously this was 
relatively closed source.


On May 8, 2020, at 1:12 PM, Kevin Rushforth  wrote:

While there is no plan to "open up" more of com.sun.javafx (and that isn't 
really the right way to look at it), if you have a proposed enhancement to the existing 
public javafx.* classes we could discuss it.

As for your specific example, can you say more about what your use case is? The 
GraphicsContext object is a drawing context for a Canvas node, so it is not a natural 
place to put an API that computes or returns a path. I get the sense that you are looking 
at the existing internal implementation classes and saying "how can I get access to 
some information that might be useful to my application" rather than describing what 
your application is trying to do. Once we understand what you are trying to do, we can 
discuss whether the need is general enough to propose adding to the public API of JavaFX 
and what form such a new API might take.

-- Kevin



On 5/8/2020 9:35 AM, jfx user2 wrote:
I am aware of this and that’s why I am asking.  There are useful private 
features in com.sun.javafx and I explained one of them in my message.  I have 
an additional related example but the lar

Re: Working on - JDK-8090423 - [Font] Support Font Weights other than Bold and Regular, like Light

[Philip Race]

I was mulling over why if it is so easy we didn't do it and I suspect
(haven't checked, and so long ago I can't remember off hand) that
this code needed to run on top of the old Java 2D pipeline (wrongly
called the Swing pipeline). And 2D did not and does not provide
this functionality either.

-phil.

On 4/22/20, 3:40 PM, Philip Race wrote:

Sadly no one is working on it.
It probably is not that hard to do, the weight should be in the OS/2 
table


-phil

On 4/22/20, 3:26 PM, Tom Schindl wrote:

Hi Kevin / Phil,

I'd like to start working on JDK-8090423 but before I start investing 
time I wanted to make sure nobody is working on that and if you have 
any input, ideas already how to address that problem help me not 
wasting time.


Tom

Re: Working on - JDK-8090423 - [Font] Support Font Weights other than Bold and Regular, like Light

[Philip Race]

Sadly no one is working on it.
It probably is not that hard to do, the weight should be in the OS/2 table

-phil

On 4/22/20, 3:26 PM, Tom Schindl wrote:

Hi Kevin / Phil,

I'd like to start working on JDK-8090423 but before I start investing 
time I wanted to make sure nobody is working on that and if you have 
any input, ideas already how to address that problem help me not 
wasting time.


Tom

Re: JavaFX controls have large size on Raspberry Pi

[Philip Race]

> I would start by looking at what Font.getDefault().getSize() returns 
since everything should be based off that.


I think the code below is the code that decides what the code above 
should return


> Another thing to check is that the reported DPI of the screen is 
correct.


The way I read the code below is that it wants the default font to be 
1/6 of an inch high on the screen.
I think any smaller than 6 lines per inch and it will be hard to read. 
To do this correctly, it relies on

the y-res being accurate for the device.

So I would follow the path Kevin suggests. For example if something is 
wrongly returning the *dimension* of
the screen when it should be the *dpi* of the screen then you'd have 6 
lines of text filling up the screen.


-phil.

On 4/20/20, 1:56 PM, Kevin Rushforth wrote:

Another thing to check is that the reported DPI of the screen is correct.

-- Kevin


On 4/20/2020 1:25 PM, David Grieve wrote:
The sizes of controls are controlled by CSS styles. Things like 
borders, backgrounds, padding, insets, all of
that defaults to the styles in a stylesheet. Most sizes are 'em' 
units, meaning they are relative to the size
of the font. JavaFX CSS will use the Font.getDefault() font size if 
there is no font explicitly set in either the

styles or in the application code.

I would start by looking at what Font.getDefault().getSize() returns 
since everything should be based off that.

It could also be an issue with the default stylesheets themselves.

-Original Message-
From: openjfx-dev  On Behalf Of 
Alexander Scherbatiy

Sent: Monday, April 20, 2020 2:16 PM
To: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] JavaFX controls have large size on Raspberry Pi

Hello,

I run a simple JavaFX application which shows a button with jdk 
14.0.1 on Raspberry Pi and the drawn button has large size.


This is because of the algorithm which is used by
PrismFontFactory.getSystemFontSize() method [1] to select a system 
font size.

If a system is embedded then the font size is calculated as

  int screenDPI = Screen.getMainScreen().getResolutionY();
  systemFontSize = ((float) screenDPI) / 6f; // 12 points

and the system is detected as embedded because the armv6hf 
architecture is defined as embedded in the armv6hf.gradle file [2].


Raspberri Pi can work both with small touch displays and with big 
monitors. It looks like Raspberry Pi should support two modes for 
font size calculation: one for small screens and another for large.


I would like to contribute a fix for this but I do not know how the 
right fix could look like.
Should there be a special screen size so for smaller screens the font 
is is proportional to the screen size and for bigger screens the font 
size is fixed?

Is there a way to check that used screen is from embedded device?
May be it should be solved in different way?

[1]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsun%2Fjavafx%2Ffont%2FPrismFontFactory.java%23L1944&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=rEz4bxNE07aW5f22AXWPRLNffwoIixvNxJopLM%2Bfbi4%3D&reserved=0 


[2]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2FbuildSrc%2Farmv6hf.gradle%23L182&data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309&sdata=Fv2sKXwfwuo6JsD0CyeoF6iDmq8rDk5goPCsK31p1Sk%3D&reserved=0 



JavaFX application:

import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class ButtonFX extends Application {
  public static void main(String[] args) {
  launch(args);
  }

  @Override
  public void start(Stage primaryStage) {
  primaryStage.setTitle("Hello World!");
  Button button = new Button("Hello, World!");

  StackPane root = new StackPane();
  root.getChildren().add(button);
  primaryStage.setScene(new Scene(root, 300, 250));
  primaryStage.show();
  }
}


Thanks,
Alexander.

Re: Remove JavaFX JPMS enforcement

[Philip Race]

On 4/20/20, 11:18 AM, Bruno Borges wrote:

I do wonder why isn't JavaFX in a single module, like Swing?


For Java developers to build Swing apps, all they need is a "requires
java.desktop".


Well it isn't because we wanted to do that for Swing. It is because it 
was too hard to decompose it
because of interdependencies between AWT and Swing and 2D. For example 
AWT + 2D APIs are

in the same java.awt package.

And Swing is the 99% use case so it would have amounted to using all of 
the same anyway.


But even if it could have been done likely we would still have had an 
aggregator module to make it easy.


Note that java.datatransfer is required by java.desktop.

-phil.

But for JavaFX, there are multiple modules.

---
*Bruno Borges*
brunoborges.io


On Mon, Apr 20, 2020 at 10:36 AM Michael Paus  wrote:


Oh I see. You  are obviously not familiar with the fact that the JDK has
a built-in test
which checks whether the JavaFX graphics module is on the module path
when you
try to launch an application main class which is derived from the JavaFX
Application class.
If you try this and the graphics module is not on the module path the
launch will fail
with an error message. That's the only reason why JavaFX programs cannot
be launched
completely on the classpath and that's where all the trouble starts. If
you circumvent this
test with the trick, I have mentioned before, everything becomes nice
and easy.

So for me there are only two questions.
1. Is there any proof of a technical reason why JavaFX could not run
correctly on the classpath?
2. If there is no such reason, then why do we torture all the newbies
with the "intricacies" of the
module system instead of just removing this barrier?

As I said before, I have not found any such problem in all the time
since JavaFX was separated
from the JDK, so this test seems to be quite artificial to me but of
course I may be wrong. That's
why I asked here.

Am 20.04.20 um 17:25 schrieb Ty Young:

I'm a bit confused here. if you don't want JPMS then you should be
able to run everything on the classpath like normal. Netbeans at least
doesn't force modules wtih Maven. Or is reflection disabled on
classpath as of Java 9 too unless you have a module-info?



Michael

Am 18.04.20 um 12:58 schrieb Ty Young:

On 4/18/20 5:01 AM, Michael Paus wrote:

Getting started with JavaFX is made overly complicated by the fact
that the use of the
module system is enforced by some code in the JDK. Especially for
beginners, who just
want to get some small program running, this is almost always a big
source of frustration.
It is not very good marketing for JavaFX to make these initial
steps such a pain. If you
need some evidence for this statement, then just follow JavaFX on
Stackoverflow or similar
sites (and also this mailing list). Almost every day you can read
frustrated posts from
helpless people who would just like to get some JavaFX project
running but are failing
because they get lost in the module system jungle.


Speaking as a long time JavaFX user(literally since Java 8), I have
mostly disagree that the JPMS is hurting JavaFX.


That said, I don't think the frustration is misplaced. What you say
is true(Netbeans mailing list is fill of JavaFX issues) and the end
user is *NOT* to be blamed here.


Rather, I think what's to blame is poor documentation, JavaFX
requiring absurd runtime module VM arguments, and  poor/buggy IDE
support.


Starting with documentation, JavaFX uses reflection for things like
TableView(everyone's favorite) and CSS style sheets. While this may
be obvious for people who are more experienced, those who are not
may be very confused when they get an onslaught of error messages
regarding reflection. Better documentation on what requires
reflection, why, and how to enable it would be useful.


Likewise, the notice about having to include javafx.graphics to the
runtime module arguments here:


https://openjfx.io/openjfx-docs/#IDE-NetBeans


Apply to Maven as well, but it's under Ant for some reason. I don't
know what was changed in JavaFX 14 that now suddenly requires a
runtime VM argument, but it's a PITA and BS. End users are going to
struggle with this, and it prevents JavaFX runtime from being purely
managed by Maven. No other JavaFX version requires this, so it's
mind boggling that all of a sudden JavaFX needs this.


Poor/buggy IDE support is really the big one here. I don't know
about other IDEs but Netbeans DOES NOT provide a project template
for creating a JavaFX application with setup dependencies. Netbeans,
when setup with a Maven project, allows you to select an entire
project(pom) rather than the individual dependencies(jar) which
doesn't work. What you search for also matters: if you search for
"JavaFX" you will get the wrong search results. You need to search
for "openjfx" which can be confusing.


Anyway, yeah, it's a PITA. There is also an issue with Ant based
projects and Ne

Re: sane default option values for Linux

[Philip Race]

Some of the latest Linuxes don't even include GTK2 by default !
Its only a step away from them not being even available as an optional 
download.


> ...although I honestly don't think this was a regression introduced 
in JavaFX...
> literally every graphical application segfaults now, including games 
like Minecraft..


Since Minecraft does not use Swing, Java2D, AWT or JavaFx *at all* - not 
even loading them - it
definitely there can't be anything in the Java client stack that is 
causing it.
So if switching to GTK2 miraculously cures it, then that seems like a 
coincidence
and not anything we are doing. It could be a change elsewhere in the 
JDK, if it
reproduces today with 12+ but not 11, but bringing it up on this list, 
or requesting

this workaround, both seem to be pointing in the wrong direction.
And Kevin's suggestion of a driver bug seems possible + worth looking into.

-phl

On 3/18/20, 5:04 AM, Kevin Rushforth wrote:


> Regardless, the other issues are still valid. Can we please have 
GTK2 set as default along with force painter uploading?


No, we are not going to do this. GTK 2 is on its way out. GTK 3 has 
been the default for both AWT and JavaFX since JDK 11 / JavaFX 11. I'd 
much rather see energy going into fixing any remaining GTK 3 issues 
than take a step backwards.


The other issues you are seeing relating to the need for 
"forceUploadingPainter" and the crash in libnvidia-glcore are 
indicative of a possible graphics driver bug. We do plenty of testing 
on Linux and haven't see reports of the problems you are having. The 
likely solution would be to blacklist that driver and fall back to the 
software pipeline. You might consider "-Dprism.order=sw" rather than 
using forceUploadingPainter (the latter is only intended for testing 
and not recommended for production).


-- Kevin


On 3/18/2020 12:48 AM, Ty Young wrote:
After going through varies JDK versions from OpenJDK from 8 to 
present, it seems like the segfault issues was introduced elsewhere 
at about JDK12/13.



Regardless, the other issues are still valid. Can we please have GTK2 
set as default along with force painter uploading?



On 3/17/20 6:54 AM, Ty Young wrote:

Hi all,


After many months of being unable to run my JavaFX application due 
to transitioning to the new Project Panama MemoryAccess API(for 
native C calling, of course), I've finally gotten things to 
semi-working order and able to tryout JavaFX 14... only to find out 
that JavaFX on Linux is still buggy without specifying runtime args.



To recap for those who don't develop JavaFX on Linux or use it, if 
you don't have -Dprism.forceUploadingPainter=true set, JavaFX 
applications will suffer from buffer zeroing when resizing an 
application. This affects *ALL* JavaFX applications. There are still 
GTK3 bugs and regressions that, since it was enabled by default back 
in JavaFX 11(IIRC) still haven't been fixed. If you try to use GTK3 
right now with JavaFX 14 you get a GDK warning:



(java:64002): Gdk-WARNING **: 06:23:04.022: Native Windows wider or 
taller than 32767 pixels are not supported



This is not so if GTK 2 is specified by doing: -Djdk.gtk.version=2. 
No application code requests a window that tall or wide.



As a bonus, something new that was introduced in Java 13(12?) and 
later is that exiting a JavaFX application will cause a segfault:



# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7fbfbad22d9d, pid=68034, tid=68044
#
# JRE version: OpenJDK Runtime Environment (15.0) (build 
15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew)
# Java VM: OpenJDK 64-Bit Server VM 
(15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew, mixed 
mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)

# Problematic frame:
# C  [libnvidia-glcore.so.440.64+0xa95d9d]


...although I honestly don't think this was a regression introduced 
in JavaFX... literally every graphical application segfaults now, 
including games like Minecraft... but regardless it happens when 
exiting a JavaFX application too. Originally I thought it was a bug 
caused by the Project Panama builds but it's been persistent for 
over a year now. I'm guessing something broke in JDK proper.



Anyway, point of this email isn't to complain that no one is testing 
JavaFX on Linux(clearly no one is, by the by), but to ask why sane 
defaults aren't being used. Anyone developing a JavaFX application 
on and/or for Linux(god help them) is not going to know how to fix 
problems caused by GTK3 or by not forcing painter uploading, so, if 
no one is going to fix these issues(which is fine, I guess), why not 
use config options that are known to work properly?

Re: Request for adding my github userid ..

[Philip Race]

https://wiki.openjdk.java.net/display/SKARA/Skara#Skara-AssociatingyourGitHubaccountandyourOpenJDKusername

-phil.

On 3/15/20, 6:34 AM, Eric Bresie wrote:

Silly question...

Is this whole new contributor process (i.e. including the GitHub id 
association, sakara notations in the ticket, etc.) documented someplace outside 
of mailing list?

Eric Bresie
ebre...@gmail.com

On February 26, 2020 at 4:17:59 AM CST, Dalibor Topic 
 wrote:
Yeah, he did. ;)

On 22.02.2020 17:58, Kevin Rushforth wrote:

You should be all set now. Dalibor will likely take care of this early
next week.

-- Kevin


On 2/22/2020 8:42 AM, Rony G. Flatscher wrote:

On 22.02.2020 17:33, Philip Race wrote:

What openjdk ID would this be associated with ?

8234959 (tel:8234959): FXMLLoader does not populate ENGINE_SCOPE Bindings with
FILENAME and ARGV #122

One PR is the fix another one is dubbed as WIP and has the test unit
for this bug (such that one can
apply it before and after the fix).


I don't see a Rony Flatscher in the census :
https://openjdk.java.net/census

Rony, Have you made contributions and been granted author status ?

No, this is the first time I try to contribute code.

If yes, where is it on that page ? If not, then you need to make
contributions
(not just sign the OCA) before you get author status and until then
there is nothing
with which to associate your github id.

Hmm, how should I then submit a fix/a pull request?

The OCA was processed in 2017-03-01 (reported by Dalibor Topic), as
suggested I introduced myself in
[1]. However, for various reasons I got side tracked and only came
back this last November.

@Kevin: thank you for your advice, did comment on both PR

---rony

[1] "Introduction":
<https://mail.openjdk.java.net/pipermail/discuss/2017-March/004160.html>




On 2/22/20, 8:27 AM, Kevin Rushforth wrote:

What you need to do is this:


Once you have signed the OCA, please let us know by writing
`/signed` in a comment in this pull

request.

Omit the quotes in the command.

This will alert the Skara maintainers to check your OCA status and
make the association.

-- Kevin


On 2/22/2020 8:20 AM, Rony G. Flatscher wrote:

Trying to place my first pull requests via github and received the
following e-mail:

--- cut ---

Hi ronyfla, welcome to this OpenJDK project and thanks for
contributing!

We do not recognize you as Contributor
<https://openjdk.java.net/bylaws#contributor>  and need to
ensure you have signed the Oracle Contributor Agreement (OCA). If
you have not signed the OCA,
please follow the instructions
<https://www.oracle.com/technetwork/community/oca-486395.html>.
Please fill in your GitHub username in the "Username" field of the
application. Once you have
signed
the OCA, please let us know by writing |/signed| in a comment in
this pull request.

If you already are an OpenJDK Author
<https://openjdk.java.net/bylaws#author>, Committer
<https://openjdk.java.net/bylaws#committer>  or Reviewer
<https://openjdk.java.net/bylaws#reviewer>,
please click here
<https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1>
to
open a new issue so that we can record that fact. Please use "Add
GitHub user ronyfla" as summary
for the issue.

If you are contributing this work on behalf of your employer and
your employer has signed the OCA,
please let us know by writing |/covered| in a comment in this pull
request.

--- cut ---

So I am kindly requesting to associate my github user id 'ronyfla'
with my signed OCA form such
that
the pull requests can go forward.

TIA

---rony

P.S.: In the meantime I have changed the github e-mail address for
'ronyfla' to the one in the OCA
if that makes a difference.

--
<http://www.oracle.com>  Dalibor Topic
Consulting Product Manager
Phone: +494089091214 (tel:+494089091214), Mobile: 
+491737185961 (tel:+491737185961)
, Video: dalibor.to...@oracle.com


Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRB 246209
Geschäftsführer: Ralf Herrmann

Re: Request for adding my github userid ..

[Philip Race]

Well I didn't know that ...

-phil.

On 2/22/20, 8:38 AM, Kevin Rushforth wrote:
Rony isn't an Author, meaning he doesn't have an OpenJDK ID. 
Nevertheless, all Contributors need to have their GitHub username 
registered. It's a different process for those who do have an OpenJDK 
ID versus those who don't.


Those who do will file an issue in JBS in the SKARA project to 
associate their GitHub user ID with their OpenJDK ID.


Those who don't will enter the "/signed" command (or "/covered" if 
working for an employer who has signed on behalf of the whole company) 
to have their GitHub username verified against the list of OCA 
signatories.


Both processes are listed in the automated comment (which Rony 
included below) that the Skara bot adds to a PR for first-time 
Contributors.


-- Kevin


On 2/22/2020 8:33 AM, Philip Race wrote:

What openjdk ID would this be associated with ?
I don't see a Rony Flatscher in the census : 
https://openjdk.java.net/census


Rony, Have you made contributions and been granted author status ?
If yes, where is it on that page ? If not, then you need to make 
contributions
(not just sign the OCA) before you get author status and until then 
there is nothing

with which to associate your github id.

-phil

On 2/22/20, 8:27 AM, Kevin Rushforth wrote:

What you need to do is this:

> Once you have signed the OCA, please let us know by writing 
`/signed` in a comment in this pull request.


Omit the quotes in the command.

This will alert the Skara maintainers to check your OCA status and 
make the association.


-- Kevin


On 2/22/2020 8:20 AM, Rony G. Flatscher wrote:
Trying to place my first pull requests via github and received the 
following e-mail:


--- cut ---

Hi ronyfla, welcome to this OpenJDK project and thanks for 
contributing!


We do not recognize you as Contributor 
<https://openjdk.java.net/bylaws#contributor> and need to
ensure you have signed the Oracle Contributor Agreement (OCA). If 
you have not signed the OCA,
please follow the instructions 
<https://www.oracle.com/technetwork/community/oca-486395.html>.
Please fill in your GitHub username in the "Username" field of the 
application. Once you have signed
the OCA, please let us know by writing |/signed| in a comment in 
this pull request.


If you already are an OpenJDK Author 
<https://openjdk.java.net/bylaws#author>, Committer
<https://openjdk.java.net/bylaws#committer> or Reviewer 
<https://openjdk.java.net/bylaws#reviewer>,
please click here 
<https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1> 
to
open a new issue so that we can record that fact. Please use "Add 
GitHub user ronyfla" as summary

for the issue.

If you are contributing this work on behalf of your employer and 
your employer has signed the OCA,
please let us know by writing |/covered| in a comment in this pull 
request.


--- cut ---

So I am kindly requesting to associate my github user id 'ronyfla' 
with my signed OCA form such that

the pull requests can go forward.

TIA

---rony

P.S.: In the meantime I have changed the github e-mail address for 
'ronyfla' to the one in the OCA

if that makes a difference.

Re: Request for adding my github userid ..

[Philip Race]

What openjdk ID would this be associated with ?
I don't see a Rony Flatscher in the census : https://openjdk.java.net/census

Rony, Have you made contributions and been granted author status ?
If yes, where is it on that page ? If not, then you need to make 
contributions
(not just sign the OCA) before you get author status and until then 
there is nothing

with which to associate your github id.

-phil

On 2/22/20, 8:27 AM, Kevin Rushforth wrote:

What you need to do is this:

> Once you have signed the OCA, please let us know by writing 
`/signed` in a comment in this pull request.


Omit the quotes in the command.

This will alert the Skara maintainers to check your OCA status and 
make the association.


-- Kevin


On 2/22/2020 8:20 AM, Rony G. Flatscher wrote:
Trying to place my first pull requests via github and received the 
following e-mail:


--- cut ---

Hi ronyfla, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor 
 and need to
ensure you have signed the Oracle Contributor Agreement (OCA). If you 
have not signed the OCA,
please follow the instructions 
.
Please fill in your GitHub username in the "Username" field of the 
application. Once you have signed
the OCA, please let us know by writing |/signed| in a comment in this 
pull request.


If you already are an OpenJDK Author 
, Committer
 or Reviewer 
,
please click here 
 
to
open a new issue so that we can record that fact. Please use "Add 
GitHub user ronyfla" as summary

for the issue.

If you are contributing this work on behalf of your employer and your 
employer has signed the OCA,
please let us know by writing |/covered| in a comment in this pull 
request.


--- cut ---

So I am kindly requesting to associate my github user id 'ronyfla' 
with my signed OCA form such that

the pull requests can go forward.

TIA

---rony

P.S.: In the meantime I have changed the github e-mail address for 
'ronyfla' to the one in the OCA

if that makes a difference.

Re: set Destination attribute in printReqAttrSet

[Philip Race]

I found that there were some bugs in the JDK code that FX calls
that need to be fixed first. I started on those but it was reasonably
complex to test and so that is still WIP and then the FX part should
be possible.

-phil.

On 2/4/20, 2:52 AM, Neacsu Cristian wrote:

Hello,

Any updates regarding this matter? :-s

Thank you in advance,
Cristian-Stefan

On Sat, May 11, 2019 at 2:36 AM Neacsu Cristian 
<mailto:neacsu.cristianste...@gmail.com>> wrote:


Damn ... Thank you for your reply and for the ticket submitted.
I created an invoice application for my own company, and imagine
that java 9+ would kill me :) All the invoices are generated
automatically through pdf printer (I tried few free pdf libraries
as an alternative, but for what I need they have poor results).

I actually posted my ugly solution as well here some time ago:

https://stackoverflow.com/questions/52684422/javafx-set-programmatically-the-destination-path-to-print-directly-a-node-to-p/52687798#52687798

I know it is not much, but 89 hits might mean something. People
might fight with it later, when they are going to migrate for new
java versions.

Thank you so much, and looking forward if you guys have time to
take care of it.

Cristian-Stefan


On Fri, May 10, 2019 at 8:15 PM Philip Race
mailto:philip.r...@oracle.com>> wrote:

Everything you are touching there pre-supposes knowledge
of today's implementation of the JavaFX printing API, so
I don't think we can endorse that.
The right thing to do (maybe years ago!) is to file
an RFE to request that something like the Destination attribute
be supported in the FX printing API. I've reviewed the open
bug list and I don't see that anyone else has asked for this.

I just submitted :
https://bugs.openjdk.java.net/browse/JDK-8223717

JFYI, I reviewed some old notes and it was originally planned
to be
supported in the API but during design discussion it was removed
as a result of a combination of getting it right, not being
sure how
many people would need it (you may be the first) and some perhaps
over-stated concerns about security.

-phil.

On 5/10/19, 1:39 AM, Neacsu Cristian wrote:
> For windows print through "Microsoft Print to PDF", there is
no way right
> now to pre-define a path programmatically. There is no way
to set inside
> the printReqAttrSet (J2DPrinterJob), an attribute of type
Destination, to
> solve this issue.
>
> Before jdk 9, I was bypassing it through reflection like this:
>
> java.lang.reflect.Field field =
job.getClass().getDeclaredField("jobImpl");
> field.setAccessible(true);
> PrinterJobImpl jobImpl = (PrinterJobImpl) field.get(job);
> field.setAccessible(false);
> field = jobImpl.getClass().getDeclaredField("printReqAttrSet");
> field.setAccessible(true);
> PrintRequestAttributeSet printReqAttrSet =
(PrintRequestAttributeSet)
> field.get(jobImpl);
> field.setAccessible(false);
> printReqAttrSet.add(new Destination(new
File(filePath).toURI()));
>
> Now, the module is closed, so I cannot access it through
reflection. Is
> there a way to obtain this behavior again?

Re: OpenJFX is not using FontConfig

[Philip Race]

Perhaps you could trace the process to see if we successfully load the 
shared library ?

Maybe we can't do that or can't initialise it for some reason.

But Centos 7.4 is the same as RH 7.4 and OL 7.4 so this is surprising.

Do you have the same fontconfig packages on working and non-working ?
For example do both (or neither) have the fontconfig-develop (or 
whatever it is called)

package as well as the runtime ?

What does a pure Java SE (java 2d) app do on the same machine ?
It also loads fontconfig to find fonts so does it succeed or does it 
fail too ?

Try an Oracle produced OpenJDK build to tet this.

-phil


On 1/8/20, 7:30 AM, Fabian Keller wrote:

Hi,
I'm currently investigating a problem where openjfx is not using
FontConfig on a CentOS machine.

Error message:
...
Loading FontFactory com.sun.javafx.font.freetype.FTFactory
Subpixel: enabled
Freetype2 Loaded (version 2.8.0)
LCD support Disabled
Fallback fontDir is /root/jdk-11.0.5+10/lib/fonts exists = false
java.io.FileNotFoundException: null/allfonts.properties (No such file
or directory)
Fall back to opening the files
  *** FONTCONFIG LOCATED FONTS:
Not using FontConfig
Fontconfig returned no font for sans:regular:roman
...

I'm using openjfx bundled with my application in a fat jar.
(dependencies javafx-base, javafx-web, javafx-swing) (Tested openjfx
versions: 11, 11.0.1, 13, 13.0.1)
The jar is working without any problems on two different machines, one
with a fresh installation of CentOS 7.4 with Gnome.
On other existing machines (CentOS 7.4) i see the error above,
terminating with jvm core dump due to no available fonts.
I tested the behaviour with two jdk distributions from adoptopenjdk
(OpenJDK11U-jdk_x64_linux_hotspot_11.0.5_10) and Bellsoft
(bellsoft-jdk11.0.5+11).

FontConfig seem's to work properly
# fc-match sans.regular
DejaVuSans.ttf: "DejaVu Sans" "Book"
# fc-match sans:regular:roman
DejaVuSans.ttf: "DejaVu Sans" "Book"

The jvm command line i used:
java -Dprism.useFontConfig=true -Dprism.debugfonts=true
-Dprism.verbose=true -cp nalf.jar de.dummy.Main

I took a look at the source which produces the line "Not using FontConfig":
https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/font/FontConfigManager.java#L161

If I read correctly the only case where this output can happen is if
'useFontConfig' is false.

The only assignment of 'useFontConfig' is here:
https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/font/FontConfigManager.java#L52

useFontConfig should only be false if the property
'prism.useFontConfig' is not equals 'true'. But I set it explicitly to
"true" (default should also be true).


Does anybody have a clue, what's the problem or has anybody an idea
how to debug this further?


Best regards
Fabian Keller

Re: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow

[Philip Race]

On 12/20/19, 7:04 PM, Scott Palmer wrote:

I'm not sure if I'me supposed to try to integrate now that I've made that 10 -> 
 0 change, or if the new change resets the need for review...


It shows ready, which surprises me.
Still learning skara .. I'd expect any change to reset as how can it 
know if it is
a  good or insignificant change or not no matter how the commenter 
characterised the issue ?




  Also, note that the link in the bot msg for "project specific requirements" 
is giving me a 404 error.

I see that too https://github.com/openjdk/jfx/blob/masterCONTRIBUTING.md


I don't know how the change here : 
https://github.com/openjdk/skara/pull/343/files


+ automated pre-integration checks. When the change also ");
+   message.append("fulfills all [project specific 
requirements](https://github.com/";);


maps to the project, but it seems like there's a config bug somewhere 
that may be just being

exposed

-phil

Re: Skara - bot sending can-be-integrated message prematurely?

[Philip Race]

On 12/16/19, 4:14 PM, Nir Lisker wrote:

Do other projects also have multi-reviewers requirements?


The client libraries in the OpenJDK do as a default rule, excusing 
simple fixes.




I would think that at least for a CSR, which is OpenJDK-wide, a request
could be put in with the Skara to track it. A Reviewer (or Committer?)
could invoke a /csr command which will require the PR author to provide a
link to the CSR, and check that it was approved as part of the patch
approval process.


I think that if there is a CSR sub-task in JBS skara can key off whether 
that is approved.
This does mean skara needs to probe JBS but SFAIK its doing that a 
hundred times

a minute anyway.

-phil.



Not sure how complicated it would be to implement.

- Nir

On Mon, Dec 16, 2019 at 5:39 PM Kevin Rushforth
wrote:


That's a good question about whether we can ask for a slight rewording
of the Skara bot message to indicate that there might be other things to
check before "/integrate". I'll raise that question with the Skara team.

As an aside, I noticed the other day that you typed "/integrate" after a
single review, but in that case, there was no clear indication from Ajit
(the first reviewer and the sponsor) that a second review was required,
so I didn't comment on it.

-- Kevin


On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:

Kevin,

thanks for the clarification :) My bad that I didn't re-read the
contrib.md. But then, who does? The lazy like myself do it
occasionally only (down to once and then forget about it)

Maybe the bot message can be improved? With some indication that its
(the bot's) knowledge about review requirements is limited, so would
require a careful check by the contributor before actually post the
/integrate comment? Actually, I think I goofed the other day, was
safed only by Ajit who waited for the 2nd review before his /sponsor.

-- Jeanette

Zitat von Kevin Rushforth:


I added a comment to the two PRs in question, but it bears discussion
here.

The Skara bot can't know whether all criteria have been met. It
can't, for example, know whether there are outstanding comments from
some reviewers that need to be addressed. Nor does it know which PRs
need two reviewers (or sometimes a third if there is a specific
person we would like to review it), which ones need a CSR, etc.

So having it state authoritatively that the PR is ready to integrate
is a bit misleading. This is documented in the Code Review section of
the CONTRIBUTING [1] doc:


NOTE: while the Skara tooling will indicate that the PR is ready to
integrate once the first reviewer with a "Reviewer" role in the
project has approved it, this may or may not be sufficient depending
on the type of fix. For example, you must wait for a second approval
for enhancements or high-impact bug fixes.

If anyone can think of a way to improve this and make it more clear,
that would be helpful.

-- Kevin

[1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md


On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:

Looks like it assumes a pull request as properly reviewed as soon as
it gets a single approve - independent on how many reviewers are
required, see f.i.

https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
https://github.com/openjdk/jfx/pull/6#issuecomment-566028296

-- Jeanette

Re: Fwd: Re: Can't commit into lanai repo (Artem at JetBrains)

[Philip Race]

Sorry .. wrong list - auto-complete ! Please ignore.

-phil.

On 11/7/19, 5:48 AM, Philip Race wrote:
Based on everything I see here, I wonder if Artem is not configured as 
a Project Lanai committer ?

Contrary to the census ..

Fwd: Re: Can't commit into lanai repo (Artem at JetBrains)

[Philip Race]

Based on everything I see here, I wonder if Artem is not configured as a 
Project Lanai committer ?

Contrary to the census ..

-phil.

 Original Message 
Subject:Re: Can't commit into lanai repo
Date:   Thu, 7 Nov 2019 15:57:02 +0300
From:   Artem Bochkarev 
To: Philip Race 



Hello!

1. I can pull over ssh. Command line output:

   bocha@unit-1145 lanai % hg pull
   pulling from ssh://abochka...@hg.openjdk.java.net/lanai/lanai
   <http://abochka...@hg.openjdk.java.net/lanai/lanai>
   Enter passphrase for key '/Users/bocha/.ssh/id_rsa':
   searching for changes
   no changes found


2. It seems that I've got 'write'-rights via ssh (at least for 
abochka...@cr.openjdk.java.net <mailto:abochka...@cr.openjdk.java.net>). 
Scp works correctly:


   scp README.md abochka...@cr.openjdk.java.net:~

3. Output for hg verify:

   bocha@unit-1145 lanai % hg verify
   checking changesets
   checking manifests
   crosschecking files in changesets and manifests
   checking files
   checked 56593 changesets with 485676 changes to 184847 files


4.  hg heads:

   bocha@unit-1145 lanai % hg heads
   changeset:   56592:f2e40582513d
   tag: tip
   user:abochkarev
   date:Thu Nov 07 12:24:48 2019 +0300
   summary: 8233714: support 32bpp raster formats (for SwToTexture
   blit)

5. hg incoming:

   bocha@unit-1145 lanai % hg incoming
   Enter passphrase for key '/Users/bocha/.ssh/id_rsa':
   comparing with ssh://abochka...@hg.openjdk.java.net/lanai/lanai
   <http://abochka...@hg.openjdk.java.net/lanai/lanai>
   searching for changes
   no changes found


6. hg out:

   bocha@unit-1145 lanai % hg out
   comparing with ssh://abochka...@hg.openjdk.java.net/lanai/lanai
   <http://abochka...@hg.openjdk.java.net/lanai/lanai>
   Enter passphrase for key '/Users/bocha/.ssh/id_rsa':
   searching for changes
   changeset:   56592:f2e40582513d
   tag: tip
   user:abochkarev
   date:Thu Nov 07 12:24:48 2019 +0300
   summary: 8233714: support 32bpp raster formats (for SwToTexture
   blit)


7. hg push:

   bocha@unit-1145 lanai % hg push
   pushing to ssh://abochka...@hg.openjdk.java.net/lanai/lanai
   <http://abochka...@hg.openjdk.java.net/lanai/lanai>
   Enter passphrase for key '/Users/bocha/.ssh/id_rsa':
   searching for changes
   remote: abort: could not lock repository lanai/lanai: Read-only file
   system
   abort: unexpected response: empty string



I don't know where ssh-config problem can be. My ssh public key ends 
with "bo...@unit-1145.labs.intellij.net 
<mailto:bo...@unit-1145.labs.intellij.net>" (i.e. the key was generated 
for user 'bocha'), but my oracle login is "abochkarev" - could this 
mismatch affect anything?


On Tue, Nov 5, 2019 at 11:15 PM Philip Race <mailto:philip.r...@oracle.com>> wrote:


   That's a very generic message.
   The census here says you DO have rights :
   http://openjdk.java.net/census#lanai
   Could be an ssh config problem or a problem with your repo.
   I just can't tell from that message.

   Can you *pull* over ssh ?

   What do you see for these commands ?
   hg verify
   hg heads
   hg incoming
   hg out

   -phil.

   On 11/5/19, 11:48 AM, Artem Bochkarev wrote:
> Hello! Three days ago I was trying to push commits into lanai and
   I've
> got strange error:
> "empty response string"
> It seems that I haven't got enough rights to push into lanai repo.
> Please advise me what can I do to solve (at least diagnose) this
   problem?

Re: Okay to open a bug?

[Philip Race]

I see no problem with filing a bug .. and bonus points for assigning it 
to yourself and triaging it.


-phil.

On 10/26/19, 8:20 AM, Jeanette Winzenburg wrote:


ar ... wrong bug id: https://bugs.openjdk.java.net/browse/JDK-8233040

Zitat von Jeanette Winzenburg :

Just filed a bug (https://bugs.openjdk.java.net/browse/JDK-8231692) 
and accidentally opened it - the child in me can't refrain from 
clicking buttons to see what happens ;) Having it opened, I went the 
whole way and assigned it to me (it's in my current line of interes 
anyway).


Not certain if I maybe violated some procedure on the side of jbs? If 
so, please revert everything (except the bug, of course :)


Happy weekend,
Jeanette

Re: Use of Hashtable in Prism

[Philip Race]

I am not sure but mutation of the Hashtable only happens from inside a
block synchronized on CACHE_SIZE_LOCK.

Perhaps this somehow plays into it .. in some way I can't see.
But I am told that uncontended locks are quite cheap these days.

-phil

On 9/23/19, 10:18 AM, Scott Palmer wrote:

I just noticed that NetBeans is warning me about use of an “obsolete 
collection” in PrismTextLayout.java.

Is there a reason this isn’t using HashMap or ConcurrentHashMap ?

Scott

Re: set Destination attribute in printReqAttrSet

[Philip Race]

Everything you are touching there pre-supposes knowledge
of today's implementation of the JavaFX printing API, so
I don't think we can endorse that.
The right thing to do (maybe years ago!) is to file
an RFE to request that something like the Destination attribute
be supported in the FX printing API. I've reviewed the open
bug list and I don't see that anyone else has asked for this.

I just submitted : https://bugs.openjdk.java.net/browse/JDK-8223717

JFYI, I reviewed some old notes and it was originally planned to be
supported in the API but during design discussion it was removed
as a result of a combination of getting it right, not being sure how
many people would need it (you may be the first) and some perhaps
over-stated concerns about security.

-phil.

On 5/10/19, 1:39 AM, Neacsu Cristian wrote:

For windows print through "Microsoft Print to PDF", there is no way right
now to pre-define a path programmatically. There is no way to set inside
the printReqAttrSet (J2DPrinterJob), an attribute of type Destination, to
solve this issue.

Before jdk 9, I was bypassing it through reflection like this:

java.lang.reflect.Field field = job.getClass().getDeclaredField("jobImpl");
field.setAccessible(true);
PrinterJobImpl jobImpl = (PrinterJobImpl) field.get(job);
field.setAccessible(false);
field = jobImpl.getClass().getDeclaredField("printReqAttrSet");
field.setAccessible(true);
PrintRequestAttributeSet printReqAttrSet = (PrintRequestAttributeSet)
field.get(jobImpl);
field.setAccessible(false);
printReqAttrSet.add(new Destination(new File(filePath).toURI()));

Now, the module is closed, so I cannot access it through reflection. Is
there a way to obtain this behavior again?

Re: OpenJFX Build Setup

[Philip Race]

try
gradle -PCOMPILE_MEDIA=true -PCOMPILE_WEBKIT=true

-phil.

On 11/9/18, 12:37 PM, Bryce Glover wrote:

To Whom It May Concern,

  While going through the process of setting up an OpenJFX package to be
distributed via Homebrew in
https://github.com/Homebrew/homebrew-core/pull/32864, I noticed that the
results of running either plain 'gradle' or task-qualified 'gradle all'
don't include the following build products:

- 'libfxplugins.dylib'
- 'libglib-lite.dylib'
- 'libgstreamer-lite.dylib'
- 'libjfxmedia.dylib'
- 'libjfxmedia_avf.dylib'
- 'libjfxwebkit.dylib'

under '"$BUILD_PATH/build/artifacts/javafx-sdk-$VERSION/lib/"' (where '
$BUILD_PATH' is a temporary directory and '$VERSION' is the version being
built, currently v11.0.1+1, the latest release as of this writing) as
compared to the SDK archives you distribute on your download page
.  It's not immediately obvious from your
build instructions
  what
additional 'gradle' options and/or properties I might need to set in order
to fix this.  Given the presence of those dynamic libraries mentioning
GStreamer, it looks like I might be missing a dependency, too.  How might I
build these additional artifacts like you do for the pre-compiled releases?


Thanks in advance,
  Bryce Glover
  randomdsde...@gmail.com

Re: Setting the FreeType LCD filter

[Philip Race]

Hi,

Your explanation makes sense.
Compile time linking is probably best so long as we can verify that
the function is available on all the platforms we need to build & run on 
.. notably

older versions of OEL&RHEL.

Failing that, then as well as adding ".6" we should initialise

jint rc =-1;

instead of to zero .. so that failure to find the function isn't confused
as failure *of* the function, which in a nutshell, seems to be the bug here.
And I suppose we have the same bug on "older" systems where the freetype 
library is
found but lack the symbol.

Is there no JBS bug id already open on this ? If one was closed as not 
reproducible,
we can re-open it. Better than creating a new one.

-phil.

On 9/30/18, 12:03 PM, John Neffenger wrote:
I think I found the cause of the text rendering problem I have always 
seen in JavaFX applications on Linux:


Reduce color fringes in FreeType subpixel rendering
https://github.com/javafxports/openjdk-jfx/issues/229

I'm finally seeing the fonts as they were intended! I used the Oracle 
bug report outline as a template for the GitHub issue to make it easy 
to copy to the Java Bug Database. Do I need a Java Bug ID before I 
submit a pull request?


Thanks,
John

P.S.: For background information, there is a great demonstration of 
LCD filtering algorithms by Felipe Heidrich at 1:02:47 into the video 
"JavaFX Text Rendering" . The 
link takes you directly to the two-minute segment showing the text 
rendered by FreeType, first with no filter, and then with its various 
filter options. (Note: the audio is a bit loud.)

Re: Trying to find what fixed a TextFlow bug between 8 and 9

[Philip Race]

Do you see the bug as platform independent ?
I just ran your test on 8u121 on Mac and am not sure what the problem is
that you are seeing. It behaves as well as JDK 10 does.
If its platform specific maybe you need to look at the platform-specific 
code


-phil.

On 7/18/18, 6:02 AM, Tom Schindl wrote:

Hi,

I'm trying to find the change that was made so that the following
snippet renders the text no matter if TextFlow wraps the line or not in
the same way (which is broken in FX8)


package fxbugs;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.layout.VBox;
import javafx.scene.text.Text;
import javafx.scene.text.TextFlow;
import javafx.stage.Stage;

public class TextRenderBug extends Application {

 @Override
 public void start(Stage primaryStage) throws Exception {
 VBox box = new VBox();

 Text t1 = new Text("1234");
 Text t2 = new Text(" - A. Ackermann Bla Bla Bla");
 TextFlow t = new TextFlow(t1,t2);
 box.getChildren().add(t);

 Scene s = new Scene(box, 800, 600);
 primaryStage.setScene(s);
 primaryStage.show();
 }

 public static void main(String[] args) {
 launch(args);
 }
}

I've looked through the changes of com.sun.javafx.text but nothing
really looked like it might have fixed the issue.

Tom

Re: CFV: New OpenJFX Committer: Prem Balakrishnan

[Philip Race]

Vote: yes.

-phil.

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[Philip Race]

Some follow up comments.

On 5/10/18, 5:49 PM, Philip Race wrote:
I've looked over the Swing code. No time to actually try it out so I 
can only comment on what I see.


I am not sure what I think about class docs like "This class wraps 
 .."
I know no javadoc is generated but this module is exported and 
probably should say something

less specific.

In general I really have to hold my nose when looking at this whole 
module and I

find it distasteful to endorse it.

I really don't like all the things SwingInterOpUtils.java does.


Specific things we should look at in this file
- getDefaultScaleX/Y .. JDK 9 will set a transform on the graphics that
is passed to JComponent.paintComponent() .. so I wonder if we really
need this internal API. I doubt any other code is updating the transform
in a way that would make it a problem so the information you get should 
be valid.


The code to get the data array for the raster and associated information
can be extracted via standard API like this :

DataBuffer  db = BufferedImage.getRaster().getDataBuffer();
if (db instanceof DataBufferInt) {
 data = (DataBufferInt)db.getData();
}

So all of those can be fixed.

The code that accepts a native window handle maybe should require it is 
accessed via JNI ...

It could still be unsupported, but it would be package private or similar.
If you have a native ID, then you are already using native code.
This sidesteps any questions about the stability of such an API which
accepts a native resource.

The code that finds a component by location is probably harmless ...

I'm less sure about the event posting and focus grabbing support.
I'd like to have Sergey comment on those.

the DnD code is too much for me to examine in detail.

I worry we are creating something we'll come to regret here.
The "unsupportedness" needs to be backed up by deprecated-for-removal 
being included

today so we can get rid of it the next release if we want to.


I've looked at jdk.unsupported and they don't seem to have deprecation 
tags so

maybe that isn't an issue.

-phil


No @since tags anywhere

-phil.

On 5/10/18, 8:32 AM, Kevin Rushforth wrote:
I confirm that this fixes the issue. The interface change to make the 
two static methods e instance methods is a good change in any case.


I am not a Swing "R"eviewer, but the .13 webrev gets a +1 from me.

-- Kevin


On 5/10/2018 8:20 AM, Prasanta Sadhukhan wrote:


Hi Kevin,All,

Please find the modified webrev fixing this #1 issue
http://cr.openjdk.java.net/~psadhukhan/fxswing.13/
via change in 
jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext 
and FXDnD.java#postDropTargetEvent


For me, #2 works, #3 doesn't work even now due to JDK-8141391 
<https://bugs.openjdk.java.net/browse/JDK-8141391> and #4 works for me.


Regards
Prasanta
On 5/9/2018 11:29 PM, Kevin Rushforth wrote:

Hi Prasanta,

The API looks good now.

All of our automated tests work (except for the ones with a 
security manager due to JDK-8202451 
<https://bugs.openjdk.java.net/browse/JDK-8202451>).


The only functional problem that I see is that Drag and Drop onto a 
SwingNode doesn't work. We need to make sure that we test the 
following four cases:


1. Drag / drop onto a Swing component in a SwingNode
2. Drag / drop from a Swing component in a SwingNode
3. Drag / drop onto a JavaFX control in a JFXPanel
4. Drag / drop from a JavaFX control in a JFXPanel

So far I only tried the first one; the others still need to be 
validated.


-- Kevin



On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote:

Modified webrev to cater to this

http://cr.openjdk.java.net/~psadhukhan/fxswing.12/

Regards
Prasanta
On 5/9/2018 5:58 PM, Kevin Rushforth wrote:

The following can also be abstract:

LightweightContentWrapper:
  getComponent, createDragGestureRecognizer, 
createDragSourceContextPeer


DropTargetContextWrapper:
  getTargetActions, getDropTarget, getTransferDataFlavors, 
getTransferable, isTransferableJVMLocal


DispatcherWrapper:
  isDispatchThread, createSecondaryLoop

The rest looks good to me (although I still see two public 
methods with "Peer" in the name, so Phil may want those renamed).


-- Kevin


On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote:

Modified webrev to cater to these 3 observations
http://cr.openjdk.java.net/~psadhukhan/fxswing.11/

Regards
Prasanta

On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
The module definition for jdk.unsupported.desktop and the 
changes to java.desktop look fine.


In reviewing the jdk.swing.interop API, I have the following 
suggestions / observations:


1. DispatcherWrapper, DragSourceContextWrapper, 
DropTargetContextWrapper, and LightweightContentWrapper can all 
be abstract, along with most of the methods (rather than having 
an empty body return value that is never used).


2. The addNotify method in LightweightFrameWrapper is unused. 
Should be used somewhere? If

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[Philip Race]

PS .. there should be some tests on the JDK side that don't use FX
Or at least a reasoned explanation as to why this isn't possible.

-phil.

On 5/10/18, 5:49 PM, Philip Race wrote:
I've looked over the Swing code. No time to actually try it out so I 
can only comment on what I see.


I am not sure what I think about class docs like "This class wraps 
 .."
I know no javadoc is generated but this module is exported and 
probably should say something

less specific.

In general I really have to hold my nose when looking at this whole 
module and I

find it distasteful to endorse it.

I really don't like all the things SwingInterOpUtils.java does.

I worry we are creating something we'll come to regret here.
The "unsupportedness" needs to be backed up by deprecated-for-removal 
being included

today so we can get rid of it the next release if we want to.

No @since tags anywhere

-phil.

On 5/10/18, 8:32 AM, Kevin Rushforth wrote:
I confirm that this fixes the issue. The interface change to make the 
two static methods e instance methods is a good change in any case.


I am not a Swing "R"eviewer, but the .13 webrev gets a +1 from me.

-- Kevin


On 5/10/2018 8:20 AM, Prasanta Sadhukhan wrote:


Hi Kevin,All,

Please find the modified webrev fixing this #1 issue
http://cr.openjdk.java.net/~psadhukhan/fxswing.13/
via change in 
jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext 
and FXDnD.java#postDropTargetEvent


For me, #2 works, #3 doesn't work even now due to JDK-8141391 
<https://bugs.openjdk.java.net/browse/JDK-8141391> and #4 works for me.


Regards
Prasanta
On 5/9/2018 11:29 PM, Kevin Rushforth wrote:

Hi Prasanta,

The API looks good now.

All of our automated tests work (except for the ones with a 
security manager due to JDK-8202451 
<https://bugs.openjdk.java.net/browse/JDK-8202451>).


The only functional problem that I see is that Drag and Drop onto a 
SwingNode doesn't work. We need to make sure that we test the 
following four cases:


1. Drag / drop onto a Swing component in a SwingNode
2. Drag / drop from a Swing component in a SwingNode
3. Drag / drop onto a JavaFX control in a JFXPanel
4. Drag / drop from a JavaFX control in a JFXPanel

So far I only tried the first one; the others still need to be 
validated.


-- Kevin



On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote:

Modified webrev to cater to this

http://cr.openjdk.java.net/~psadhukhan/fxswing.12/

Regards
Prasanta
On 5/9/2018 5:58 PM, Kevin Rushforth wrote:

The following can also be abstract:

LightweightContentWrapper:
  getComponent, createDragGestureRecognizer, 
createDragSourceContextPeer


DropTargetContextWrapper:
  getTargetActions, getDropTarget, getTransferDataFlavors, 
getTransferable, isTransferableJVMLocal


DispatcherWrapper:
  isDispatchThread, createSecondaryLoop

The rest looks good to me (although I still see two public 
methods with "Peer" in the name, so Phil may want those renamed).


-- Kevin


On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote:

Modified webrev to cater to these 3 observations
http://cr.openjdk.java.net/~psadhukhan/fxswing.11/

Regards
Prasanta

On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
The module definition for jdk.unsupported.desktop and the 
changes to java.desktop look fine.


In reviewing the jdk.swing.interop API, I have the following 
suggestions / observations:


1. DispatcherWrapper, DragSourceContextWrapper, 
DropTargetContextWrapper, and LightweightContentWrapper can all 
be abstract, along with most of the methods (rather than having 
an empty body return value that is never used).


2. The addNotify method in LightweightFrameWrapper is unused. 
Should be used somewhere? If not, then it can be removed.


The implementation of the new wrapper classes looks OK to me 
with one observation that might or might not matter:


3. The behavior of getDefaultScaleX/Y (which is now in 
SwingInteropUtils) has changed in the case where the Graphics 
is not an instance of SunGraphics2D. The former behavior was to 
leave the instance variables X and Y unchanged. The new 
behavior will set them back to 1.0. Maybe this can't happen in 
practice, but it is something to consider.


-- Kevin


On 5/8/2018 3:31 AM, Alan Bateman wrote:

On 08/05/2018 06:51, Prasanta Sadhukhan wrote:

Modified webrev to rename to InteropProviderImpl

http://cr.openjdk.java.net/~psadhukhan/fxswing.10/

This looks okay to me.

-Alan

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[Philip Race]

I've looked over the Swing code. No time to actually try it out so I can 
only comment on what I see.


I am not sure what I think about class docs like "This class wraps 
 .."
I know no javadoc is generated but this module is exported and probably 
should say something

less specific.

In general I really have to hold my nose when looking at this whole 
module and I

find it distasteful to endorse it.

I really don't like all the things SwingInterOpUtils.java does.

I worry we are creating something we'll come to regret here.
The "unsupportedness" needs to be backed up by deprecated-for-removal 
being included

today so we can get rid of it the next release if we want to.

No @since tags anywhere

-phil.

On 5/10/18, 8:32 AM, Kevin Rushforth wrote:
I confirm that this fixes the issue. The interface change to make the 
two static methods e instance methods is a good change in any case.


I am not a Swing "R"eviewer, but the .13 webrev gets a +1 from me.

-- Kevin


On 5/10/2018 8:20 AM, Prasanta Sadhukhan wrote:


Hi Kevin,All,

Please find the modified webrev fixing this #1 issue
http://cr.openjdk.java.net/~psadhukhan/fxswing.13/
via change in 
jdk/swing/interop/DropTargetContextWrapper.java#setDropTargetContext 
and FXDnD.java#postDropTargetEvent


For me, #2 works, #3 doesn't work even now due to JDK-8141391 
 and #4 works for me.


Regards
Prasanta
On 5/9/2018 11:29 PM, Kevin Rushforth wrote:

Hi Prasanta,

The API looks good now.

All of our automated tests work (except for the ones with a security 
manager due to JDK-8202451 
).


The only functional problem that I see is that Drag and Drop onto a 
SwingNode doesn't work. We need to make sure that we test the 
following four cases:


1. Drag / drop onto a Swing component in a SwingNode
2. Drag / drop from a Swing component in a SwingNode
3. Drag / drop onto a JavaFX control in a JFXPanel
4. Drag / drop from a JavaFX control in a JFXPanel

So far I only tried the first one; the others still need to be 
validated.


-- Kevin



On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote:

Modified webrev to cater to this

http://cr.openjdk.java.net/~psadhukhan/fxswing.12/

Regards
Prasanta
On 5/9/2018 5:58 PM, Kevin Rushforth wrote:

The following can also be abstract:

LightweightContentWrapper:
  getComponent, createDragGestureRecognizer, 
createDragSourceContextPeer


DropTargetContextWrapper:
  getTargetActions, getDropTarget, getTransferDataFlavors, 
getTransferable, isTransferableJVMLocal


DispatcherWrapper:
  isDispatchThread, createSecondaryLoop

The rest looks good to me (although I still see two public methods 
with "Peer" in the name, so Phil may want those renamed).


-- Kevin


On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote:

Modified webrev to cater to these 3 observations
http://cr.openjdk.java.net/~psadhukhan/fxswing.11/

Regards
Prasanta

On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
The module definition for jdk.unsupported.desktop and the 
changes to java.desktop look fine.


In reviewing the jdk.swing.interop API, I have the following 
suggestions / observations:


1. DispatcherWrapper, DragSourceContextWrapper, 
DropTargetContextWrapper, and LightweightContentWrapper can all 
be abstract, along with most of the methods (rather than having 
an empty body return value that is never used).


2. The addNotify method in LightweightFrameWrapper is unused. 
Should be used somewhere? If not, then it can be removed.


The implementation of the new wrapper classes looks OK to me 
with one observation that might or might not matter:


3. The behavior of getDefaultScaleX/Y (which is now in 
SwingInteropUtils) has changed in the case where the Graphics is 
not an instance of SunGraphics2D. The former behavior was to 
leave the instance variables X and Y unchanged. The new behavior 
will set them back to 1.0. Maybe this can't happen in practice, 
but it is something to consider.


-- Kevin


On 5/8/2018 3:31 AM, Alan Bateman wrote:

On 08/05/2018 06:51, Prasanta Sadhukhan wrote:

Modified webrev to rename to InteropProviderImpl

http://cr.openjdk.java.net/~psadhukhan/fxswing.10/

This looks okay to me.

-Alan

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[Philip Race]

Yes, they (the methods mentioning Peer) should be renamed.

Qn. to Mandy & Alan : it seems there is no need to mention this module
in make/common/Modules.gmk in order to get it built, but is there any
advantage in doing so ? I mean without it, there is no conscious listing of
it as a module nor classification of it.

Another thing that Kevin & I touched on in conversation is that it seems
doclint fail on warning must be disabled by default .. and I suppose that
is what we want here since documentation is minimal.

-phil.

On 5/9/18, 5:28 AM, Kevin Rushforth wrote:

The following can also be abstract:

LightweightContentWrapper:
  getComponent, createDragGestureRecognizer, createDragSourceContextPeer

DropTargetContextWrapper:
  getTargetActions, getDropTarget, getTransferDataFlavors, 
getTransferable, isTransferableJVMLocal


DispatcherWrapper:
  isDispatchThread, createSecondaryLoop

The rest looks good to me (although I still see two public methods 
with "Peer" in the name, so Phil may want those renamed).


-- Kevin


On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote:

Modified webrev to cater to these 3 observations
http://cr.openjdk.java.net/~psadhukhan/fxswing.11/

Regards
Prasanta

On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
The module definition for jdk.unsupported.desktop and the changes to 
java.desktop look fine.


In reviewing the jdk.swing.interop API, I have the following 
suggestions / observations:


1. DispatcherWrapper, DragSourceContextWrapper, 
DropTargetContextWrapper, and LightweightContentWrapper can all be 
abstract, along with most of the methods (rather than having an 
empty body return value that is never used).


2. The addNotify method in LightweightFrameWrapper is unused. Should 
be used somewhere? If not, then it can be removed.


The implementation of the new wrapper classes looks OK to me with 
one observation that might or might not matter:


3. The behavior of getDefaultScaleX/Y (which is now in 
SwingInteropUtils) has changed in the case where the Graphics is not 
an instance of SunGraphics2D. The former behavior was to leave the 
instance variables X and Y unchanged. The new behavior will set them 
back to 1.0. Maybe this can't happen in practice, but it is 
something to consider.


-- Kevin


On 5/8/2018 3:31 AM, Alan Bateman wrote:

On 08/05/2018 06:51, Prasanta Sadhukhan wrote:

Modified webrev to rename to InteropProviderImpl

http://cr.openjdk.java.net/~psadhukhan/fxswing.10/

This looks okay to me.

-Alan

Re: native libs in modules

[Philip Race]

On 4/29/18, 10:05 AM, Johan Vos wrote:

Now that the OpenJFX SDK that works with Java 11 is about to be released in
EA, we should think about releasing the modules.

In case you download the OpenJFX SDK, running an app goes like
java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app

If you use gradle or maven, the same should be achieved using e.g.
dependencies {
 compile 'javafx:javafx.controls:11.0.0'
}

(ignore the naming and versioning for now)

This will download the javafx controls module and its dependencies from
e.g. maven central. The javafx controls module info declares a requires
entry for javafx.base and javafx.graphics so those will be downloaded.

The question is how the native libs should be downloaded. It is possible to
bundle the native libs with the modules, but there are a number of options
for dealing with platform-specific libraries:

1. javafx.graphics contains all native libraries for all platforms.
2. a generic javafx.graphics module containing java code only, plus N
platform-specific modules (or jar) containing the native code. An example
of how this is used is ND4J:
https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j-native/1.0.0-SNAPSHOT/


The java code is platform-specific too .. so I don't see how #1 would 
work and

#2 would seem to require some large amount of work and I don't think will
work either because you can't split packages acrosss modules which is 
what it

would probably mean.

-phil.


To make it more complex, there are a number of options for e.g. prims
leading to a number of native libs. Do we want to include all relevant
options for all platforms?

- Johan

Re: Question/discussion about JDK-8129582

[Philip Race]

racle.com>> wrote:

You can't skip layout just because it is bidi ..
where here you are apparently implicitly meaning Hebrew.
This might be apparently working but may not always work even
for Hebrew and will be a disaster for Arabic.

Here is a web page which talks about OTL (OpenType Layout)
for Hebrew :
https://www.microsoft.com/typography/OpenTypeDev/hebrew/intro.htm
<https://www.microsoft.com/typography/OpenTypeDev/hebrew/intro.htm>
I can't say offhand why this might be exclusive to FX.
That test case would be handy.
So this needs more analysis even if you found a way to
limit this to
specifically Latin+Hebrew.

-phil.


On 01/04/2017 10:32 AM, Itai wrote:

Some quick-and-dirty thing I hacked now and seems to
improve the performance drastically is something like:

if (complex but not bidi) {
   use GlyphLayout.
} else if (bidi) {
   use java.text.Bidi.reorderVisually to get visual glyph
order, then use same implementation as non-bidi
non-complex layout
} else {
   ...
}

Very minimal tests show it working correctly, and
performance is 8-10 times faster (on par with non-bidi
text).
Do you think this solution makes sense? Can you see any
obvious pitfalls?
If it seems OK I'll try some more tests and then work it
into something clean enough to submit as a patch suggestion.


On Wed, Jan 4, 2017 at 7:48 PM, Itai mailto:itai...@gmail.com>> wrote:

Thanks for replying.
I think I understand what you're saying about the
cache. As for complexity - I'm mostly working with
text which is only in Hebrew, which isn't complex as
far as I understand the definition (no glyph "fusing"
as in Arabic or Farsi). I can work with minor
performance drops, but when the same window takes
more than 10 times to show if it has Hebrew labels is
a lot more than minor - and this is exclusive to
JavaFX, so it's not like this problem is unsolvable.

Perhaps the caching is indeed not the correct
solution, but maybe there can be a way to simplify
the layout in non-complex BiDi cases? Or optimize
PangoGlyphLayout.layout?

Thank you again for replying, I really hope this
issue can see some improvement.

On Wed, Jan 4, 2017 at 7:26 PM, Philip Race
mailto:philip.r...@oracle.com>> wrote:

The cache is a heuristic optimisation and whether
it helps depends on how well that cache is used.
It is a time-space trade-off and I'd expect it to
show up as helping more in micro-benchmarks or
text-intensive benchmarks which use the same text
broken in the same way.
Complex text layout is inherently slower and if
you are doing a lot of it .. it will be slow .. and
unless it is repeated a cache won't help.
During start-up I'd *expect* that there isn't a
lot of re-use going on.

You would need to profile how often  the same
text (and attributes) are passed through this code.
If you could provide us a test case we could
examine it too.

If it were a real use case, then we'd move on to
examine the feasibility of caching ...

-phil.



On 1/4/17, 9:19 AM, Itai wrote:

Recently JDK-8129582 [1] started really
affecting me, with startup speed
and overall responsiveness becoming really bad.

Digging into it, I have found most time is
wasted in
com.sun.javafx.text.GlyphLayout.layout (as
represented by PangoGlyphLayout
on my Linux machine), which in turn is called
by com.sun.javafx.text.PrismTextLayout.shape,
which has:

 if (run.isComplex()) {
 /* Use GlyphLayout to shape
complex text */
 layout.layout(run, font, strike,

Re: [11] Review request : JDK-8195806 : Eliminate dependency on sun.font.lookup in javafx.graphics

[Philip Race]

Well that removes the dependency but how are you fixing the problem of 
how else to find the font ?
There needs to be alternate code or you need to go back to see what 
would happen if some code

tried to locate that font and how it would fail.

-phil.

On 2/13/18, 11:11 PM, Ajit Ghaisas wrote:

Hi Kevin, Phil,

   Request you to review following fix :

   Issue :  https://bugs.openjdk.java.net/browse/JDK-8195806

   Fix :  http://cr.openjdk.java.net/~aghaisas/fx/8195806/webrev.0/

Regards,
Ajit

Re: CFV: New OpenJFX Committer: Rajath Kamath

[Philip Race]

Vote: yes

-phil.

Re: OpenJFX JIRA Location

[Philip Race]

This mailing list is one option.

-phil.

On 1/7/18, 9:58 AM, Michael Paus wrote:
Your proposal will normally end up in the JIRA repository within 1-2 
days.
And then what? As we are not talking about a bug report here, the 
proposal will most
certainly raise some questions. Now how do you answer these questions? 
How do you

discuss issues with the responsible people?

Am 07.01.18 um 18:40 schrieb Philip Race:
You can go to https://bugreport.java.com/, scroll to the bottom and 
start a new bug report.


It goes into the same JIRA instance in a different project and is 
then trivially moved

(by someone with write access) to the JDK project.

Make sure you select javafx as the component.

-phil.

On 1/7/18, 6:52 AM, Michael Paus wrote:
The old JIRA has been moved here: 
https://bugs.openjdk.java.net/secure/Dashboard.jspa
But this won't help you very much unless you are already an OpenJDK 
author or more because

there is no public write access to this JIRA :-(

Am 07.01.18 um 15:06 schrieb Robert Hencke:

Hello,

I was looking to contribute some minor fix-ups to the OpenJFX build
scripts.  As part of this, I found the page on the developer 
workflow here:


https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow

It mentions that all contributions should first start with filing 
of a JIRA

issue.  However, the link to JIRA provided on this page (
https://javafx-jira.kenai.com/) does not seem to work.

Is the JIRA site down, or maybe it moved?

Thank you!
Robert

Re: OpenJFX JIRA Location

[Philip Race]

You can go to https://bugreport.java.com/, scroll to the bottom and 
start a new bug report.


It goes into the same JIRA instance in a different project and is then 
trivially moved

(by someone with write access) to the JDK project.

Make sure you select javafx as the component.

-phil.

On 1/7/18, 6:52 AM, Michael Paus wrote:
The old JIRA has been moved here: 
https://bugs.openjdk.java.net/secure/Dashboard.jspa
But this won't help you very much unless you are already an OpenJDK 
author or more because

there is no public write access to this JIRA :-(

Am 07.01.18 um 15:06 schrieb Robert Hencke:

Hello,

I was looking to contribute some minor fix-ups to the OpenJFX build
scripts.  As part of this, I found the page on the developer workflow 
here:


https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow

It mentions that all contributions should first start with filing of 
a JIRA

issue.  However, the link to JIRA provided on this page (
https://javafx-jira.kenai.com/) does not seem to work.

Is the JIRA site down, or maybe it moved?

Thank you!
Robert

Re: Turning off font anti-antialiasing patch

[Philip Race]

This should be closed as will not fix. FX assumes and requires unhinted 
metrics

so cannot work with B&W text which will not display properly with hinting.
Most fonts will render really-really badly if not hinted when using B&W.
Then there are the fonts which don't even have hints and so will render 
really-really badly anyway.


-phil.

On 1/2/18, 4:20 AM, François Jaouen wrote:

While porting a swing application to JavaFX 8, I had to patch JavaFX 8 to 
disable font anti-aliasing on linux.

But, for readibility of text,  I also had to reenable font hinting, in this 
case only.

Since, I've found this open bug 
https://bugs.openjdk.java.net/browse/JDK-8092207.

I will be glad to publish this contribution if it fits in OpenJFX plans. But as 
it requires some rework, let me know first if it has any interest.

François Jaouen

Re: CFV: New OpenJFX Committer: Laurent Bourgès

[Philip Race]

Vote: yes

-phil.

RFR: 8089900: [Mac, Font] NPE in MacFontFinder.populateFontFileNameMap

[Philip Race]

Bug: https://bugs.openjdk.java.net/browse/JDK-8089900
Webrev : http://cr.openjdk.java.net/~prr/8089900/

Reported numerous times over many years and releases.
Root cause in core text not known but we can avoid the NPE
Read the bug report and it's duplicates for more details.

-phil.

Re: Innovation again (was Re: Text classes)

[Philip Race]

There needs to be a viable community that is not just Oracle to support 
you here ..

I think everyone has come to be dependent on Oracle to "be there".
But if there is a specific community need that Oracle doesn't see as 
essential, then the community should help out.


-phil.

On 12/5/17, 9:27 PM, John-Val Rose wrote:

Well, that’s all fine but you didn’t address the issue of working with someone 
within Oracle to get these innovations done.

Sure, I could just toil away by myself but clearly it would be better all 
around if there was someone with much more extensive knowledge of JavaFX and 
its internals who was accessible when required.

I would assume that a member of the Oracle JavaFX team would be such a person. 
If not, then who?


On 6 Dec 2017, at 15:53, Philip Race  wrote:

I think looking at it as an Oracle-owned and controlled project maybe the first 
mistake here.
Yes it was closed source and then Oracle controlled, but not any more, OCA 
requirements aside.
It is not even a "java specification". It can be evolved at an API level 
without a JSR.
The JEP process is the main thing to be followed, although we also use CSRs too 
to track API.
Consider it that anyone who is a contributor owns (not the right word ?) a 
piece of it too.
So standing on the project is what matters. Not the company who pays you to 
work on it.

-phil.


On 12/5/17, 8:21 PM, John-Val Rose wrote:
Phil et. al.,

Whilst I’m not going to be quite as “passionate” as some on this issue 
(although I do understand the frustration), I would like to point out again 
that this is indeed a huge gap and it is critical that it is filled ASAP.

Obviously a solution where every word in a text document is a Node would be 
unworkable so it would need to be architected from the ground up.

I would be happy to work on such as feature, just as I was happy to work on 
implementing WebGL, but my hesitation is concern over the assistance and 
involvement from Oracle.

If I am going to have to spend months working on something without any or only 
minimal involvement from Oracle, only to find at the end that Oracle either 
doesn’t like the design, implementation or something else then it is wasted 
time I’ll never get back.

There are lots of other innovations too that I would like to see in JavaFX but 
I just don’t “feel the enthusiasm” from Oracle.

If there is someone on the JavaFX team who would be willing to work with me (at 
least in some capacity), please have them contact me privately via email.

The innovations I could work on and contribute include:

1. WebGL support in WebView
2. Better text support including text documents&   rich text editors etc.
3. Significant improvements in scene graph rendering speed using modern 
game-engine style structures and algorithms

JavaFX cannot survive without innovation and I am keen to see it happen and 
contribute as much as possible.

Graciously,

John-Val Rose
Rosethorn Technology


On 6 Dec 2017, at 11:36, jav...@use.startmail.com wrote:

Sorry about all the typos previously.

Question- why not use the code in awt ? I am not totally up on what's going on 
with the platforms' native rendering engines ( meaning, I have no idea 
whatsoever) or how they have changed, but golly it sure does still work pretty 
well.

  At least it seems to me looking at awt that a smallish number of things are 
1) well defined by the native platofrm and 2) would more or less translate 
directly to an Java API and 3) from those small number of building blocks, 
(Font and Glyph metrics and this kind of thing)   text line layout algorithms 
can be written by ordinary civilians along with all the other stuff that goes 
into a text editor.

And yes, everything does look easy when someone else is going to do it.

Re: Innovation again (was Re: Text classes)

[Philip Race]

I think looking at it as an Oracle-owned and controlled project maybe 
the first mistake here.
Yes it was closed source and then Oracle controlled, but not any more, 
OCA requirements aside.
It is not even a "java specification". It can be evolved at an API level 
without a JSR.
The JEP process is the main thing to be followed, although we also use 
CSRs too to track API.
Consider it that anyone who is a contributor owns (not the right word ?) 
a piece of it too.
So standing on the project is what matters. Not the company who pays you 
to work on it.


-phil.

On 12/5/17, 8:21 PM, John-Val Rose wrote:

Phil et. al.,

Whilst I’m not going to be quite as “passionate” as some on this issue 
(although I do understand the frustration), I would like to point out again 
that this is indeed a huge gap and it is critical that it is filled ASAP.

Obviously a solution where every word in a text document is a Node would be 
unworkable so it would need to be architected from the ground up.

I would be happy to work on such as feature, just as I was happy to work on 
implementing WebGL, but my hesitation is concern over the assistance and 
involvement from Oracle.

If I am going to have to spend months working on something without any or only 
minimal involvement from Oracle, only to find at the end that Oracle either 
doesn’t like the design, implementation or something else then it is wasted 
time I’ll never get back.

There are lots of other innovations too that I would like to see in JavaFX but 
I just don’t “feel the enthusiasm” from Oracle.

If there is someone on the JavaFX team who would be willing to work with me (at 
least in some capacity), please have them contact me privately via email.

The innovations I could work on and contribute include:

1. WebGL support in WebView
2. Better text support including text documents&  rich text editors etc.
3. Significant improvements in scene graph rendering speed using modern 
game-engine style structures and algorithms

JavaFX cannot survive without innovation and I am keen to see it happen and 
contribute as much as possible.

Graciously,

John-Val Rose
Rosethorn Technology


On 6 Dec 2017, at 11:36, jav...@use.startmail.com wrote:

Sorry about all the typos previously.

Question- why not use the code in awt ? I am not totally up on what's going on 
with the platforms' native rendering engines ( meaning, I have no idea 
whatsoever) or how they have changed, but golly it sure does still work pretty 
well.

  At least it seems to me looking at awt that a smallish number of things are 
1) well defined by the native platofrm and 2) would more or less translate 
directly to an Java API and 3) from those small number of building blocks, 
(Font and Glyph metrics and this kind of thing)   text line layout algorithms 
can be written by ordinary civilians along with all the other stuff that goes 
into a text editor.

And yes, everything does look easy when someone else is going to do it.

Re: CFV: New OpenJFX Committer: Ambarish Rapte

[Philip Race]

Vote: yes

-phil.

Re: WebView and WebGL

[Philip Race]

FWIW Java 2D ships OGL support on Windows (turned on by a flag) and our SQE
have occasionally dutifully run tests in that mode and regularly turn up
bugs that look like driver bugs. As a consequence FX decided to not ship it.
So although FX builds OGL support on all platforms it is excluded from the
windows product distribution.

-phil.

On 9/9/17, 9:51 AM, Sten Nordstrom wrote:

Having done some GL work on windows I've to agree with Mike. Windows GL
drivers can be a disaster. If you are able to specify hardware for your
users it's fine but if you take a random win-machine you are most likely in
trouble. So something like angle would probably be the safest way to get
EGL to work, especially as FX seems to use Direct3D on windows anyway.

And yes, doing it as Mike proposes one would get an EGL node on the way to
webgl.

-- Sten

Re: Review Request: JDK-8185954: Mac: JavaFx TextArea doesn't display the Emoji and Symbols on dropping them on the text area

[Philip Race]

Well... you had asked me what to do about the Emoji in the context of 
8176319
and I said to include it in that fix as you had there .. so I don't know 
what this separate bug

and webrev is about.
Seems like you should close it as a dup. and return to the previous bug ?

-phil.

On 8/18/17, 2:05 AM, Manajit Halder wrote:

Hi Phil,

Please review the fix.

Regards,
Manajit


On 08-Aug-2017, at 4:52 PM, Manajit Halder  wrote:

Hi All,

Kindly review the following JavaFx fix.

Bug: 
https://bugs.openjdk.java.net/browse/JDK-8185954
Webrev: 
http://cr.openjdk.java.net/~mhalder/fx/8185954/webrev.02/

Note: This fix is  related to issue 
https://bugs.openjdk.java.net/browse/JDK-8176319.

Regards,
Manajit

Re: [10] Review request: 8185017 Fix Bad Characters

[Philip Race]

+1

Although I am puzzled why I did not hit this before.

-phil.

On 7/20/17, 4:34 PM, Chris Bensen wrote:

Phil,

Please review this fix to remove the bad characters.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8185017
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8185017/webrev.00/

Chris

Re: [10] Review request for 8176844: Menus not always selected properly with GTK 3

[Philip Race]

AWT used to have really bad at X11 remote display and
it was looked at a few times and I think it was improved
noticeably when we could get rid of  "round trip" requests.
I think Jim had a hand in some of that work.

So I am sure a round trip - or similar - is bad for performance.

If you want to measure the effect of such change, remote display to
your desktop from a machine in a geographically distant site.

It is the latency that kills performance, not the bandwidth.

-phil.

On 4/4/17, 3:43 PM, David Hill wrote:

On 4/4/17, 1:27 PM, Semyon Sadetsky wrote:

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8176844

webrev: http://cr.openjdk.java.net/~ssadetsky/8176844/

--Semyon



Semyon,

I have been sitting here for a while thinking about adding
gdk_display_sync(gdk_display_get_default());

I can see why this might address many issues, as it flushes the 
pipeline and waits for the X11 server to catch up. That is balanced 
out by a historical distrust of using XSync in any situation where the 
consequences.


Part of me thinks it is minimal overhead though, the other part does 
not like stalling the asynchronous X11 design.


The other part of me would like to use this only for the window events 
that need it, instead of all of them.


and I found this in hte GTK docs:
gdk_events_pending ()
Waits for a GraphicsExpose or NoExpose event from the X server. This 
is used in the GtkText and GtkCList widgets in GTK+ to make sure any 
GraphicsExpose events are handled before the widget is scrolled.


so perhaps this should be used in some cases (like setVisible).

sigh.

Will try to make up my mind tomorrow.

Dave.

RFR: 8177751: Update FX implementation to prepare renaming of Module and Layer classes

[Philip Race]

David, Vadim, Jonathan, Guru - please review.

Bug: https://bugs.openjdk.java.net/browse/JDK-8177751
webrev: http://cr.openjdk.java.net/~prr/8177751/

In tidying up the module system API towards the end of the release,
the jigsaw team have determined that Module and Layer classes are
core concepts like Class and need to be moved into java.lang out of
java.lang.reflect. See links in the bug for more details.

There are references to these classes in javafx. Notably in the launcher.
If the jigsaw change is pushed without FX being updated first all FX
apps will simply cease to work - there is an exception on start up.

The change here is to use reflection to find the actual class at runtime.
This therefore works both before + after the proposed change.

The exact "wording" of the changes, eg notably things like the javadoc
changes are not important as we'll revert these back later once the
jigsaw changes are in promoted builds and so forth.

The ModuleAccess class will likely disappear again too.

So the important issue here is whether it works.

I've built + tested against jdk9 (without the package change) and
the jake forest (with the package change) and all tests I've run
(gradle test, controls tests, Ensemble) seem to work fine.

We've looked hard for any other places that may be affected and think
what is in this webrev is all. Still it would be helpful if folks familiar
with particular areas could check for any problems they may know about.

-phil.

Re: Testing your JavaFX applications on JDK 9

[Philip Race]

I was asking about the VM not the O/S.

32 bit or 64 bit in this case.

Notably the 32 bit client VM is gone so you get the 32 bit server VM.
That could make a difference, although in theory the server VM performs 
better - so

long as it does not run out of memory.

-phil.

On 1/26/17, 6:44 PM, Scott Palmer wrote:

I’ve only tested with Java 9 on Windows 10 64-bit so far.

I have not yet done any profiling to try to isolate where the difference might 
be.  The application generates data in native code, wrapped in a native 
ByteBuffer and passes an object around holding the buffer and map of properties 
to go with it.  I’m doing virtually no processing on the data and just 
measuring the rate that packets are going through the workflow so far.  The GUI 
is mostly static during the test except for a table and some labels showing 
stats that are updated with bitrates, packet rates, timestamps etc.

I’ll continue to try to isolate a test case that I can share as time allows.  I 
should be able to get some testing done on Mac and Linux as well and will send 
a followup email with any new information.

Regards,

Scott



On Jan 26, 2017, at 9:37 PM, Philip Race  wrote:

Scott,

What VM/bitness/platforms show this ? All or just a specific one ?

-phil.

On 1/26/17, 6:08 PM, Kevin Rushforth wrote:

Hi Scott,

Thanks for the report. The only JDK 9 specific performance problems I have seen 
is with startup, which would be a good thing to discuss on jigsaw-dev. If you 
are seeing actual application slowdown, that might be something else, depending 
on where the problem is. Have you profiled your application?

-- Kevin


Scott Palmer wrote:

I finally managed to get my app running on JDK 9.  It is based on a plugin 
architecture and the plugins are made accessible by modifying the system class 
loader at runtime (because that seemed to be the only way to make things like 
JAXB able to reach the classes in the plugins).  That “hack” broke with the 
module system so I had to find an alternative.  (Now I’m using a java agent to 
get an Instrumentation interface so I can do it in a somewhat supported way via 
the appendToSystemClassLoaderSearch method.)

Anyway, I’ve noticed that the application runs slower on Java 9.  For a simple 
test I see almost a 10% performance drop.  However, I’m not sure that it is 
Java FX related.  I see the same throughput with the default renderer or the 
recently added Marlin renderer, always a bit slower than Java 8u121.  I use the 
same JVM options, including forcing the garbage collector to use the same 
algorithm.

Is there any expectation of a performance drop with JDK 9 at this stage?  For 
example should I expect some unoptimized stuff in the EA builds?
I guess the jigsaw-dev alias the right place to bring this up?

I have a feeling it is going to be difficult to track down. :-(

I have noticed a couple layout issues fixed with JavaFX 9. Stuff that used to 
“snap into place” only when I resized a dialog now seems to be correct when the 
dialog first appears. Thanks for that!

Regards,

Scott



On Jan 11, 2017, at 2:14 PM, Kevin Rushforth  wrote:

As you may know JDK 9 has hit the feature extension complete milestone [1]. We 
still have a small number of weeks to fix P1-P3 bugs, but we need to know about 
them in order to fix them. Our focus will be on bugs that are new in JDK 9 
(regressions).

I ask all JavaFX developers to please download JDK 9 early access [2] and test 
your application. You can report any bugs via bugs.java.com [3]. If you have 
any questions about whether a behavior is a bug or is expected, please ask on 
this alias or on the jigsaw-dev alias [4].

Thank you.

-- Kevin

[1] http://openjdk.java.net/projects/jdk9/
[2] https://jdk9.java.net/download/
[3] http://bugreport.java.com/
[4] jigsaw-...@openjdk.java.net

Re: Testing your JavaFX applications on JDK 9

[Philip Race]

Scott,

What VM/bitness/platforms show this ? All or just a specific one ?

-phil.

On 1/26/17, 6:08 PM, Kevin Rushforth wrote:

Hi Scott,

Thanks for the report. The only JDK 9 specific performance problems I 
have seen is with startup, which would be a good thing to discuss on 
jigsaw-dev. If you are seeing actual application slowdown, that might 
be something else, depending on where the problem is. Have you 
profiled your application?


-- Kevin


Scott Palmer wrote:
I finally managed to get my app running on JDK 9.  It is based on a 
plugin architecture and the plugins are made accessible by modifying 
the system class loader at runtime (because that seemed to be the 
only way to make things like JAXB able to reach the classes in the 
plugins).  That “hack” broke with the module system so I had to find 
an alternative.  (Now I’m using a java agent to get an 
Instrumentation interface so I can do it in a somewhat supported way 
via the appendToSystemClassLoaderSearch method.)


Anyway, I’ve noticed that the application runs slower on Java 9.  For 
a simple test I see almost a 10% performance drop.  However, I’m not 
sure that it is Java FX related.  I see the same throughput with the 
default renderer or the recently added Marlin renderer, always a bit 
slower than Java 8u121.  I use the same JVM options, including 
forcing the garbage collector to use the same algorithm.


Is there any expectation of a performance drop with JDK 9 at this 
stage?  For example should I expect some unoptimized stuff in the EA 
builds?

I guess the jigsaw-dev alias the right place to bring this up?

I have a feeling it is going to be difficult to track down. :-(

I have noticed a couple layout issues fixed with JavaFX 9. Stuff that 
used to “snap into place” only when I resized a dialog now seems to 
be correct when the dialog first appears. Thanks for that!


Regards,

Scott


On Jan 11, 2017, at 2:14 PM, Kevin Rushforth 
 wrote:


As you may know JDK 9 has hit the feature extension complete 
milestone [1]. We still have a small number of weeks to fix P1-P3 
bugs, but we need to know about them in order to fix them. Our focus 
will be on bugs that are new in JDK 9 (regressions).


I ask all JavaFX developers to please download JDK 9 early access 
[2] and test your application. You can report any bugs via 
bugs.java.com [3]. If you have any questions about whether a 
behavior is a bug or is expected, please ask on this alias or on the 
jigsaw-dev alias [4].


Thank you.

-- Kevin

[1] http://openjdk.java.net/projects/jdk9/
[2] https://jdk9.java.net/download/
[3] http://bugreport.java.com/
[4] jigsaw-...@openjdk.java.net

Re: Question/discussion about JDK-8129582

[Philip Race]

The cache is a heuristic optimisation and whether it helps depends on 
how well that cache is used.
It is a time-space trade-off and I'd expect it to show up as helping 
more in micro-benchmarks or

text-intensive benchmarks which use the same text broken in the same way.
Complex text layout is inherently slower and if you are doing a lot of 
it .. it will be slow .. and

unless it is repeated a cache won't help.
During start-up I'd *expect* that there isn't a lot of re-use going on.

You would need to profile how often  the same text (and attributes) are 
passed through this code.

If you could provide us a test case we could examine it too.

If it were a real use case, then we'd move on to examine the feasibility 
of caching ...


-phil.


On 1/4/17, 9:19 AM, Itai wrote:

Recently JDK-8129582 [1] started really affecting me, with startup speed
and overall responsiveness becoming really bad.

Digging into it, I have found most time is wasted in
com.sun.javafx.text.GlyphLayout.layout (as represented by PangoGlyphLayout
on my Linux machine), which in turn is called
by com.sun.javafx.text.PrismTextLayout.shape, which has:

 if (run.isComplex()) {
 /* Use GlyphLayout to shape complex text */
 layout.layout(run, font, strike, chars);
 } else {
 ...
 if (layoutCache == null) {
  ...
  } else {
   ...
  }
 }

which to my very naive reading seems as if while non-complex (with all BiDi
text considered complex) glyph runs are cached, complex runs are never
cached, which forces re-calculation every time.

I'm trying to read and understand this part better, but could it be
possible that this is the issue? How feasible would it be to have a layout
cache for complex runs, or at least non-complex BiDi runs?

Thanks,
Itai.

[1]:  https://bugs.openjdk.java.net/browse/JDK-8129582

Re: What does the nicetohave label in JIRA mean?

[Philip Race]

This one is still targeted to 9, and so far as I can tell that has 
always been the case.
The "release team" for the whole JDK 9 release have allowed that bugs 
that existed

in 8 GA may be deferred out of 9 if there is not time to fix them.
The logic behind that is (I think) that it is not a regression that 
stops you moving

from 8 to 9 if it already existed since 8 GA.
This one is more subtle than that .. it did not start to manifest until 
versions

of MacOS later than any available when 8 GA shipped.

Regardless of labels it is clear that this is one that needs to be 
addressed.


-phil.


On 9/13/16, 8:10 AM, Kevin Rushforth wrote:
We're using that label to track JavaFX, AWT, Java2D, and Swing bugs 
that have been moved out of JDK 9, but which we would still like to 
fix if time permits.


-- Kevin


Scott Palmer wrote:
I just noticed it was applied to a bug I am watching, JDK-8089573 
(JavaFX

printing does not work on Mac)
The issue seems to be more critical to me than what the words 
"nicetohave"

would imply, but perhaps it simply means that it has been deferred?

Scott

RFR: 8087632: The printer job status shows "ERROR" after setting the pages range and printing the content.

[Philip Race]

Bug : https://bugs.openjdk.java.net/browse/JDK-8087632
Webrev: http://cr.openjdk.java.net/~prr/8087632/

Eval. is in the JBS bug.

-phil.

Re: Compiling OpenJFX on OpenBSD

[Philip Race]

On 8/4/16, 7:18 AM, David Hill wrote:

On 8/4/16, 9:50 AM, Turvamies IT Security Services wrote:

Hello, world!


This really looks like a Gradle failure to me. 


That is what I said when this was posted to build-dev.

First there is the bit about the lock being held, then issues with the 
cache (are you behind a blocking firewall, proxy set ?), then the 
exceptions in gradle itself.


I think most of the team is using Gradle 2.11, so it might be remotely 
possible that is the issue too.


2.13 works for me but I am not using BSD ...



I would assume you have looked at: 
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX,


There are prebuilt binaries out there if you just want to have 
binaries to play with:


   http://chriswhocodes.com/


None of these are for BSD (SFAICS).

-phil.



Apologies for the cross post, but since the bsd-port-dev list appears 
to be

very quiet (and since I'm in a hurry), I'll post my question here too.

I'm attempting to compile OpenJFX (rt-b41445afa464) on OpenBSD CURRENT
(2016-08-04) since the official OpenBSD package (and port) of OpenJDK
does not include OpenJFX.

I have managed to install and/or compile all the dependencies,
including gradle, but got stuck while compiling OpenJFX itself:

$ pwd
/tmp/rt-b41445afa464

$ env
JAVA_HOME=/usr/local/jdk-1.8.0
JDK_HOME=/usr/local/jdk-1.8.0
JRE_HOME=/usr/local/jdk-1.8.0
PATH=/usr/local/jdk-1.8.0/bin:/tmp/.gradle/wrapper/dists/gradle-2.14-bin/76oc0mnc3ieqtsukq90mp0rxk/gradle-2.14/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin 



$ gradle --debug
[...]
08:38:44.707 [INFO] 
[org.gradle.configuration.project.BuildScriptProcessor] Evaluating 
root project 'rt-b41445afa464' using build file 
'/tmp/rt-b41445afa464/build.gradle'.


08:38:44.727 [DEBUG] 
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire 
shared lock on cp_proj remapped class cache for 
ctdme4j40oppm9q0pdgqhpn3y 
/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/cp_proj-1283120199659856910).


08:38:44.728 [DEBUG] 
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.


08:38:44.729 [DEBUG] 
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on 
cp_proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y 
(/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/cp_proj-1283120199659856910).


08:38:44.732 [DEBUG] 
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire 
shared lock on proj remapped class cache for 
ctdme4j40oppm9q0pdgqhpn3y 
(/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/proj-1283120199659856910).


08:38:44.733 [DEBUG] 
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.


08:38:44.734 [DEBUG] 
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on 
proj remapped class cache for ctdme4j40oppm9q0pdgqhpn3y 
(/tmp/.gradle/caches/2.14/scripts-remapped/build_17kvkvc4f9j45htivwn1v303b/ctdme4j40oppm9q0pdgqhpn3y/proj-1283120199659856910). 



08:38:45.852 [INFO] [org.gradle.api.Project] Applying 
COMPILE_FLAGS_FILE 'buildSrc/.gradle'


08:38:45.859 [DEBUG] 
[org.gradle.configuration.project.BuildScriptProcessor] Timing: 
Running the build script took 1.151 secs


08:38:45.902 [ERROR] [org.gradle.BuildExceptionReporter]

08:38:45.904 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: 
Build failed with an exception.


08:38:45.906 [ERROR] [org.gradle.BuildExceptionReporter]

08:38:45.907 [ERROR] [org.gradle.BuildExceptionReporter] * Where:

08:38:45.908 [ERROR] [org.gradle.BuildExceptionReporter] Build file 
'/tmp/rt-b41445afa464/build.gradle' line:


614 08:38:45.909 [ERROR] [org.gradle.BuildExceptionReporter]

08:38:45.910 [ERROR] [org.gradle.BuildExceptionReporter] * What went 
wrong:


08:38:45.911 [ERROR] [org.gradle.BuildExceptionReporter] A problem 
occurred evaluating root project 'rt-b41445afa464'.


08:38:45.912 [ERROR] [org.gradle.BuildExceptionReporter]>  String 
index out of range: 0


08:38:45.912 [ERROR] [org.gradle.BuildExceptionReporter]

08:38:45.913 [ERROR] [org.gradle.BuildExceptionReporter] * Try:

08:38:45.914 [ERROR] [org.gradle.BuildExceptionReporter] Run with 
--stacktrace option to get the stack trace.


08:38:45.916 [LIFECYCLE] [org.gradle.BuildResultLogger]

08:38:45.917 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD FAILED

08:38:45.918 [LIFECYCLE] [org.gradle.BuildResultLogger]

08:38:45.919 [LIFECYCLE] [org.gradle.BuildResultLogger] Total time: 
29.999 secs


08:38:45.931 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] 
Cache Plugin Resolution Cache 
(/tmp/.gradle/caches/2.14/plugin-resolution) was closed 0 times.


I don't quite know how to debug this further.

Any tips would be much appreciated!

Yours,

Jyri
--
Turvamies IT Security Services

P.S. FYI, here's gradle --debug output:

:buildSrc:generateGrammarSource UP-TO-DATE
:buildSrc:co

Re: CFV: New OpenJFX Committer: Andrey Rusakov

[Philip Race]

Vote: yes

-phil.

Re: early draft for 8087516: [JavaFX] Conditional support for GTK 3 on Linux

[Philip Race]

That may be [need to be] ironed out later.
We are not certain there is a 100% reliable mechanism for this.
Some experiments on the AWT equivalent using dlopen(..) with
RTLD_NOLOAD is apparently failing to detect that gtk3 was loaded
in the case it was loaded by SWT.

An alternative but not very pretty approach using /proc has been proposed.
'
Any boiler plate code that works across all versions of Linux/Unix and
where you do not control the manner in which gtk3 was loaded is proving 
elusive.


And nothing will help in the case that FX is loaded first and gtk/swt is 
loaded later.


-phil.


On 4/23/16, 10:32 AM, Tom Schindl wrote:

David / Kevin,

Do you see chances to detect for the SWT case if we are running with SWT
on Gtk3 or Gtk2 and not having to use -Djdk.gtk.version=3

The problem with requiring one to switch by setting the System-Property
is that eg if someone want to use FX in the Eclipse IDE he does not
control the Java-Launch Process.

Tom

On 23.04.16 00:50, David Hill wrote:

Kevin, Phil, anyone else interested.

Here is an early draft of [JavaFX] Conditional support for GTK 3 on
Linux

http://cr.openjdk.java.net/~ddhill/8087516.1/

There are some rough edges left, particularly with the GTK 3 side of
shaped windows.
Given my time frame, I am interested in feedback on what is there
because the core of it is complete.

I have done limited testing on this, some with GTK3 and have not found
any problems so far. I have more unit testing planned for next week.

The default GTK version will be GTK2. To use GTK3, use the following:

-Djdk.gtk.version=3

To enable some really verbose output:

 -Djdk.gtk.verbose=true

This verbosity will be reduced before I commit this - and only a message
about the version actually used will be output.

Known issues: Marked with a DAVE for easy cleanup later.
 * shaped windows with GTK3 - need to verify the new region methods
 * debug code that will be used to check that all of the code paths
are tested.
 * move the disableGrab back into the main code logic.

Re: FTFactory.java: Fonts loaded by Pango are never registered and always return

[Philip Race]

Since I don't see any code here that looks like it would run only on
an embedded environment then I wonder why Linux desktop users
are not reporting the same problem ?

Did your instrumentation check that both dlopen & dlsym succeeeded ?

-phil.

On 3/3/16, 7:43 AM, Maurice wrote:
Hmm  I think I have to agree with you... you are right. Commenting 
it in didn't give a compiler or linkage error, and it made it work. 
I'm happy at the moment and tired of the debugging process, but I'll 
give it more thought later.


Op 03-03-16 om 16:36 schreef Mario Torre:

On Thu, Mar 3, 2016 at 2:48 PM, Maurice  wrote:

At the moment the embedded environment I'm using is not able to use
downloaded or external supplied fonts. I've traced through the 
system and

found that it looks like it fails in pango.c FcConfigAppFontAddFile, at
least OSPango.FcConfigAppFontAddFile returns false, thus propagating 
a null

all the way up.

Checking the pango.c file I noticed something very interesting:
JNIEXPORT jboolean JNICALL OS_NATIVE(FcConfigAppFontAddFile)
 (JNIEnv *env, jclass that, jlong arg0, jstring arg1)
{
 static void *fp = NULL;
 if (!fp) {
 void* handle = dlopen(LIB_FONTCONFIG, RTLD_LAZY);
 if (handle) fp = dlsym(handle, "FcConfigAppFontAddFile");
 }
 jboolean rc = 0;
 if (arg1) {
 const char *text = (*env)->GetStringUTFChars(env, arg1, NULL);
 if (text) {
//rc = (jboolean)FcConfigAppFontAddFile(arg0, text);
 if (fp) {
 rc = (jboolean)((jboolean (*)(jlong, const char 
*))fp)(arg0,

text);
 }
 (*env)->ReleaseStringUTFChars(env, arg1, text);
 }
 }
 return rc;
}

Yes, you see it correctly! The line that actually should register 
the font

Pointer to functions make me blind too, but If I'm not reading it
wrong, I think this is not a commented code call, it's meant to tell
what the code below it does (apparently, it made blind also the
author!):

FcConfigAppFontAddFile is dloaded into fp, so this totally
incomprehensible line:

((jboolean (*)(jlong, const char *))fp)(arg0, text);

it's just casting fp to a function that returns a jboolean and takes a
jlong and a const char array as argument, hence it becomes again:

(jboolean)FcConfigAppFontAddFile(arg0, text);

Cheers,
Mario

Re: Canvas Clip performance

[Philip Race]

On 2/4/16, 2:59 PM, Elric Morgenstern wrote:

I see. Interesting. Isn't there a switch to toggle it on JDK8?


There is no switch that can enable it if it is disabled by 'default'.


Assuming you are talking about JavaFX, right? Because you were referring to
Java2D in your reply.


No I am talking about 2D. What I meant was that maybe the performance issue
is inherent in the card and the only reason it looks OK with Java2D on 
Intel is
that we aren't using anything much at all of the Intel chip and are 
doing the work

on the cpu instead.

-phil.



On Thu, Feb 4, 2016 at 11:52 PM, Philip Race  wrote:


Java 2D does not (generally) enable D3D on Intel.
We tried for JDK 8 but there were problems and it was disabled again in
8u40 I think.
JDK 9 EA builds (currently) still have it enabled to help get some testing
so
if you are running an 8ux release you might want to switch to 9 to get a
fairer comparison.

-phil.



On 2/4/16, 2:49 PM, Elric Morgenstern wrote:


Hi guys,

I've noticed that clipping performance (Canvas GraphicsContext) is
extremely bad on an Intel HD graphics chip. One rectangular clip is fine,
anything beyond that, or a spherical clip shape, will bring the framerate
to its knees.

I notice no performance difference on my GeForce system, but on the
integrated chip my application is basically insufferable.

The same thing performed with Java2D experiences no performance issues on
neither system.

Any ideas?

Re: Canvas Clip performance

[Philip Race]

Java 2D does not (generally) enable D3D on Intel.
We tried for JDK 8 but there were problems and it was disabled again in 
8u40 I think.
JDK 9 EA builds (currently) still have it enabled to help get some 
testing so
if you are running an 8ux release you might want to switch to 9 to get a 
fairer comparison.


-phil.


On 2/4/16, 2:49 PM, Elric Morgenstern wrote:

Hi guys,

I've noticed that clipping performance (Canvas GraphicsContext) is
extremely bad on an Intel HD graphics chip. One rectangular clip is fine,
anything beyond that, or a spherical clip shape, will bring the framerate
to its knees.

I notice no performance difference on my GeForce system, but on the
integrated chip my application is basically insufferable.

The same thing performed with Java2D experiences no performance issues on
neither system.

Any ideas?

Re: including fonts

[Philip Race]

Hi,
That was a bit too vague for me to know what you mean.

Also there is no relationship with "AWT" (actually "Java 2D") fonts.
The Java FX API and implementation is completely independent of
anything in the core Java SE platform.

One point that might not have been clear enough is that you
shouldn't expect (for example) DirectWrite or CoreText to
understand the semantics of CSS and directly support accepting
CSS style parameters and managing CSS contexts. All of that
needs to belong to an "application layer" which is what the brower 
really  is,

and sits on top of those platform APIs.
And in this case the equivalent is the FX CSS implementation which sits
on top of the FX font API.

-phil.

On 1/5/16, 5:35 AM, Tom Eugelink wrote:
It should, but it does not. It seems the whole font management is 
based on AWT Font and that is missing a lot of CSS features.


Tom

On 4-1-2016 22:46, Phil Race wrote:

Hi,

I'm not certain I understand what it is that is missing.
I don't think Font.loadFont would need to accept the CSS parameters
and do the CSS-style lookup. @font-face should populate a CSS table
of names and styles. I expect that is what browsers do.
The CSS lookup code would then consult this internal table of fonts 
loaded

for the current CSS context and then ask the font system to use the one
that corresponds. If there is no match then it would be assumed it is a
request for a system provided font.

One thing that might be missing in Font.loadFont() is a way to keep 
the CSS
loaded fonts partioned. And there's a need for deriving a font with 
different attributes

as simple as a different size.


-phil.


On 01/04/2016 01:36 PM, David Grieve wrote:
The reason CSS ignores everything but src is that there is no public 
API in Font for providing the additional information.


CSS uses Font.loadFont to load a font from a @font-face src url. See 
com/sun/javafx/css/StyleManager.java


On 1/4/16 2:43 PM, Phil Race wrote:

Hi,

I can't speak authoritatively on the CSS implementation because I 
am not
familiar with it but here are some thoughts and observations that 
might help.


Suppose you have :
@font-face {
  font-family: RobotoMedium
  src: url("robotomedium.ttf"
}

My reading of the W3C spec. is that the name you specify as 
font-family
is used by CSS as the family name regardless of the *actual* name 
of the font
but I don't think FX can be working like that if it ignores 
font-family.


If CSS is ignoring everything except src that seems like
you then need to know for sure yourself what the family + style of 
the font is

and per that bug then use it via fx-font using the actual name+style.
This suggests CSS is loading the font into the list of fonts 
available to be used

by creating fonts directly from JavaFX API.
This seems to be confirmed by you seeing that Font.getFontNames()
reports these.

So you'd need to do the following for both font files
ie.

@font-face {
  font-family: BlahBlahDoesNotMatterApparently
  src: url("robotomedium.ttf")
}


@font-face {
  font-family: BlahBlahDoesNotMatterEither
  src: url("robotomediumitalic.ttf")
}

and reference as :

-fx-font: normal normal 12 "Roboto Medium"
-fx-font: italic normal 12 "Roboto Medium"

If this does not work then I don't know what CSS might be doing in 
its lookup.
The comment about only the last one loaded being available does not 
add up to me

unless CSS is doing some buggy filtering or remembering of its own.
Perhaps explicitly specifying "normal" will fix that.

-phil.

On 01/04/2016 12:08 AM, Tom Eugelink wrote:

No problem, thanks for the suggestion!

What I expect to be the cause is that the attributes in 
@font-face, specifying if a font is italic or not, are not 
supported. And they probably aren't populated based on the TTF 
metadata either. But before I dive too deep, maybe someone can 
prevent me from swimming in the wrong direction.


Tom


On 4-1-2016 00:02, cogmission (David Ray) wrote:
I guess I was assuming the "ideal"/expected behavior applied? 
Sorry...


On Sun, Jan 3, 2016 at 10:14 AM, Tom Eugelink > wrote:


Hi David,

Which would assume that if I specify no keywords, then it 
should take the normal version. It does not. Whatever version is 
loaded last is used.


Tom



On 3-1-2016 17:09, cogmission (David Ray) wrote:

Hi Tom,

I Believe in CSS, once you establish the family you can 
access the sub-types via type keywords?

...via

-fx-font-weight: bold,bolder etc.
-fx-font-style: plain, italic

Cheers,
David

On Sun, Jan 3, 2016 at 8:52 AM, Tom Eugelink 
mailto:t...@tbee.org> >> wrote:


Addendum:

If I list the font families using Font.getFamilies() 
I get "Roboto Medium" once, given that both TTF files are added 
using @font-face. But if I examine Font.getFontNames() I get 
separate entries for "Roboto Medium" and "Roboto Medium Italic". 
Closer e

Re: Java 9 Questions

[Philip Race]

On 11/19/2015 11:49 AM, Scott Palmer wrote:

I was just looking at the Java 9 EA pages and have a few questions (mostly 
JavaFX related).

- There is a separate download for Java 9 + Jigsaw, but it has a much earlier 
build number (b86).  Is Jigsaw not included with the  of the latest (b92) 
download?

- When looking at the Java 9 JEPs I see several that are UI related:
   - JEP 251: Multi-resolution Images
   - JEP 258: HarfBuzz Font-Layout Engine
   - JEP 265: Marlin Graphics Renderer

All of these refer to Java2D or AWT.   How is JavaFX affected?  Is there no 
common ground for things like multi-resolution images and font layout for 
example?


FX already has multi-res image support.
But none of these JEPS directly relate to FX.



It is already cumbersome to deal with things like ImageIO because it depends on 
Java2d images and conversion is required to use JavaFX images.  How does Jigsaw 
help with this?  I hope I don’t have to pull in AWT/Swing just to load an image 
with ImageIO so that I can show it in my JavaFX application. (Too bad images or 
some base image class could not be made neutral to the UI toolkit being used.)
I think there must be at least three different image loading mechanisms in the 
JDK now.  Are there plans to consolidate this?

jigsaw delivers all of AWT/2D/Swing as one module so won't help you reduce
dependence on that if you need Image I/O. It was recognised a while back
that JavaFX needs more support in imaging and image format support but
it is not for JDK 9.

Core SE had 4 image loading mechanisms
1) Toolkit.createImage (jdk 1.0)
2) com.sun.image.codec.jpeg  (jdk 1.2 not standard, now retired)
3) Image I/O (1.4)
4) splashscreen (1.6)


add FX and there is one more.

IJG is at the bottom of all the JPEG support although versions differ.


Just curious where things are heading.


Consolidation is somewhat at odds with the module system here.
If FX depends on java.desktop it is nearly impossible to consolidate all 
these
so they can be shared as they are so much intertwined with the rest of 
the java.desktop module.


Leaving aside SE, it is clear that FX needs more imaging support and how
it is done should not add gobs of footprint or dependencies.

-phil.


Thanks,

Scott

hg: openjfx/8u-dev/rt: Fixed RT-37480: [Printing] Cups - incorrect paper size

[philip . race]

Changeset: 68105c7c4740
Author:prr
Date:  2014-07-18 12:32 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/68105c7c4740

Fixed RT-37480: [Printing] Cups - incorrect paper size
Reviewed-by: kcr

! modules/graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinter.java
+ tests/manual/printing/TestMargins.java