[9] review request: 8145682 topDocument() returns an incorrect reference for cached Documents

[Murali Billa]

 

Hi Kevin, Alexander,

 

Please review the fix for  below :

JIRA: https://bugs.openjdk.java.net/browse/JDK-8145682

 

Webrev:  http://cr.openjdk.java.net/~ghb/murali/8145682/webrev.00/

 

Root Cause: There is a regression with r162947 which changed the way the top 
document is determined, effecting below 2 cases: 
1) when the Document is in page cache
2) Document is in the middle of having its render tree destroyed OR 
notification posting for cached or being-destroyed documents., leading to 
non-deletion of the proper top document's AXObjectCache
 
Fix: Applying pre- r162947 way of determining the top document and r164718 
patch applied. Also tested to make sure that 
fast/history/timed-refresh-in-cached-frame.html is also passed.

 

 

Thanks,

Murali

 

 

In(Sanity) Testing Mondays

[Vadim Pakhnushev]

Reminder, Monday 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 PST until 1pm 
PST.


Happy testing!

Thanks,
Vadim

HEADS-UP: Bumping minimum OS X version to build FX 9 to OS X 10.9

[Kevin Rushforth]

We currently build FX 9 on Mac OS X 10.9.5 and run on 10.9.5 or later. 
As part of an ongoing effort to cleanup old, unused code that is only 
there to support older OS versions, we filed the following two issues:


https://bugs.openjdk.java.net/browse/JDK-8145602
https://bugs.openjdk.java.net/browse/JDK-8145604

The impact of this cleanup is that FX 9 will no longer build with OS X 
10.8 or earlier. You will need at least OS X 10.9.5 and XCode 5.1.1 in 
order to build FX 9.


Note that the minimum version of Mac OS X that will be supported in JDK 
9 is 10.10, although we intend to keep FX buildable and runnable on OS X 
10.9.5 for the foreseeable future.


-- Kevin

Re: Update on FX plans for JDK 9

[David Hill]

On 12/17/15, 1:10 PM, Tom Schindl wrote:

[...]


   JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux

This is a real problem for the SWT-FX integration because SWT is more
and more setting GTK3 as the default. We (the OSGi-FXClassloader)
currently saves people from hard core-dumps by refusing to load FXCanvas
but they'll get a CNF instead with a decent error message why we refused
to load that classes.


Sounds like I have someone to help test my code. :-)
Not quite there yet.


Naturally this requires FXCanvas to work in FX9 but that is a different
topic ;-)

Tom




--
David Hill
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
world."
-- George Santayana (1863 - 1952)

review Remove deprecated GTK2 calls in JavaFX

[David Hill]

Kevin,

A small change, substituting the "approved" way of calling GTK. This helps in a 
small way moving to GTK3 support.

bug: https://bugs.openjdk.java.net/browse/JDK-8145837
webrev: http://cr.openjdk.java.net/~ddhill/8145837/

--
David Hill
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
world."
-- George Santayana (1863 - 1952)

Re: MediaView does not play video on Ubuntu

[Casall, Alexander]

Hi Jens,

Thanks for the hint. We already had the codecs installed.

We figured out that there seems to be a bug in the media implementation of 
Windows and Linux. Our video was vertical and had a resolution of 800x1500. It 
played perfectly on MacOS. On Windows the MediaView startet with an unknown 
error and on Ubuntu it didn’t do anything, neither putting something in the 
errorProperty nor having any warning. So the solution was to render the video 
in 1500x800 and rotate it in FX.

Thanks for your response,

Alex






Am [DATE] schrieb "openjfx-dev im Auftrag von Jens Kapitza" <[ADDRESS]>:

>Hi,
>
>are the -extra codecs installed?
>
>http://askubuntu.com/questions/214421/how-to-install-the-mpeg-4-aac-dec
>oder-and-the-h-264-decoder
>
>
>Für Ubuntu 15.10 könnte das hier helfen?!:
>
>sudo apt-get install libavcodec-extra  libavcodec-ffmpeg-extra56  
>libav-tools ffmpeg
>
>
>
>
>Am Donnerstag, den 17.12.2015, 11:02 + schrieb Casall, Alexander:
>> Hi,
>
>> 
>> I’m trying to get the MediaView running on an Ubuntu 14.04
>> 
>> Target JRE: 1.8.0_66-b17
>> I’m building the app on Mac with: jdk1.8.0_40.jdk
>> 
>> The Video is h264 encoded and is running perfectly on the MacOS.
>> 
>> When I launch it on Ubuntu the MediaView just shows a blank screen,
>> no exceptions, nothing.
>> 
>> Any suggestions?
>> 
>> Cheers Alex
>> 
>> 

Re: Update on FX plans for JDK 9

[Michael Ennen]

Exposing platform APIs for the major supported platforms (Windows, OS X,
sensible Linux distros) for registering
URL handlers gets a big +1 from me.

While feasibly outside of the scope of OpenJFX, an auto updater would be
amazing. I know you,
Mike, have done work in this area with UpdateFX which could serve a
starting point for the JavaFX
devs if they agree to tackle this issue.

On Thu, Dec 17, 2015 at 3:05 PM, Mike Hearn  wrote:

> >
> >   JDK-8091107: Add java.awt.Desktop support to javafx
> >   JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX
> (FX
> > equivalent for JEP 272)
> >
>
> Exposing platform APIs is a big deal for anyone who wants to make an app
> that really benefits from being on the desktop. Doing things like handling
> files, registering URL handlers etc was a big PITA in my app. Definitely +1
> to supporting these cases better.
>
>
> >   JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer
> > for non-applet Stage
> >
>
> It's unclear from this description or the bug what the benefit of doing
> that would be. Performance?
>
>
> >   JDK-8145154: Provide public API support for PerformanceTracker
> > functionality
> >   JDK-8090763: Public API for Glass's robot functionality
> >
>
> For testing and so on, public APIs seem lower priority to me. A developer
> can always override Jigsaw from the command line and use whatever internal
> APIs are needed. Breakage is less of a concern because it's under the
> control of the developer.
>
> The biggest lack in the JavaFX/javapackager/jlink story is still, by far, a
> slick auto update system. Shipping apps that can't update themselves in
> 2015 is unacceptable even for corporate deployments.
>



-- 
Michael Ennen

Re: Update on FX plans for JDK 9

[Michael Ennen]

Exposing platform APIs for the major supported platforms (Windows, OS X,
sensible Linux distros) for registering
URL handlers gets a big +1 from me.

While feasibly outside of the scope of OpenJFX, an auto updater would be
amazing. I know you,
Mike, have done work in this area with UpdateFX which could serve a
starting point for the JavaFX
devs if they agree to tackle this issue.

On Thu, Dec 17, 2015 at 3:05 PM, Mike Hearn  wrote:

> >
> >   JDK-8091107: Add java.awt.Desktop support to javafx
> >   JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX
> (FX
> > equivalent for JEP 272)
> >
>
> Exposing platform APIs is a big deal for anyone who wants to make an app
> that really benefits from being on the desktop. Doing things like handling
> files, registering URL handlers etc was a big PITA in my app. Definitely +1
> to supporting these cases better.
>
>
> >   JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer
> > for non-applet Stage
> >
>
> It's unclear from this description or the bug what the benefit of doing
> that would be. Performance?
>
>
> >   JDK-8145154: Provide public API support for PerformanceTracker
> > functionality
> >   JDK-8090763: Public API for Glass's robot functionality
> >
>
> For testing and so on, public APIs seem lower priority to me. A developer
> can always override Jigsaw from the command line and use whatever internal
> APIs are needed. Breakage is less of a concern because it's under the
> control of the developer.
>
> The biggest lack in the JavaFX/javapackager/jlink story is still, by far, a
> slick auto update system. Shipping apps that can't update themselves in
> 2015 is unacceptable even for corporate deployments.
>



-- 
Michael Ennen