JavaFX features in JDK 9
I realise we are a long way off JDK 9 still and with crucial features such as Jigsaw still a little up in the air but is it possible someone could itemise the most likely new features, enhancements and bug fixes that we will see in JavaFX when JDK 9 is released? Of course it's purely speculation at this point but it would assist me greatly to have some of idea of where JavaFX is heading and which areas are seen as most important. Thanks, Felix
Re: JavaFx: printer dialog is shown behind main window(stage)
Hi Alexander, this seems to be a known bug: https://bugs.openjdk.java.net/browse/JDK-8088395 Rgds Werner On 15.06.2015 07:54, Александр Свиридов wrote: The printer dialog appears. But! it appears behind the main window but not in front of main window! This strange behaviour happens only when dialog appears the first time. The second and other times it's in front of the main window. How to fix it?
In(Sanity) Testing Mondays
Reminder, Monday (today) is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PDT until 1pm PDT. Happy testing! Thanks. -- Kevin
Re: Font rendering hints - RT-36146 - progress?
It is one of many RFEs that we might consider for JDK 9, but have not committed to. I don't think Phil has looked into it recently, but perhaps he can provide an update on it. -- Kevin Felix Bembrick wrote: Has anyone had a look at this, done some work on it or can provide some details as to its progress? Thanks, Felix On 11 June 2015 at 13:50, Felix Bembrick felix.bembr...@gmail.com wrote: I am following this one closely and hoping that some progress has been made and that a fix is planned but it's difficult to determine from the JIRA issue. Does anyone have any additional info on where this issue is at? Thanks, Felix
[8u60,9] review request: 8088823: Advanced Media Player tab does not respond to Time slider on Windows
Hi Alexander, Kevin. Could you please review the following fix? jbs: https://bugs.openjdk.java.net/browse/JDK-8088823 wevrev: http://cr.openjdk.java.net/~stayer/8088823/webrev.00/ Please review and comment in JBS. This patch partly fixes regression after https://bugs.openjdk.java.net/browse/JDK-8092944 and partly fixes missing parts. In JDK-8092944 DeliverSample fails in CBaseOutputPin::GetDeliveryBuffer with E_NOINTERFACE because m_pAllocator is NULL. So this patch does not ignore all errors that are not E_FAIL. Patch in gstqueue.c allows to generate GST_ELEMENT_ERROR even if there is no eos in the queue. Without this part _loop task is silently stops and application is not generating any errors. Patch in flvdemux.c just cleans redundancy. It's just not necessary. I'd say that some SQE effort is necessary for testing this patch better. K
Bug report: HostServicesFactory on Linux needs a more complete browsers list
The file HostServicesFactory.java (I cannot find it in the JFX8+ repo)
contains this line of code, for Linux. It should be re-arranged and
extended for better compatibility:
- static final String[] browsers = new String[]{google-chrome,
firefox, opera, konqueror, mozilla};
+ static final String[] browsers = new String[]{xdg-open,
gnome-open, google-chrome, chromium, firefox, opera,
konqueror, mozilla};
Re: Font rendering hints - RT-36146 - progress?
If you can figure out some apps for which there is source and provide those tweaks that might help understand the differences but I am not sure it will be as straightforward as you hope. -phil.. On 6/15/15 1:52 PM, Felix Bembrick wrote: The thing is that the way DirectWrite is utilised now by JavaFX either through which hints are applied by default or by some other way, the result is text which does not render exactly the same way as (almost) every native Windows application that also utilises DirectWrite. Wouldn't a simpler solution (or at least a first step) be just to tweak the hints and options until JavaFX font rendering on Windows matches the way native apps do it? I believe at the moment all the default options are selected so perhaps experimenting with some of the non-default options or examining actual code of some native apps to see which options/hints they are setting would arrive at a best match configuration that could replace the all defaults configuration we have now? Then, later down the track, these hints/options could potentially be made user-configurable. On 16 June 2015 at 06:05, Phil Race philip.r...@oracle.com mailto:philip.r...@oracle.com wrote: I would have to look at it starting more or less from scratch and I do not know that it would be as simple as providing a way to tweak DirectWrite rendering. The differences seem to be quite small differences in sub-pixel intensity and sub-pixel accumulation of the total advance. I do not know what API or client produced the 'native' rendering. And what if someone else wants something different again ? So I am not sure when we will get to looking into this and deciding if it makes sense. -phil. On 06/14/2015 02:31 PM, Felix Bembrick wrote: Has anyone had a look at this, done some work on it or can provide some details as to its progress? Thanks, Felix On 11 June 2015 at 13:50, Felix Bembrick felix.bembr...@gmail.com mailto:felix.bembr...@gmail.com wrote: I am following this one closely and hoping that some progress has been made and that a fix is planned but it's difficult to determine from the JIRA issue. Does anyone have any additional info on where this issue is at? Thanks, Felix
HiDPI in monocle
Hi, With the changes introduced in the fix for RT-27960 ( https://bugs.openjdk.java.net/browse/JDK-8098184), the hidpi support on Android is broken. As part of the changes in http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/670ed25ed138, we introduced a getScale method on NativeScreen, and the result of this method was used in the constructor of Screen (See MonocleApplication.java). As an example, on a Nexus 5 the getScale() would return 3.0, as the device has 1920x1080 physical pixels but we use a Scene with dimensions 640x360. I'm not sure how to map this getScale() to the new getPlatformScale() and getRenderScale() though? - Johan
Re: Font rendering hints - RT-36146 - progress?
I would have to look at it starting more or less from scratch and I do not know that it would be as simple as providing a way to tweak DirectWrite rendering. The differences seem to be quite small differences in sub-pixel intensity and sub-pixel accumulation of the total advance. I do not know what API or client produced the 'native' rendering. And what if someone else wants something different again ? So I am not sure when we will get to looking into this and deciding if it makes sense. -phil. On 06/14/2015 02:31 PM, Felix Bembrick wrote: Has anyone had a look at this, done some work on it or can provide some details as to its progress? Thanks, Felix On 11 June 2015 at 13:50, Felix Bembrick felix.bembr...@gmail.com wrote: I am following this one closely and hoping that some progress has been made and that a fix is planned but it's difficult to determine from the JIRA issue. Does anyone have any additional info on where this issue is at? Thanks, Felix
8u-dev and 9-dev unlocked -- Rampdown rules in effect for 8u-dev
8u-dev and 9-dev are open following this week's testing. As previously communicated [1] and stated on the JavaFX Wiki [2] the following rampdown rules for 8u60 are in effect this week for pushing changes to 8u-dev: Mon, Jun 15 to Sun, Jun 21 -- regressions and critical bugs only, pre-commit review required All bug fixes require a pre-commit review; an exception is made for changesets that do not touch shipping code, such as fixes to unit tests and non-shipping examples/toys Changes should go to 9-dev first (which may be done with either a pre-commit or post-commit review) and then backported to 8u-dev for 8u60 with a pre-commit review. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-May/017296.html [2] https://wiki.openjdk.java.net/display/OpenJFX/8u60
Re: Font rendering hints - RT-36146 - progress?
The thing is that the way DirectWrite is utilised now by JavaFX either through which hints are applied by default or by some other way, the result is text which does not render exactly the same way as (almost) every native Windows application that also utilises DirectWrite. Wouldn't a simpler solution (or at least a first step) be just to tweak the hints and options until JavaFX font rendering on Windows matches the way native apps do it? I believe at the moment all the default options are selected so perhaps experimenting with some of the non-default options or examining actual code of some native apps to see which options/hints they are setting would arrive at a best match configuration that could replace the all defaults configuration we have now? Then, later down the track, these hints/options could potentially be made user-configurable. On 16 June 2015 at 06:05, Phil Race philip.r...@oracle.com wrote: I would have to look at it starting more or less from scratch and I do not know that it would be as simple as providing a way to tweak DirectWrite rendering. The differences seem to be quite small differences in sub-pixel intensity and sub-pixel accumulation of the total advance. I do not know what API or client produced the 'native' rendering. And what if someone else wants something different again ? So I am not sure when we will get to looking into this and deciding if it makes sense. -phil. On 06/14/2015 02:31 PM, Felix Bembrick wrote: Has anyone had a look at this, done some work on it or can provide some details as to its progress? Thanks, Felix On 11 June 2015 at 13:50, Felix Bembrick felix.bembr...@gmail.com wrote: I am following this one closely and hoping that some progress has been made and that a fix is planned but it's difficult to determine from the JIRA issue. Does anyone have any additional info on where this issue is at? Thanks, Felix
