EventFilter efficiency
I need to react upon two distinct EventTypes. There are two possibilities: Adding two distinct event filters, each for its own event type, or add one event filter for a family of event types, using a switch statement in "application space" to filter for the right event. Certainly for an application programmer it might be more nice to have one distinct filter per event type, but I could imagine that having one common filter might reduce the overhead for JavaFX's event management? -Markus
review: 8145857: Enable fxml module tests in jake
Kevin, https://bugs.openjdk.java.net/browse/JDK-8145857 http://cr.openjdk.java.net/~ddhill/8145857 One small step closer -- 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: CFV: New OpenJFX Committer: Johan Vos
Vote: YES > On Dec 22, 2015, at 6:10 PM, Jasper Potts wrote: > > Vote: yes > > Sent from my iPhone > >> On Dec 22, 2015, at 5:03 PM, Alexander Kouznetsov >> wrote: >> >> Vote: yes >> >> Best regards, >> Alexander Kouznetsov >> (408) 276-0387 >> >>> On 21 дек 2015 11:45, David Hill wrote: >>> >>> I hereby nominate Johan Vos to OpenJFX Committer. >>> >>> Johan Vos (jvos) has been active in the OpenJFX community, and instrumental >>> in the maturity of Monocle, the owner of the Android and IOS ports and is >>> an OpenJFX Author. >>> >>> A list of Johan's commits is also available by the following links >>> >>> http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=jvos >>> http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=johanvos >>> >>> Votes are due by January 5th, 2016. >>> >>> Only current OpenJFX Committers [1] are eligible to vote on this >>> nomination. Votes must be cast in the open by replying to this mailing list. >>> >>> For Lazy Consensus voting instructions, see [2]. Nomination to a project >>> Committer is described in [3]. >>> >>> [1] http://openjdk.java.net/census#openjfx >>> >>> [2] http://openjdk.java.net/bylaws#lazy-consensus >>> >>> [3] http://openjdk.java.net/projects#project-committer >>> >>> Thanks, >>> >>> Dave >>
Re: Update on FX plans for JDK 9
Thanks to everyone who has commented on this. With the winter holidays upon us, we will respond to feedback and pick this up next year. -- Kevin Kevin Rushforth wrote: Given the recently announced JDK 9 schedule slip [1], we have taken the opportunity to explore what RFE's / Features we could possibly now work on for inclusion in JDK 9. We wanted to give you a pre-holiday season update on what we are currently thinking. The following RFEs are in progress or planned for JDK 9: JDK-8144585: Encapsulate JavaFX impl_* implementation methods JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs JDK-8091308: Define fine-grained permissions for JavaFX Expose Hi-DPI properties for render scale and screen scale (FX equivalent task for JEP 263 JDK-8055212) Multi-resolution image support (FX equivalent task for JEP 251 JDK-8046010) Additionally, we have started to look into making public API for some of the impl_* API that will otherwise be hidden by JDK-8144585. See Jonathan's earlier e-mail on the subject [2]. Here is what we have so far: JDK-8144628: Provide API to expose list of showing Windows JDK-8144625: Expose code and char properties on KeyCode JDK-8144962: Promote TableColumn reorderable property to public API JDK-8144871: Add default method getStyleableNode to Styleable interface JDK-8145143: Promote Image.impl_getUrl() to public API as Image.getUrl() JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and Labeled If there are any we have missed that your application depends on, please send e-mail to Jonathan. Finally, here is an updated list of other RFEs we might consider for JDK 9. We will not be able to do all of these, but hope to be able to do many of them. We could use the help of the OpenJFX community in prioritizing this list or possibly adding something that we missed, as long as the scope is small enough. 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) JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux JDK-8092040: Implement Image writers for JavaFX JDK-8091673: Runtime should have a published focus traversal API for use in custom controls JDK-8089311: [TableCell] commit on focus lost not possible in every case JDK-8090477: Customizable visibility timing for Tooltip JDK-8092098: [TabPane] Support for draggable tabs JDK-8144556: Add support to allow user specified rendering order JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer for non-applet Stage JDK-8145154: Provide public API support for PerformanceTracker functionality JDK-8090763: Public API for Glass's robot functionality Let us know what is most important to your application. We will keep you posted with updates on what exactly is being targeted (note that you can track it by looking at the Fix Version in JBS, which we strive to keep up-to-date). Thanks! -- Kevin [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003237.html [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018338.html
Re: [8u/9] review request for 8139210: JavaFX rendering glitch when rendering many Paths using HW pipeline
Bumping this review request since it was shelved for a few weeks while I was working on other issues. The latest webrev (for 9 only for now) is now at: http://cr.openjdk.java.net/~flar/JDK-8139210/webrev.fx9.02/ This should address all of the concerns raised in the reviews in the bug report... ...jim On 11/7/15 3:57 PM, Jim Graham wrote: I've created 2 versions of the fix for this bug. One is low source impact but maintains the current convoluted role of the VertexBuffer class in the code base and makes it slightly more murky. The second fix touches a bunch of files, but it cleans up the use of the VB class throughout the code base. JBS: https://bugs.openjdk.java.net/browse/JDK-8139210 webrev for simple fix (8u & 9): http://cr.openjdk.java.net/~flar/JDK-8139210/webrev.00/ webrev for bigger fix (8u): http://cr.openjdk.java.net/~flar/JDK-8139210/webrev.alt8u.00/ webrev for bigger fix (9): http://cr.openjdk.java.net/~flar/JDK-8139210/webrev.alt9.00/ (the 2 webrevs differ *only* in the location of the TestGraphics.java file) We should consider this for both 8u and 9. I recommend going with the more complete fix for 9, but which is more appropriate for 8u? ...jim
