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

[Richard Bair]

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
 on a coding problem I have with JavaFX Service / Task, which might or
>> might
 not involve inputStreams. I share it here:
 
>> https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered
> --
> Cl?ment Levallois
> Associate Professor
> emlyon business school
> Twitter and Skype: @seinecle
> mobile: +33(0)6 59 08 33 92
> 
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>> 
> 
> 
> -- 
> Pedro Duque Vieira - https://www.pixelduke.com

Re: Scene graph performance

[Richard Bair]

Hi Steve,

It could be a benchmark problem, although I wouldn’t be surprised at all if the 
benchmark was exercising the platform in some way that was CPU limited. 
Assuming it is CPU limited (and not going multi-core), I think the problem 
really comes down to what Markus said:

> The limiting factor is the single-thread architecture of rather all parts of 
> JavaFX. The only real difference you see between machines is not correlating 
> with neither number of CPU cores nor GPU cores, but only with CPU frequency, 
> roughly spoken. Short term fixes will only provide little improvement, by 
> optimizing the critical execution path (i. e. produce hot spot histogram 
> using a profiler), for example improvement clipping, caching, etc. Huge 
> performance optimizations need an architectural change within JavaFX's 
> "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel 
> execution in lots of places. Typical design patterns would be parallel 
> iterations, work-stealing executors, fibers (a.k.a cooperative 
> multi-threading, a.k.a CompletableFuture), and last but not least partitioned 
> rendering (a.k.a tiled rendering).
> 
> I am pretty sure you can add a lot more ideas to the list and produce great 
> performance, scaling linearly with number of CPU cores / GPU cores, but this 
> somes at a cost: Risk to introduce hard to track bugs, and needed manpower.
> 
> If somebody has at least a lot of free spare time, I am pretty sure Kevin 
> could easily provide a huge set of work items in this area. :-)


JavaFX was setup to be multi-threaded — in fact there are always at least 2 
threads — the application / scene graph thread and the render thread. Going 
way, way back the goal was for multi-core computation/rasterizing on the NG 
side (Prism), but it didn’t get done for a variety of reasons. I couldn’t even 
say what kind of performance win/loss it would bring. I’m sure for some 
workloads it would be way better,but for many others it probably wouldn’t make 
any difference. A lot of other more pressing features had to be implemented 
first which would allow people to build apps at all on top of FX (like controls 
and effects and animations and so forth), and Prism has served us really well.

There are a few places we could play with fork/join to see if we can get 
performance boosts, all of which would be tricky and have to be done very 
carefully because they are part of highly tuned code paths:
Computing and applying CSS styles
Computing bounds
Computing layout
Syncing state between scene graph and the render graph
Updating state on the render graph (not sure much time is spent here…)
Rasterizing (fonts, anti-aliased glyphs, etc)

Some of these might be easier to try out than others. For example, using 
multiple threads at sync time should be safe, but probably won’t see much of 
any gain (as it takes a couple MS maximum to do this sync anyway). The more 
difficult one is probably making the rasterizing steps multi-threaded, but that 
would probably bring the biggest win. Computing bounds and layout and CSS in 
parallel would be very tricky, but if it could be done, would likely result in 
a nice speed boost for very large scenes (it would have no impact on rendering 
performance).

Cheers!
Richard

Re: Scene graph performance

[Richard Bair]

Hi Herve,

Thanks for chiming in. I agree.  From my own experience and benchmarking with 
other app-dev GUI toolkits, JavaFX performs very well for a very wide range of 
use cases. That being said, performance was always a passion of mine and I know 
there is more to be had. I like Kevin’s idea of updating to newer graphics 
pipelines too. Our first goal was to get broad coverage, so OpenGL ES 2 and DX 
9 were the hot ticket. But getting onto the newer pipelines opens up a lot of 
additional possibilities.

Richard

> On Jul 21, 2016, at 2:33 PM, Hervé Girod  wrote:
> 
> I really don't understand all this. We use Java FX 8 in a graphic framework 
> where we need high performance (prototyping Cockpit Display Systems with 
> dynamic Maps and Head Up Displays), and we find that JavaFX performance is 
> pretty good our use case. For example, Qt / QML performance is far worse in 
> our POV, for no real additional simplicity of usage for big projects. We also 
> used OpenGL before (used JOGL), but (at least for our own usage) what 
> additional performance benefits we could maybe achieve were not worth the 
> amount of work we would have needed to get them (if we had any). 
> 
> Hervé
> 
> Sent from my iPad
> 
>> On 21 juil. 2016, at 23:09, Felix Bembrick  wrote:
>> 
>> Yes, well I think this the problem:
>> 
>> 1) Going on history, it would be a best case scenario for Java 10 to be 
>> released in 2020 (but more likely 2021).
>> 
>> 2) With JavaFX, we are already "behind the game" (pun intended).
>> 
>> 3) JavaFX itself has evolved much slower than its competitors.
>> 
>> 4) Technology in general will have moved ahead by massive leaps by 2021 
>> (including our competitors).
>> 
>> 5) If the *first* optimised JavaFX scene graph is not released until 2021, I 
>> genuinely fear that not only would "the ship have sailed" but, it would 
>> actually be way over the horizon and completely out of sight.
>> 
>> Felix
>> 
>>> On 22 Jul 2016, at 06:51, dalibor topic  wrote:
>>> 
>>> There is no JDK 10 Project in OpenJDK yet, so there has been no proposed 
>>> schedule for it yet.
>>> 
>>> cheers,
>>> dalibor topic
>>> 
 On 21.07.2016 20:51, Felix Bembrick wrote:
 What is a "ball park" figure (i.e. around the 6-9 month granularity if 
 possible) for the the release date for JDK 10?
 
> On 22 Jul 2016, at 04:42, Kevin Rushforth  
> wrote:
> 
> Oh, I was agreeing with the analysis of what *would* need to be done. I 
> am not saying that I think it *should* be done, given resources other 
> priorities, etc. Having said that, as I mentioned in an earlier post a 
> month or so ago, we will be collecting ideas for possible JDK 10 features 
> once JDK 9 is finished. Perhaps this could go into the bucket of things 
> to consider, but it isn't something I would think would be high on the 
> listcompared to, say, WebGL, some sort of interop with native 
> rendering, updated graphics pipelines (we're current stuck on DX 9 and GL 
> 2), public API for UI Controls Behaviors, etc.
> 
> -- Kevin
> 
> 
> Felix Bembrick wrote:
>> Well, I'm putting my hand up for this.
>> 
>> Kevin, would you like to discuss this with me on or offline?
>> 
>> Felix
>> 
>> P.S. Thanks Markus for your insight!
>> 
>> 
>>> On 22 Jul 2016, at 04:22, Kevin Rushforth  
>>> wrote:
>>> 
>>> Yep.

Re: Scene graph performance

[Richard Bair]

Have you guys profiled the application to see where the CPU time is spent? How 
many nodes in the app?

In the past the majority of CPU time has been spent in one or more of the 
following (not sure if it still applies):
  - Computing changed bounds (a lot of work was done to speed this up, but I 
think it was always a single thread doing the work)
  - Synchronizing state to the render graph (a lot of work was done here too, 
so I wouldn’t expect this to be the problem area)
  - Walking the render graph to render shapes
  - Rasterization (A lot of optimization went here too, but it is still 
essentially a CPU bound operation)
  - Reading results back from the card (this is sometimes the culprit when it 
is slow on old hardware and fast on new hardware)

These are all CPU bound tasks.

I think that there are two angles to look at. First, we always wanted to break 
down the render stage into some parallel pipeline. Adobe Flex was good at this, 
where they’d saturate every CPU you had during the CPU intensive rasterization 
phase and scene graph computation phase. Depending on your particular test, 
this might actually be the bottleneck. So the idea here is to optimize the CPU 
tasks, which will (hopefully) remove CPU from the bottleneck and allow the GPU 
to take on more of the burden. You should also do some research or experiments 
with regards to battery life to make sure using more cores doesn’t make things 
worse (and if it does, to then have a flag to indicate the amount of 
parallelism). You also have to be careful because IIRC (and I may not!) if a 
lot of CPU activity happens on some laptops they’ll kick into a “high 
performance” mode, which is sometimes what you want, and sometimes not. Games 
are happy to kick you into that mode (and drain your battery faster as a 
result) whereas business apps rarely want to do that.

Another angle to look at is more of a research direction in the graphics 
rendering. We spent quite a lot of time looking into ways to go “shader all the 
way” and avoid having to use a software rasterizer at all. The state of the art 
as likely advanced from the last time I looked at it, but at the time there 
really wasn’t anything that we could find that was really ready for production 
in terms of producing 2D screens using 3D that really gave you the polish of 
2D. Also, the scene graph semantics are fundamentally painter’s algorithm, 
since this is what everybody is used to when coming from a 2D background. But 
that’s not the way it works in 3D. In 3D you feed a bunch of meshes to the 
video card and it determines which pixels to render and which are occluded and 
don’t need to be rendered. But when you have multiple geometries at the same 
z-depth, then the card can have “z-fighting” where it renders the pixels from 
some items below you and some above. There are techniques to try to overcome 
this, but at least the last time we looked at it (according to my increasingly 
dimming memory!) there wasn’t a really brilliant solution to the problem. 
Anti-aliasing and transparency were big problems too.

 DETOUR

Normal things that you would have in 2D like shadows, text, even rounded 
rectangles have historically been produced using various 2D algorithms and 
blend modes and so forth. Most people don’t even realize the degree to which 
their view of what a real 2D screen looks like has been tainted by the 
techniques that were available for producing those screens. Many (most? all? at 
least it was at the time) game developers recognized this and used 2D toolkits 
with CPU rasterization to produce their 2D screens and then overlaid this on 3D 
content. The normal way to do this is to render the 2D images in photoshop or 
something and then slice it up and load the pngs into the graphics card on app 
startup and then scale those to produce the images. This is fine, but in a 
general purpose toolkit like FX you can’t just do that, because we allow 
programmatic access to the scene graph and people can modify the “images” in 
real time. So we draw them and cache them and reuse the cached images whenever 
possible etc. A lot was done in order to try to optimize this part of the 
problem.

When I was benchmarking this stuff, we blew away pretty much everybody who was 
in the 2D+3D general purpose graphics toolkit world. We never tried to compete 
with the game vendors (like Unity). We weren’t trying to be a pure 3D scene 
graph. There was a huge discussion about this early on in FX, as to how to 
marry the 2D and 3D worlds. Developers in these different lands come at the 
problem differently, in terms of how they understand their world (y-up or 
y-down? 0,0 in the middle? Every scene scaled? Or 0,0 in top left and pixel 
scaled by default? Anti-aliasing?). We decided it was for 2D developers who 
wanted advanced graphics and animations, and a better toolkit for building apps 
(not games). We figured that for people who wanted to program games, we were 
never going to be really 

OpenJFX Project Lead Resignation

[Richard Bair]

Hi,

As you know, I’ve been on the periphery of this project for the last several 
years, my full time employment taking me into a different path from client 
toolkits. The time has come to pass the torch, and part of that is to send my 
official resignation so that another may take it up. Truly, the time I spent 
working on JavaFX was the best so far of my career, and extremely fulfilling. 
It has been, and continues to be, a true pleasure to see your support and 
enthusiasm for this project.

I do hereby officially resign as lead of OpenJFX.

Yours,
Richard

Re: Handling Enter key presses on Buttons in JavaFX

[Richard Bair]

>>> 2) Do we want to have different behaviors for OS X and non-OS X? I'm a
>>> newly inducted member into the cult of Mac, and I don't yet have all
>>> my bearings sorted out, so I don't have a strong opinion here.
>> Please don't make different OSes behave differently as this is a real pain. 
>> I would much prefer, if JavaFX-Applications behave the same on all platforms.
> 
> That ship has already sailed. I think it it's the right thing to do. Mac 
> users want a screen menu bar and they want the okay and cancel buttons to be 
> in the correct place in dialogs.
> Respect the conventions and UI guidelines of the platform.

Agreed. Our philosophy was always to have a platform “feel” but cross platform 
“look”. This is vitally important, because people on a particular platform are 
used to certain behaviors, and if an app behaves completely differently it will 
be considered broken and (in cases like the one Jonathan mentions regarding 
“enter” on dialogs) can have adverse business effects on people. Drawing a 
button with a different shadow is one thing (and branding it that way across 
all platforms), but having different keystrokes is bad.

The right thing to do (IMO) is to carefully document the native platform’s 
behavior and match it when running on that platform. It is difficult and 
time-consuming, but necessary for end users to be satisfied with the result. 
The more FX can shoulder the burden of having platform-specific feel so that 
developers are free to focus on their app and not this level of detail, the 
better.

Richard

Re: CFV: New OpenJFX Committer: Johan Vos

[Richard Bair]

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: TableCell.getTableRow() return value

[Richard Bair]

You should be able to add generics compatibly, you just can't change the 
generics signature. One shot to get it right IIRC.

> On Nov 25, 2015, at 8:57 AM, Jonathan Giles  wrote:
> 
> It was an oversight at the time, and (from memory) is now a breaking change 
> to fix it, so for now it remains as it is, sadly.
> 
> -- Jonathan
> Sent from a touch device. Please excuse my brevity.
> 
>> On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker 
>>  wrote:
>> Seems like getTableRow() should return TableRow instead of just
>> TableRow.  That way I wouldn’t have to cast getItem().
>> 
>>
>> https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html
>> 
>> 
>> 
>> 
>> 
>>   @Override
>>   public void updateItem(Boolean isEnabled, boolean empty) {
>> ...
>>   TestCase testCase = (TestCase)getTableRow().getItem();
>> 
>> This would be nicer:
>> 
>>   TestCase testCase = getTableRow().getItem();
>> 
>> Seems like an easy change to the getTableRow() method:
>> 
>> public class TableCell extends IndexedCell {
>> ...
>>   public final TableRow getTableRow() { return tableRow.get(); }
>> 
>> 
>> Was this an oversight, or is there a reason that getTableRow() needs to
>> return TableRow instead of TableRow?
>> 
>> Thanks for any help.
>> 
>> -Larry

Re: pisces, produceFillAlphas

[Richard Bair]

Is it consistent among all android devices, or is it a specific device?

> On Oct 15, 2015, at 12:30 PM, Johan Vos  wrote:
> 
> Thanks Jim.
> I tried with different optimization flags, but it doesn't make a big
> difference. Tracing it down to system calls, somehow the gl implementation
> seems be be slower (glDrawElements(GL_TRIANGLES, numQuads * 2 * 3,
> GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) per
> invocation. The number of invocations is comparable between iOS and Android.
> 
> If you can give me a direction on where to search for the disabled
> scrolling optimization, I'll try to re-enable that and see how it improves
> performance. It might be a huge and quick win...
> 
> Thanks again,
> 
> - Johan
> 
> On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham  wrote:
> 
>> Perhaps optimization flags with the native compiler?  Also, was it called
>> a similar number of times on both?
>> 
>> Ideally we'd just be using copyArea for the scrolling, but at one point we
>> disabled the scrolling optimizations on retina MBP because they didn't work
>> with a scale factor and I don't think we reenabled them yet.  That would
>> kill scrolling performance on mobile as a result of having to rerender the
>> scene on each scroll regardless of how long produceAlphas takes...
>> 
>>...jim
>> 
>> 
>> On 10/15/15 4:27 AM, Johan Vos wrote:
>> 
>>> After spending lots of time optimizing JavaFX on iOS, I am now at the
>>> point
>>> where scrolling is 10 times faster on iOS than on Android.
>>> The scrolling in the iOS version of the Gluon JavaOne mobile schedule
>>> builder is pretty good imho. On Android, it is much slower. I profiled and
>>> compared both, and it turns out that on Android, we spend lots of time in
>>> the native implementation of NativePiscesRasterizer.produceFillAlphas
>>> (implemented in native-prism/NativePiscesRasterizer.c)
>>> 
>>> On average, calling this native function on an iPhone 6 takes 40,000ns
>>> whereas on a Nexus 6, this takes about 800,000ns.
>>> 
>>> If anyone has a suggestion on how to improve or avoid this, I'm all ears.
>>> 
>>> Thanks,
>>> 
>>> - Johan
>>> 
>>> 

Re: Java & JavaFX on mobiles

[Richard Bair]

Donald, do you know if the iOS version has the JIT compiler? I know Apple 
reduced the restriction for some cases, but I can’t remember if it applied to 
us or not. Or is the VM on iOS interpreter only?

Richard

> On Oct 7, 2015, at 2:21 PM, Donald Smith  wrote:
> 
> There is no "official  JDKs for iOS and Android", and anyone that tries to 
> spin the recent OpenJDK project announcement as such is likely just trying to 
> consume you as click-bait.  The recent project announcement is simply to make 
> internal code we have for some of our other commercial products available to 
> those who may wish to use it (and therefore we hopefully benefit from any 
> contributions back). That's it.  It won't be released as part of the Oracle 
> JDK.  It's just some source, for OpenJDK.
> 
> - Don
> 
> On 07/10/2015 5:11 PM, Felix Bembrick wrote:
>> The world of Java and JavaFX is growing more confusing than ever it seems.
>> 
>> Some say Oracle is cutting back on funding for Java because it is 
>> effectively helping its competitors. Sounds similar to Google forking WebKit 
>> so they weren't writing code for Apple.
>> 
>> But now we hear of the looming release of official JDKs for iOS and Android 
>> from Oracle.
>> 
>> Will these JDKs be the best and simplest way of running JavaFX on those 
>> platforms? Without JIT support, will these JDKs support AOT compiling?
>> 
>> Do the proposed JDKs for mobiles even include JavaFX?
>> 
>> Felix
> 

Re: JavaFX JIRA issues moving to JBS

[Richard Bair]

Hi everybody,

Moving to JBS is both good and bad. The good:
Reduce costs associated with the project
Reduce internal overhead for development processes (everybody on Java uses JBS 
for everything so having a second JIRA makes everything harder with release 
management, management, even engineers who have to switch from one to the other)
JBS has dedicated engineering for support and maintenance, upgrades, etc
Making OpenJFX more of a core component of OpenJDK
Issues can be indexed on Google etc. (no account required to view issues)

The bad:
Contributing is hard (nay, impossible?) if you are not at least an OpenJDK 
Author

This last bullet is a huge problem IMO and the reason why we didn’t roll out a 
migration to JBS 1-2 years ago. But that is an OpenJDK policy issue, and all we 
can do is raise the issue and voice support for a more lenient policy. I 
actually don’t know if bugs.java.com http://bugs.java.com/ allows you to 
comment on your own bug, but I don’t think it does. What happens if you file a 
bug and the dev cannot reproduce? Or they need more info? How do you add more 
info? I’m not even sure this is possible without emailing the engineer directly.

 From what I see, JBS still doesn't support self-creation of accounts.

This is correct. The only way for people to file issues freely is through 
bugs.java.com

 perhaps I can ask for one and perhaps Oracle would grant one (to be verified).

I am certain you could get one, you’ve been an active member of the community 
for a long time.

 But I don't think this would apply for a common employee of a corporate that, 
 among other things, also develops in Java; not mentioning that not having the 
 possibility of instantly signing in is not good, and would discourage almost 
 everybody I know. The bridge offered by bugs.sun.com is cumbersome too. In 
 any case, this is completely different from any other FLOSS project around, 
 where access to the issue tracker is immediate and easy.

I agree.

 I understand that, being Java so popular, Oracle might fear some kind of 
 massive, low-level posting of issues, that would be expensive to manage. If 
 this is the case, let's discuss it.

This is exactly the issue. We know from the last 20 years that in fact we get a 
huge amount of completely bogus bugs that get filed via bugs.java.com 
http://bugs.java.com/ (previously bugs.sun.com http://bugs.sun.com/). Wild 
stuff from end users like “I can’t reboot my computer” and so forth. The 
concern with JBS (as I understand it) was that we’d end up with 10’s or 
100,000’s of thousands of user accounts, many of which would be one-shot 
submitters associated with bogus issues.

One solution would be if Atlasssian had some kind of “guest” mode where 
submitter accounts could be created but they would not show up in lists for 
things like assignees etc so they don’t clutter other views. Another solution 
could be to have a system whereby anybody who submits a good issue through 
bugs.java.com http://bugs.java.com/ would get an email allowing them to sign 
up on JBS if they had an issue.

Or, maybe the concern is actually not a problem — since Applets etc would point 
towards bugs.java.com http://bugs.java.com/, the only people (hopefully) 
coming to JBS are serious developers, the doors could be opened.

Dalibor would probably know the right alias to discuss the JBS policy, and I do 
believe, personally, that the policy is too restrictive and discourages 
cooperation and needs to be changed. But I also think moving to JBS is a good 
thing for a bunch of other reasons (and cost cutting can’t be ignored) and 
actually I’m looking forward to the ability to browse issues without having to 
get an account (not like I don’t have an account, but I mean for all the folks 
out there who just want to see the issues :-)).

Cheers
Richard

Re: JavaFX JIRA issues moving to JBS

[Richard Bair]

 Why can't an effort be made to influence JBS policies before making the 
 switch?

I think the way to do this is to engage the JBS folks on their alias, I don’t 
think they watch this one and Kevin doesn’t have the ability to change this 
policy. He’s just the messenger!

Richard

Re: The trouble with Skins

[Richard Bair]

tl;dr; I lean toward keeping the Control API as view-agnostic as possible, but 
where view details become essential to the operation of the control, then 
define the Control to always include those specific view details.



Very interesting discussion, I’m enjoying reading through it. The following is 
a bit of background as to where my head was when we were designing this.

In Swing we had a similar concept to the Skins, they were the various UI 
delegates. In theory they allowed you to change the look of a Swing component 
(and they did) — but there were all kinds of “view specific” details that 
leaked into it, and also in the Swing components. With JavaFX, I wanted to go 
down more of a purist route, where the Skin would literally do all the UI 
(view)  and the control would be the controller. OK, the Control was a Node 
because it made more sense conceptually to put a Button into a scene graph than 
to create a Button, associate it with a view, put the View into the scene 
graph, and somewhere stash the controller so you could get it back later. And 
for something like a Button, it works well.

Almost as soon as we’d gone down this road we got into the various problems you 
guys have been discussion around scroll bars and view positions. If you’re 
using the standard UI, then you kind of want to have access to these properties 
so you can get the UX right. However if we add these properties to ListView, 
then it would go down the road of saying “ListView displays a list of items and 
has a scroll bar or at least a scroll position and you have convenience API for 
making certain items visible, etc”.

Another very common complaint was about how to go about knowing the size of a 
cell for a specific list view item. You’d really want an API on ListView that 
said “getCell(item)” and then you got the cell, at least assuming it was 
visible, otherwise since it is virtualized it doesn’t make a whole lot of 
sense. But anyway, if you don’t know whether the skin even does virtualization, 
then how can you define these semantics in a way that is broadly consistent and 
usable?

Basically it comes down to having the API on the controller (Control) and 
restricting what kinds of skins can be created per control or having users cast 
the skin to a concrete type and work with the Skin directly for such things. If 
we were a dynamic language we could be dirty and munge the two together into a 
single thing (dynamic properties), but with its own set of trade-offs (you have 
to know what kind of skin you’re dealing with, and if you get it wrong, your 
app breaks).

As time went on we ended up adding more view-specific functionality to the 
controls (even adding view state via the CSS background API etc!!). I don’t 
know what the right answer is for this design question, but where we were 
heading was a place where you would have different UI controls for different 
“classes” of controls. So a ListView with scrollbars is our ListView, and a 
PagingListView or something would probably be different. They could have a 
common base class if we designed it such, otherwise they would just have those 
similarities that are consistent between the two classes of control.

That is why I find this actually quite appropriate:

 So Skins prevent us from getting visual details of the Control (such
 as scroll position, position of item on screen, ...), because it is
 Skin-specific, but at the same time they fail to customize the look 
 feel, because visual presentation leaks into the Control anyway.


This is the design balance! If you get it wrong, you get exactly what you’re 
saying here.

In the end, I lean toward keeping the Control API as view-agnostic as possible, 
but where view details become essential to the operation of the control, then 
define the Control to always include those specific view details.

Re: The trouble with Skins

[Richard Bair]

Sounds like this may be a case of where view details become essential to the 
operation of the control, then define the Control to always include those 
specific view details.”


 On Mar 23, 2015, at 11:45 AM, Robert Krüger krue...@lesspain.de wrote:
 
 
 
 On Mon, Mar 23, 2015 at 7:07 PM, Richard Bair richard.b...@oracle.com 
 mailto:richard.b...@oracle.com wrote:
 tl;dr; I lean toward keeping the Control API as view-agnostic as possible, 
 but where view details become essential to the operation of the control, then 
 define the Control to always include those specific view details.
 
 
 
 Very interesting discussion, I’m enjoying reading through it. The following 
 is a bit of background as to where my head was when we were designing this.
 
 In Swing we had a similar concept to the Skins, they were the various UI 
 delegates. In theory they allowed you to change the look of a Swing component 
 (and they did) — but there were all kinds of “view specific” details that 
 leaked into it, and also in the Swing components. With JavaFX, I wanted to go 
 down more of a purist route, where the Skin would literally do all the UI 
 (view)  and the control would be the controller. OK, the Control was a Node 
 because it made more sense conceptually to put a Button into a scene graph 
 than to create a Button, associate it with a view, put the View into the 
 scene graph, and somewhere stash the controller so you could get it back 
 later. And for something like a Button, it works well.
 
 Almost as soon as we’d gone down this road we got into the various problems 
 you guys have been discussion around scroll bars and view positions. If 
 you’re using the standard UI, then you kind of want to have access to these 
 properties so you can get the UX right. However if we add these properties to 
 ListView, then it would go down the road of saying “ListView displays a list 
 of items and has a scroll bar or at least a scroll position and you have 
 convenience API for making certain items visible, etc”.
 
 Another very common complaint was about how to go about knowing the size of a 
 cell for a specific list view item. You’d really want an API on ListView that 
 said “getCell(item)” and then you got the cell, at least assuming it was 
 visible, otherwise since it is virtualized it doesn’t make a whole lot of 
 sense. But anyway, if you don’t know whether the skin even does 
 virtualization, then how can you define these semantics in a way that is 
 broadly consistent and usable?
 
 Basically it comes down to having the API on the controller (Control) and 
 restricting what kinds of skins can be created per control or having users 
 cast the skin to a concrete type and work with the Skin directly for such 
 things. If we were a dynamic language we could be dirty and munge the two 
 together into a single thing (dynamic properties), but with its own set of 
 trade-offs (you have to know what kind of skin you’re dealing with, and if 
 you get it wrong, your app breaks).
 
 As time went on we ended up adding more view-specific functionality to the 
 controls (even adding view state via the CSS background API etc!!). I don’t 
 know what the right answer is for this design question, but where we were 
 heading was a place where you would have different UI controls for different 
 “classes” of controls. So a ListView with scrollbars is our ListView, and a 
 PagingListView or something would probably be different. They could have a 
 common base class if we designed it such, otherwise they would just have 
 those similarities that are consistent between the two classes of control.
 
 That is why I find this actually quite appropriate:
 
  So Skins prevent us from getting visual details of the Control (such
  as scroll position, position of item on screen, ...), because it is
  Skin-specific, but at the same time they fail to customize the look 
  feel, because visual presentation leaks into the Control anyway.
 
 
 This is the design balance! If you get it wrong, you get exactly what you’re 
 saying here.
 
 In the end, I lean toward keeping the Control API as view-agnostic as 
 possible, but where view details become essential to the operation of the 
 control, then define the Control to always include those specific view 
 details.
 
 
 Not understanding the discussion in-depth, I just hope that solving issues 
 like https://javafx-jira.kenai.com/browse/RT-39917 
 https://javafx-jira.kenai.com/browse/RT-39917 is possible within the 
 current design. If such limitations are something one has to live with, it is 
 not possible to create a UX that can compete with other toolkits including 
 Swing. At the moment this is a brick wall we seem to be hitting porting our 
 product from Swing to JFX.

Re: Build farm for OpenJFX (on ARM)

[Richard Bair]

Cool!

 On Feb 5, 2015, at 2:19 PM, Mani Sarkar sadhak...@gmail.com wrote:
 
 Hi All,
 
 As per Chris's message and the tweet I got last night / this morning I'm
 updating you (which I was intending to do when the time was right), that we
 now have a successful OpenJFX build on Cloudbees, see
 https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/OpenJFX/.
 
 Our build farm is able to build an updated artefact each day. Currently its
 a Linux build, the ARM build is on its way, an issue with a dependency has
 hindered us, but once that is also successful you will be able to download
 both these binaries from the above Cloudbees location.
 
 I'll add to what Chris has mentioned, I was not aware of another initiative
 to build OpenJFX binaries and ours is to not duplicate the effort but make
 such opensource binaries related to OpenJDK available to everyone in the
 community.
 
 We need all the help you can give us. As you can see from the list on the
 cloud farm, something or the other always needs to be attended to.
 
 Thanks.
 
 Cheers,
 Mani
 
 On Thu, Feb 5, 2015 at 8:35 AM, Chris Newland cnewl...@chrisnewland.com
 wrote:
 
 Hi Johan, all,
 
 Following the announcement that JDK builds for ARM will no longer include
 JavaFX I started talking with the OpenJDK Adoption group
 (https://wiki.openjdk.java.net/display/Adoption/Main) about the
 possibility of using their CloudBees CI system to produce OpenJFX binaries
 (for all operating systems including ARM) as a way to help keep JavaFX
 alive on IoT devices.
 
 For those who don't know the Adoption group, its mission is to help
 developers get started with building OpenJDK, testing new features,
 submitting bug reports, and cleaning up code.
 
 Adoption has a CloudBees CI set up and I've been talking with Mani Sarkar
 (@theneomatrix369) about setting up an OpenJFX CI project with
 cross-compile support that builds OpenJFX for all archs.
 
 The cross-compile instructions here
 
 https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float
 are working great for me locally so now we're trying to work out how to
 move that to the cloud.
 
 I don't want to tread on anyone's toes here and we're not trying to become
 any kind of official source for JavaFX, just trying to make sure there's
 an easy way (e.g. binaries) for end users to add JavaFX to their ARM JDKs
 and to help people dip their toes into OpenJFX development as per the
 Adoption group's mission.
 
 Happy to coordinate on how we can make this useful and avoid any
 duplication of effort :)
 
 Personally, I'm a big fan of JavaFX and use it as the UI layer in JITWatch
 (https://github.com/AdoptOpenJDK/jitwatch/). I'm also into IoT and
 wearables and think JavaFX would be great on the new Raspberry Pi 2.
 
 Cheers,
 
 Chris
 @chriswhocodes
 
 
 
 
 
 -- 
 @theNeomatrix369 http://twitter.com/theNeomatrix369*  |  **Blog
 http://neomatrix369.wordpress.com**  |  *LJC Associate  LJC Advocate
 (@adoptopenjdk  @adoptajsr programs)
 *Meet-a-Project - *MutabilityDetector
 https://github.com/MutabilityDetector*  |  **Bitbucket
 https://bitbucket.org/neomatrix369* * |  **Github
 https://github.com/neomatrix369* * |  **LinkedIn
 http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b*
 *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
 
 *Don't chase success, rather aim for Excellence, and success will come
 chasing after you!*

Re: Quick look at JavaFX methods above the HotSpot inlining threshold

[Richard Bair]

Hi Chris,

I’ve not seen any experiments or investigation along these lines, looking 
forward to what you find!

Richard

 On Nov 3, 2014, at 3:42 PM, Chris Newland cnewl...@chrisnewland.com wrote:
 
 Hi all,
 
 As part of the JITWatch[1] project I've written a tool called JarScan
 which counts the bytecode size of methods in a jar and logs those methods
 which are above HotSpot's 325 byte size threshold for inlining methods it
 determines are hot.
 
 In jfxrt.jar from Oracle's JDK 1.8.0_25 on Linux x86_64 there are 774
 methods above the threshold which I've listed in this gist:
 https://gist.github.com/chriswhocodes/c474e49f0d111757dbf2
 
 A lot of these won't be found in hot code but perhaps the methods under
 com.sun.javafx.geom and javafx.scene.transform could be candidates for
 examination with JIT compilation in mind?
 
 Has anybody on the list done any experiments in this area? If not I'll try
 and find some time to see if there are any gains to be made by trimming
 methods (in the OpenJFX source) to fit inside the inlining threshold.
 
 Cheers,
 
 Chris
 @chriswhocodes
 
 [1] https://github.com/AdoptOpenJDK/jitwatch
 

Re: Tagging UI control

[Richard Bair]

I tried writing one once just using a TextField, but it ended up being very 
difficult. With the TextFlow as a basis instead, it might be easier. You can 
also do it out of a composite of controls as you mention here, depending on the 
user experience you are looking for with the control. I would probably look at 
a few JS/HTML implementations and see what they do, we have the same basic 
rules (scene graph) so the concepts should map pretty well across I expect.

On Sep 8, 2014, at 4:15 AM, Mike Hearn m...@plan99.net wrote:

 I've not encountered one, but building such a thing should be quite
 straightforward. You could use CSS to create a text-area like rectangle
 with an HBox inside it, and then have a no-border textedit that simply
 expands to fill the available space. When the user presses enter you create
 an appropriately styled label with the contained text and insert it to the
 left of the edit in the hbox. Tweak CSS and spacing and you have a basic
 tagging control.
 
 On Mon, Sep 8, 2014 at 10:02 AM, Robert Krüger krue...@lesspain.de wrote:
 
 Hi,
 
 how would one go about implementing (i.e. use which api) a tagging
 control (e.g. like http://xoxco.com/projects/code/tagsinput/) in JFX
 or is this already available in an existing extension library?
 
 Is this easily done with a bit of text parsing and CSS magic or as
 fiddely as building a rich text editor or does it even make sense to
 build this by integrating a web component and using an existing
 javascript-based solution (which feels a bit odd)?
 
 Thanks in advance for any opinions/pointers.
 
 Robert
 

Re: Compiling 8u20-b26 for iOS

[Richard Bair]

I’ll let one of the other guys answer about the web component build order, but 
...

On Sep 1, 2014, at 11:58 PM, Niklas Therning nik...@therning.org wrote:

 Also, how is the jfxrt.jar that comes with my Java8 installation treated by
 the build? I guess it is ignored since otherwise I wouldn't get any
 compilation problems due to missing WebView etc since those classes are in
 Java8's jfxrt.jar?

The jfxrt.jar that comes with the JDK is in the lib/ext directory (as is 
Nashorn). We simply omit both from the class path when we build by setting 
java.ext.dirs= (to empty).

Richard

Re: Text rendering on Windows

[Richard Bair]

 I won't be able to get access to a Windows machine for another week or so but 
 when I do I will gladly send you some screenshots.  However, are you saying 
 that this is the first time anyone has reported such a finding? There's no 
 existing JIRA for this specific issue? I ask because even though people tell 
 me I am super fussy with fonts and see things others just can't see, I have 
 observed the stated discrepancy on *every* Windows machine I have tried with 
 JFX 8 (about 4 quite different machines) so I would be very surprised if no 
 one else notices a difference.

It is really common for two font fussy people to disagree on which font 
rendering is “better” :-). We’ve also looked at various applications and it 
seems to be a mixture of different techniques (sometimes even within the same 
app!). For such things, it might be better to expose some kind of settings that 
lets the developer chose which font hinting they want to use or other settings. 
Just something to keep in mind.

The other day I was doing some HTML (blah) and comparing the font rendering 
with another website. My fonts were dark and heavy, their fonts were light and 
stylish. The font was exactly the same. The weight was exactly the same. The 
style, variant, etc were all the same. The difference was 
'-webkit-font-smoothing: antialiased;’. I don’t know if the two of us, given 
the same page and same rendering, would agree on which font looked nicer (maybe 
we would, maybe not, I really don’t know!).

Which makes me think we probably need to expose some toggles so folks can tweak 
the characteristics to their liking.

Richard

Re: JavaFx roadmap?

[Richard Bair]

The work for planning is now done within OpenJDK. You might want to look at 
some of the JEPs defined for FX in upcoming releases (such as 
http://openjdk.java.net/jeps/209, http://openjdk.java.net/jeps/205, 
http://openjdk.java.net/jeps/204, etc).

Thanks
Richard

On Aug 11, 2014, at 2:08 PM, Adam Granger a...@adamish.com wrote:

 The official java fx roadmap on oracle.com seems to have been taken down,
 without replacement.
 
 http://www.oracle.com/technetwork/java/javafx/overview/roadmap-1446331.html
 
 I've had a search in JIRA and there is clearly a lot of work going on.
 
 - What's the long term plan, target release dates, long term support dates?
 We're interested in this at work, but need to know oracle is committed
 to it.
 - What about features like multi-touch on Linux?
 - How will WebView ever keep up with the constantly evolving HTML5 platform?
 - Is Swing development really over?
 
 Regards,
 
 Adam.
 -- 
 Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Calculating the preferred size of a node before layout takes place?

[Richard Bair]

autosize() on Node may be what you want (sizes it then afterward you can read 
values)?

On Aug 4, 2014, at 10:56 AM, Mike Hearn m...@plan99.net wrote:

 I'd like to find the calculated height of a node in my window controllers
 initialise() method, so I can shrink the height to zero and then animate it
 to the right size later. However getHeight and getPrefHeight both return
 zero in this method, presumably because it's not been laid out yet.
 
 I tried calling layout() but that didn't help.
 
 I don't want any visual glitches caused by a node being visible and then
 immediately resized to invisibility. Is there a solution to my problem? I
 feel there must be an obvious one that I'm just overlooking somehow ...
 
 thanks!

Re: ANGLE - Translating OpenGL ES 2 code to DirectX?

[Richard Bair]

 This sounds like there are concrete plans for this, which wood be
 great news.

I’d say there were a lot of thoughts around it but it hasn’t been turned into 
an actionable plan. Heck, I don’t even know if we have a JIRA for it (Kevin 
would know…)

Richard

 The approach where an integration API would only work on
 Windows with GL support would at least in our area not be uncommon.
 There are a number of digital media pro applications that require GL
 to be installed on Windows to work.
 
 Keep up the good work.

Re: ANGLE - Translating OpenGL ES 2 code to DirectX?

[Richard Bair]

I was interested in Angle for exactly this same reason — it would allow us to 
expose OpenGL at the public API level. However there are licensing issues we’d 
have to look at, performance tests to be run, security audits performed, and 
whether or not it is actually able to perform well. 

Although the browsers use it for WebGL, WebGL is not the main thing browsers 
do. What I mean by that, is that if WebGL isn’t working, an HTML author can 
detect that and redirect or provide some kind of error to the user. If GL 
doesn’t work for us, we’d be dead in the water (probably just crash) without 
having some kind of fallback. We could maybe just fallback to software 
rendering (and realize that in such cases the performance will not be good and 
people will be mad). It didn’t look like a slam dunk to me. Rather, it seemed 
to me that we should allow the OpenGL stack to run on Windows with an option, 
let developers opt into it, but note that it isn’t a supported configuration so 
we don’t have support costs associated with it if it doesn’t work. And we’d 
have to forbid it on WebStart / Applets (within reason) so as not to allow bugs 
in the native drivers to be exploitable through us (if the board causes the VM 
to crash, there is potentially some security issues there). And then expose an 
API that works with GL, supported on Mac / Linux, but “known to work” on 
Windows in cases where Windows GL support works. That seemed to me a shorter 
path to victory.

Richard

On Jul 21, 2014, at 1:13 PM, Joseph Andresen joseph.andre...@oracle.com wrote:

 That's a good point Robert,
 
 If the GLContext work that steve and felipe did become an actual thing, this 
 would help that cause become cross platform.
 Angle also is strictly es2, and I haven't looked at prism es2 in a while but 
 I think we use GL2 calls for desktop in some cases. We would have to address 
 those cases (if even possible) before any work started.
 
 -Joe
 
 On 7/21/2014 10:40 AM, Robert Krüger wrote:
 On Mon, Jul 21, 2014 at 7:09 PM, Joseph Andresen
 joseph.andre...@oracle.com wrote:
 I also forgot,
 
 The argument could be made that if we did indeed use angle, we could ditch
 our directx 9 pipeline altogether and just use one hardware pipeline. We
 would really have to evaluate this though, and I am not sure the work would
 be worth the benefit (if there even is any).
 Well, at least the presence of the directx pipeline was used as an
 argument against exposing a GL context via a low-level native api,
 which quite a number of people with particular graphics/performance
 requirements need IIRC, so this would be a potential benefit.
 

Re: Only 1 GUI thread dialogs (was Re: 2 JavaFX applets in the same JVM)

[Richard Bair]

Hmmm… FX Experience is running for me. Is anybody else having this problem?

Richard

On Jul 8, 2014, at 2:51 PM, ngalarn...@abinitio.com wrote:

 Hi Steve,
 
 My understanding of Swing was that when in a modal dialog, which blocked 
 the EDT, a second EDT was fired up for the duration of the dialog to keep 
 the events flowing.
 
 When you say, below, that only 1 GUI thread is supported (and that thread 
 is the native GUI thread), how are (will?) modal dialogs handled?
 
 
 Thanks,
 
 Neil
 
 P.S. I've been trying to read Jonathan's article on dialogs on 
 fxexperience.com, but haven't been able to because I get redirected to 
 hosting.xmission.com
 
 
 
 From:   Stephen F Northover steve.x.northo...@oracle.com
 To: Kevin Rushforth kevin.rushfo...@oracle.com, 
 ngalarn...@abinitio.com, 
 Cc: openjfx-dev@openjdk.java.net
 Date:   07/08/2014 03:41 PM
 Subject:Re: 2 JavaFX applets in the same JVM
 
 
 
 This would imply that there was more than on distinguished GUI thread 
 per process.  JavaFX runs in the native GUI thread by design and more 
 than one GUI thread is not supported in JavaFX and on some platforms 
 (ie. Mac).
 
 Steve
 
 On 2014-07-08, 3:31 PM, Kevin Rushforth wrote:
 
 Is running 2 JavaFX applets in the same JVM supported?
 
 No, this is not supported. RT-29969 (and the non-public RT-32321) is 
 about running multiple applets from the same web page, each in their 
 own JVM. By design, JavaFX runs each applet in its own VM. It is very 
 unlikely that we would ever add the ability to run more than JavaFX 
 applet in the same VM.
 
 -- Kevin
 
 
 ngalarn...@abinitio.com wrote:
 Hello,
 
 What is the status of running 2 JavaFX applets in the same JVM 
 (separate_jvm = false)?
 When we try to load 2 applets into the same JVM we get a runtime 
 error (I think it was class loader related).
 
 When I searched in jira I found RT-29969 (the 2 applet test it refers 
 to may or may not be in the same JVM) which points to RT-32321 which 
 seems to be private (it gives me an error when I try to access it).
 
 Is running 2 JavaFX applets in the same JVM supported?
 
 If not, is that a bug or a feature?
 
 
 Thanks,
 
 Neil
 
 
 
 NOTICE from Ab Initio: This email (including any attachments) may 
 contain information that is subject to confidentiality obligations or 
 is legally privileged, and sender does not waive confidentiality or 
 privilege. If received in error, please notify the sender, delete 
 this email, and make no further use, disclosure, or distribution. 
 
 
 
 
 
 NOTICE from Ab Initio: This email (including any attachments) may contain 
 information that is subject to confidentiality obligations or is legally 
 privileged, and sender does not waive confidentiality or privilege. If 
 received in error, please notify the sender, delete this email, and make 
 no further use, disclosure, or distribution. 

Re: Resizing stage creates delays in platform.runLater pool?

[Richard Bair]

My guess would be that the number of resize events is swamping the event queue.

 On Jun 2, 2014, at 7:20 AM, Guillaume Anctil drakk...@gmail.com wrote:
 
 Hi,
 
 I have encountered severe lag in my application when resizing the stage
 while an animation is running.
 
 I've made this very simple example code to reproduce the issue:
 https://github.com/Drakkoon/LWJGL-FX/blob/master/src/JavaFXResizeTest.java
 
 This is only a tread that acquires a semaphore, prints the
 System.nanotime() delta and releases the semaphore. There's a button on the
 stage that can clicked on to start a fade animation and stop it.
 
 Resizing the stage while it is animating will create huge deltas in the
 thread. Stopping the animation brings everything back to normal. Restarting
 the animation once resized and stopped does not create the huge deltas
 until you resize again.
 
 Does anyone know what is at play here, what underlying system creates the
 lag and how to avoid this?
 
 Thanks.

Re: Extending a Region to create a JUNG Layout

[Richard Bair]

 It would be nice if Oracle or somebody else produced some documentation on 
 this.   You could create a feature request in Jira 
 (https://javafx-jira.kenai.com) for such documentation or email the 
 documentation team (javasedocs...@oracle.com), or write a blog or a openjfx 
 wiki article (https://wiki.openjdk.java.net/display/OpenJFX/Main) if you work 
 out some good techniques.

Thanks John, that is good advice.

 Can someone point me to a detailed explanation of how to extend Region to 
 create my own layout?
 In particular, how can I get a region to relayout it's children when it's 
 being resized?

Some quick pointers. First, layout is done asynchronously to the changes that 
cause the layout to have to occur. This is done so that we limit the number of 
times we layout a container. For example, if a container’s width changes, we 
mark that container (and on up the hierarchy) as needing a new layout, but we 
don’t perform the layout yet. If you were to then change the height for a 
container, we see that it has already been marked dirty and don’t have to go 
any further. Without this, we ended up with “layout storms”.

Layouts happen once “per pulse”. A “pulse” happens once per rendering. So we 
get notification that we need to prepare the scene graph in order to render the 
next frame. So we do CSS, layout, etc and then synchronize those changes down 
to the graphics layer to draw. You don’t have to worry about the pulse. Just 
know that when the width / height / etc of a layout container changes, we mark 
it as dirty, and then perform layout *sometime before the next render happens*.

In order to manually tell a region that it has a dirty layout, call 
requestLayout() on the region.

 When does a the region's parent call layoutChildren()?

During the pulse. You can force a layout (which maybe is what you’re bumping up 
against), but normally if you can, you want to let the “once per pulse” 
mechanism cause layout to occur for you.

During the layout pass, the layoutChildren() method on the region will be 
called. Inside this method you are responsible for taking into account any 
insets on the region (by calling getInsets()).

 If the height and width of the region are set to Double.MAX_VALUE indicating 
 the area can grow infinitely, how does the region know what size to set 
 itself to?

I assume you mean, when the prefWidth and prefHeight? The parent of the region 
will ask the region for its min/pref/max width and height, and will then decide 
what size to give your region. So in other words, the region doesn’t figure out 
its own width/height, it is told its width and height, *prior* to be being 
asked to layout its children.

Richard

Re: Building WebKit natives with debug symbols on 32 bit Linux

[Richard Bair]

 My question to the list is: How do you guys produce 32 bit libjfxwebkit.so 
 with debugging symbols? Have you been able to? Do you have any special tricks 
 in your sleeves?

Oh man, you’re in unchartered waters. Building webkit is a royal pain in the 
neck :-(. You’ve already ventured farther than I have. Maybe Peter Z. or one of 
the guys on our team (in Russia) who have been working more with webkit will 
have a good answer, but in general most people on the FX team don’t even build 
webkit, we just use the bits provided in the weekly builds.

Richard

Re: CFV: New OpenJFX Committer: Sandra Lions-Piron

[Richard Bair]

Vote: YES

On May 14, 2014, at 10:48 AM, Stephen F Northover 
steve.x.northo...@oracle.com wrote:

 I hereby nominate Sandra Lions-Piron to be an OpenJFX Committer.
 
 Sandra Lions-Piron is a significant contributor of the JavaFX Scene Builder 
 2.0 product, and is the designated owner of the Hierarchy Panel as well as 
 all menu commands. Sandra has been working on SB since its inception 4 years 
 ago, and during last year has been responsible for approximately 750 commits 
 to the SB 2.0 repository that we are converting to Open Source.
 
 Sandra is part of the team that has collectively done the Scene Builder 2.0 
 product, which is a complete re-implementation of the code base, over a 
 period of roughly 12 months. The new code base is more than 70,000 lines of 
 code, spread over approximately 4000 commits.
 Scene Builder 2.0 is in the process of being converted to the OpenJFX 
 repository, and will be maintained out of that repository after the 
 conversion.
 
 
 Votes are due by May 29, 2014.
 
 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
 

Re: CFV: New OpenJFX Committer: Mo Chicharro

[Richard Bair]

Vote: YES

On May 14, 2014, at 10:48 AM, Stephen F Northover 
steve.x.northo...@oracle.com wrote:

 I hereby nominate Mo Chicharro to be an OpenJFX Committer.
 
 Mo Chicharro is a significant contributor of the JavaFX Scene Builder 2.0 
 product, and, as the visual and interaction designer, he is the designated 
 owner of all FXML and CSS content. Mo has been working on SB since its 
 inception 4 years ago, and during last year has been responsible for 
 approximately 160 commits to the SB 2.0 repository that we are converting to 
 Open Source.
 
 Mo is part of the team that has collectively done the Scene Builder 2.0 
 product, which is a complete re-implementation of the code base, over a 
 period of roughly 12 months. The new code base is more than 70,000 lines of 
 code, spread over approximately 4000 commits.
 Scene Builder 2.0 is in the process of being converted to the OpenJFX 
 repository, and will be maintained out of that repository after the 
 conversion.
 
 Votes are due by May 29, 2014.
 
 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
 

Re: CFV: New OpenJFX Committer: Eric Le Ponner

[Richard Bair]

Vote: YES

On May 14, 2014, at 10:33 AM, Stephen F Northover 
steve.x.northo...@oracle.com wrote:

 I hereby nominate Eric Le Ponner to be an OpenJFX Committer.
 
 Eric Le Ponner is a significant contributor of the JavaFX Scene Builder 2.0 
 product, and is the architect of the SB Kit API as well as the designated 
 owner of the Content Panel.  Eric has been working on SB for more than 3 
 years, and during last year has been responsible for approximately 1620 
 commits to the internal SB 2.0 repository that we are converting to Open 
 Source.
 
 Eric is part of the team that has collectively done the Scene Builder 2.0 
 product, which is a complete re-implementation of the code base, over a 
 period of roughly 12 months. The new code base is more than 70,000 lines of 
 code, spread over approximately 4000 commits.
 Scene Builder 2.0 is in the process of being converted to the OpenJFX 
 repository, and will be maintained out of that repository after the 
 conversion.
 
 
 Votes are due by May 29, 2014.
 
 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
 

Re: CFV: New OpenJFX Committer: Yves Joan

[Richard Bair]

Vote: YES

On May 14, 2014, at 10:48 AM, Stephen F Northover 
steve.x.northo...@oracle.com wrote:

 I hereby nominate Yves Joan to be an OpenJFX Committer.
 
 Yves Joan is a significant contributor of the JavaFX Scene Builder 2.0 
 product, and is the designated owner of the Library Panel, Document Panel and 
 product packaging. Yves has been working on SB since its inception 4 years 
 ago, and during last year has been responsible for approximately 960 commits 
 to the SB 2.0 repository that we are converting to Open Source.
 
 Yves is part of the team that has collectively done the Scene Builder 2.0 
 product, which is a complete re-implementation of the code base, over a 
 period of roughly 12 months. The new code base is more than 70,000 lines of 
 code, spread over approximately 4000 commits.
 Scene Builder 2.0 is in the process of being converted to the OpenJFX 
 repository, and will be maintained out of that repository after the 
 conversion.
 
 
 Votes are due by May 29, 2014.
 
 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
 

Re: CFV: New OpenJFX Committer: Jerome Cambon

[Richard Bair]

Vote: YES

On May 14, 2014, at 10:39 AM, Stephen F Northover 
steve.x.northo...@oracle.com wrote:

 I hereby nominate Jerome Cambon to be an OpenJFX Committer.
 
 Jerome Cambon is a significant contributor of the JavaFX Scene Builder 2.0 
 product, and is the designated owner of the Inspector Panel as well as the 
 CSS Panel. Jerome has been working on SB for more than 3 years, and during 
 last year has been responsible for approximately 500 commits to the SB 2.0 
 repository that we are converting to Open Source.
 
 Jerome is part of the team that has collectively done the Scene Builder 2.0 
 product, which is a complete re-implementation of the code base, over a 
 period of roughly 12 months. The new code base is more than 70,000 lines of 
 code, spread over approximately 4000 commits.
 Scene Builder 2.0 is in the process of being converted to the OpenJFX 
 repository, and will be maintained out of that repository after the 
 conversion.
 
 
 Votes are due by May 29, 2014.
 
 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
 

Re: Why can Scene's only be constructed on the UI thread?

[Richard Bair]

Hi,

Actually I don’t know of any reason why Window and Scene cannot be created and 
initialized on any thread. Each of these has a peer, and the *peer* we can’t 
update except on the right thread (or with care, these are OS specific 
restrictions or issues). But I don’t see any reason why the Java side cannot be 
initialized on any background thread. And in fact, that was always my intent 
for exactly these reasons, having experienced all this pain in Swing before 
firsthand.

Its just work that needs to be done, contributions welcome :-)

Richard

On Apr 26, 2014, at 12:48 PM, Tony Anecito adanec...@yahoo.com wrote:

 Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 
 was going to address this via 2 drawing threads and modularity but jigsaw was 
 delayed and not sure what happened to the 2 drawing thread idea. I really 
 wish we could instantiate windows in memory and when needed draw them. The 
 user experience and perception of java would be so much better for the client 
 side. If someone on the java client side knows how to do this I would love to 
 try it to verify it.
  
 Best Regards,
 Tony Anecito
 On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote:
 
 
 At e(fx)clipse we have an FXML to Java translator who removes all the
 reflection overhead from FXML. It does not yet support all FXML features
 but we are steadily improving it and with test cases we are able to fix
 problems quite fast. Maybe this is an option for you?
 
 
 That would be very interesting to try, yes please! Where can I find it? My
 project is Java 8 based so that's no problem.

Re: Drawing using multiple threads in Swing EDT - Can JavaFX support this?

[Richard Bair]

 I do not know if JavaFX was ever designed to allow such an approach.

The intent was that you wouldn't have to, but that the system would do it for 
you. That is, we (in theory) would break a scene graph down and process it with 
multiple threads, both for bounding volume computations as well as 
rasterization, utilizing the hardware efficiently and sparing you the pain. 
With Canvas, if you needed to draw your own, you could do so (setup draw 
commands and apply them to the canvas on the fx thread).

We don't have optimal threading on the graphics side yet, one of my biggest 
todo items (a refactoring there could also yield a pipeline more friendly to 
advanced GPU usage whereas now we basically do es 2.0 only).

The deficiency with the canvas approach compared to java 2D is that the 
construction happens on a background thread but rasterization does not.

You can still use Java2D with FX exactly as you did with swing, as buffered 
images can be fed to the fx scene graph.

Richard 

Re: JavaFX 2 + with LWJGL ( OpenGL )

[Richard Bair]

When you get your game finished, let us know :-).

On Apr 6, 2014, at 10:09 AM, Exo Verse tora...@gmail.com wrote:

 Windows makes its own separate stack space for each OpenGL context
 integration. Which is why it runs so smoothly on Windows7. Win7 already
 separates each running process as independent from each other. I can't
 speak for Win8+. I don't like Win8, but that's another topic all of its
 own. You can use OpenGL API with anything. That in itself is not the
 problem. The problem is, Mixing 2D AND 3D into one. That is where GUIs are
 a problem for OpenGL and DirectX. You have to design your own if you're
 making your own game engine, which I am. The problem I kept running into is
 the tools needed for GUI design is crazy expensive or not enough info. I am
 an indie game dev, so I have to use what is available to me. JavaFX is
 brilliant in the way it's GUI design works. I have tried JMonkey, but even
 their Nifty GUI is not exactly user friendly. Same goes with JOGL. LWJGL is
 simple to use and it uses the same calls as C++ API call in OpenGL use. So
 since I am used to the API calls of OpenGL, LWJGL was a no brainer for me.
 
 So I'll break down your question : if you get a native OpenGLContext i
 thought you could use any other library to mix in custom OpenGL code into
 your javafx application
 The short answer is, you can, but with limited means because 2D and 3D
 can't be mixed without a LOT of overhead, at least, that was what I kept
 reading all over the net. Well, thanks to your link you provided me
 earlier, I was able to find someone who figured out how to do it with as
 little overhead as possible. I have his code on my computer now and I have
 been going over it. I can't believe it is this simple. LWJGL and JavaFX do
 work well together. I am very impressed.
 
 I have enjoyed our conversations Tom. You have definitely made my day. :)
 
 Cheers,
 Torak
 
 
 On Sun, Apr 6, 2014 at 12:56 PM, Tom Schindl 
 tom.schi...@bestsolution.atwrote:
 
 My wording was incorrect better worded: javafx does not  ship an OpenGL
 prism pipeline on Windows. And to repeat if you get a native OpenGLContext
 i thought you could use any other library to mix in custom OpenGL code into
 your javafx application, not?
 
 Tom
 
 Von meinem iPhone gesendet
 
 Am 06.04.2014 um 18:41 schrieb Exo Verse tora...@gmail.com:
 
 Yea the OpenGL comes with your graphics drivers for your video card. So
 your correct that it doesn't ship with JavaFX. What I have been going on
 about is trying to find a way to use JavaFX with LWJGL. In case you are
 unaware, LWJGL just means Light Weight Java OpenGL and its a wrapper
 for
 the OpenGL API. It's an alternative to JOGL.
 
 On another note, as I did a search, Thanks to Tom showing me that link I
 examined that code and I found something of interest in the JOGL code
 interface..  well it lead me to a google search, and viola..  LWJGL with
 JavaFX. :)
 
 LINK :
 https://github.com/Spasi/LWJGL-FX
 
 So just wanted to post the link here and say thanks for all of your
 help. :)
 
 Cheers,
 Torak
 
 
 On Sun, Apr 6, 2014 at 12:35 PM, Tom Schindl 
 tom.schi...@bestsolution.atwrote:
 
 JavaFX does not ship OpenGL binaries on windows you have to build it
 your
 own.
 
 Please note:
 a) if there are people who manage to write a prism pipeline on jogl why
 should you not be able to do the same with lwjgl?
 b) the talk i mentionned from felipe and steve show how to get access to
 the native OpenGL context and there from you can use any API you like
 can't
 remember which one they used
 
 Tom
 
 Von meinem iPhone gesendet
 
 Am 06.04.2014 um 18:18 schrieb Exo Verse tora...@gmail.com:
 
 Thanks, but as I mentioned in my original post, I don't like JOGL. It
 doesn't work with my setup. I use LWJGL because its only about the
 OpenGL
 and not other libraries, and its an easy API wrapper to use. There are
 many
 many reason I hate JOGL.. but this thread is not about hating on JOGL,
 its
 about finding a way to use LWJGL with JavaFX2+.
 
 Also, Win32 API calls can use both DirectX and OpenGL APIs. And it
 doesn't
 matter what Windows OS you're using. I have tested this out from
 Windows
 XP
 all the way to Windows 7 - 32/64 Bit with no problem.
 
 Cheers
 Torak
 
 
 On Sun, Apr 6, 2014 at 11:52 AM, Tom Schindl 
 tom.schi...@bestsolution.atwrote:
 
 There is a talk from Felipe and Steve at J1 last year how to embed
 OpenGL
 into FX using *internal* API!
 
 Search for it on parleys - this does not help you on Win32 which uses
 directx instead of javafx. BTW there are people doing a JOGL pipeline
 https://bitbucket.org/dejayberlin/joglfxpipeline/src!
 
 Tom
 Von meinem iPhone gesendet
 
 Am 06.04.2014 um 17:25 schrieb Exo Verse tora...@gmail.com:
 
 Yea its a shame that using JavaFX as an option along with OpenGL
 wasn't
 even thought of to begin with. I don't understand why they limit you
 like
 they do. Them trying to recreate the wheel and make their own version
 of
 a
 3D interface is just plain 

Re: [RT-33954] static block...causes IllegalStateException - re-open?

[Richard Bair]

Yes, this is one of the few things that I just hate about IDEA.

On Apr 7, 2014, at 6:00 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote:

 I can't speak to other IntelliJ issues, but the root cause of this particular 
 one is the same thing that Debbie ran into last week -- IntelliJ doesn't 
 launch programs using the standard Java launcher. For whatever reason, it 
 uses its own launcher. This might be worth raising with JetBrains.
 
 -- Kevin
 
 
 Jonathan Giles wrote:
 Kevin,
 
 Yes, that is the program I used, and yes, I get the 'Toolkit not 
 initialized' exception. I am running IntelliJ, so that is the reason. I 
 switched over to Eclipse and the code run as expected.
 
 I am slightly bothered by the occasional failures that seem to be 
 IntelliJ-specific. I have a gut feeling that it doesn't always run all tests 
 (or that it runs them slightly differently to get different results than 
 when run on the command line). Does anyone know why this is?
 
 I'm actually most at home in Eclipse, so perhaps I should switch to that as 
 my primary IDE for OpenJFX development.
 
 -- Jonathan
 
 On 8/04/2014 11:29 a.m., Kevin Rushforth wrote:
 Just to make sure we are running the same program, the one I ran to verify 
 that RT-33954 is fixed was the simple test program in the comments of that 
 bug. Here it is (with the imports omitted for brevity).
 
 public class Example extends Application {
   public static void main(String[] args) {
   //this is called from a static block in javafx.scene.control.Control
   PlatformImpl.setDefaultPlatformUserAgentStylesheet();
 
   Application.launch(args);
   }
 
   @Override
   public void start(final Stage primaryStage) throws Exception {
   }
 }
 
 The above program runs fine for me with no exception.
 
 Jonathan: are you seeing something different? Or perhaps running a 
 different example?
 
 NOTE: if you run this from IntelliJ it will not work. I verified that with 
 Debbie last week (on a different issue), which may be why you are seeing a 
 problem. Running it from command line, from NB, or from Eclipse works.
 
 -- Kevin
 
 
 Jonathan Giles wrote:
 Firstly, I agree - this does seem to still be reproducible despite Kevin's 
 comment that it should have been resolved in JavaFX 8.0 due to RT-28754 
 https://javafx-jira.kenai.com/browse/RT-28754, so that is troubling. 
 I'll leave Kevin to comment on that.
 
 Secondly, RT-33954 was closed as a duplicate of RT-28754 
 https://javafx-jira.kenai.com/browse/RT-28754, so it would be better to 
 leave RT-33954 closed and move discussion (including what you recently 
 posted) into RT-28754 https://javafx-jira.kenai.com/browse/RT-28754. The 
 discussion can start in there and most probably a new bug will need to be 
 opened (as RT-28754 https://javafx-jira.kenai.com/browse/RT-28754 did 
 result in a code change that at one point appears to have fixed the 
 problem, so we're possibly dealing with a regression).
 
 Thirdly, whether this is a suitable bug for someone learning the ropes is 
 debatable. I'll leave Kevin to offer his thoughts, but perhaps you can 
 propose a patch that resolves this issue for you in your test scenarios. 
 Also, a good starting point is to develop a simple test application that 
 helps to demonstrate this issue (preferably the test case is a single 
 class with no dependencies), and which you can then share in the jira 
 issue via copy/paste into a comment.
 
 Fourthly, to be a contributor in the OpenJDK requires you to follow a 
 process to get the paperwork in order. It is wise to get that started as 
 soon as possible, as it can sometimes take a while. Here's a link to the 
 process: http://openjdk.java.net/contribute/ The main thing is the OCA.
 
 Finally, welcome! :-)
 
 -- Jonathan
 
 On 6/04/2014 1:06 p.m., Sandipan Razzaque wrote:
 Hi JavaFX devs!
 
 I was wondering how people felt about re-opening this bug? I don't believe
 it has been fixed (see my comment).
 
 I'm also happy to work on it. But, let me know if you think my time would
 be better spent elsewhere. I'm keen to take on a small bug to just get the
 hang of the process and community (I'll be stumbling with mercurial along
 the way too!). I think this bug is an ideal candidate for someone just
 learning the ropes.
 
 https://javafx-jira.kenai.com/browse/RT-33954
 
 Cheers,
 SR
 
 Sandipan Razzaque | www.sandipan.net
 
 

Re: Expected frame rates for a full-screen blur

[Richard Bair]

You might also want to try using the PulseLogger (which was recently refactored 
to be usable from Java Flight Recorder). See 
http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/978e5c042214/modules/base/src/main/java/com/sun/javafx/logging/PrintLogger.java.
 Basically a few system properties are needed and then you should get per-pulse 
data that breaks down the time spent in different places. It seems like it 
shouldn’t be the case, but it looks like you’re fill rate limited. Maybe we are 
sending really huge bitmaps down to the card and the card bus just can’t keep 
up?

-Djavafx.pulseLogger=true

On Apr 4, 2014, at 2:17 PM, Stephen F Northover steve.x.northo...@oracle.com 
wrote:

 Hi Mike,
 
 I'm sorry that I've been unable to get to this until now.  I can recreate the 
 problem you are seeing on my Mac by running ColorfulCirclesApp.  Please enter 
 a JIRA for the problem.  Thanks. Also try this:
 
 Try this:
 
 PerformanceTracker tracker = PerformanceTracker.getSceneTracker(scene);
 Timeline timeline = new Timeline(
  new KeyFrame(Duration.seconds(1), t - {
 System.out.println(::FPS =  + tracker.getAverageFPS());
  }));
 timeline.setCycleCount(Timeline.INDEFINITE);
 timeline.play();
 
 Steve
 
 On 2014-04-04 4:33 PM, Mike Hearn wrote:
 OK, now I'm really puzzled - I watched the JavaFX performance talk from
 2011 and learned about PeformanceTracker. It's too bad that's not public
 API, but it works. I used it like so:
 
 PerformanceTracker tracker = PerformanceTracker.getSceneTracker(scene);
 tracker.setOnRenderedFrameTask(new Runnable() {
 long lastTimestamp = System.currentTimeMillis();
 
 @Override
 public void run() {
 final long now = System.currentTimeMillis();
 long delta = now - lastTimestamp;
 if (delta  1000)
 System.out.println(Frame took  + delta + msec);
 lastTimestamp = now;
 }
 });
 
 The 1000 thing is just to avoid printing a nonsense timestamp when the UI
 hasn't been touched for a while.
 
 The deltas I see are consistently between 10-20msec which would be between
 50 and 60fps, i.e. the vsync of the screen. But the wacky thing is, this
 doesn't change when I increase the size of the window, even though the
 animation is noticeably more choppy. It still says there's a 10-20msec gap
 between frames even though my eyes tell me otherwise. Even when I shrink
 the window size right down and get super smooth animation, the above code
 prints the same kind of deltas.
 
 This makes me think that whatever is going on, the regular JavaFX drawing
 thread isn't the issue. It seems to be churning through the scene at the
 same totally acceptable rate no matter what. So I'm thinking the issue must
 be something to do with how fast the GPU drains the command queue or
 something.
 
 BTW I tried doing -Dprism.order=j2d to see what would happen, and the GUI
 hangs before rendering anything. I'll file a bug on that later.
 
 
 On Thu, Apr 3, 2014 at 11:54 AM, Mike Hearn m...@plan99.net wrote:
 
 How does the OS tank?
 All the OS animations hit the same frame rate as the app itself does. For
 instance, opening Mission Control is normally smooth, but when a maximized
 JFX app is animating, it's not.
 
 It feels like the GPU is being overworked but as I'm not a GPU expert at
 all, I'm not sure where to begin - I am not even sure how to find out the
 frame rate so I know when tweaks are improving things! Is there a way to
 get this data from the system?
 
 

Re: Adding GStreamer plugins

[Richard Bair]

 Turns out it was a stupid mistake on my part causing the last few linking
 errors, I hadn't added one of the C files I needed to the makefile (well I
 had, but I'd then reverted it again without realising!) Thanks to all for
 the prods and advice.
 
 Once I'd done that, the build went through without a hitch - and then it
 was just a case of making the relevant additions to the native code to
 register the MKV type and create a pipeline from it using the plugin. This
 wasn't hard to work out at all; I've since tried several test files in MKV
 format (with AAC audio) all of which play in MediaPlayer without a hitch!

Awesome!

 I mainly wanted to do this as a personal exercise, though I'd imagine this
 is a useful piece of functionality for many others also - so should I
 submit a patch of the changes, or is this unlikely to be accepted? (Again,
 sorry for the perhaps obvious question, I'm rather new to this.) I've had a
 look at the code review process and it seems to suggest adding a patch to
 the relevant JIRA issue for those who don't have commit access (in this
 case 18009), but I don't seem to have permission to do that either?

It sounds like there are perhaps two different ways to move forward here, the 
first is to take a submission in the form of WIKI writeup that we can post so 
that anybody else who wants to try extending the media files can follow the 
path you took. The other is to take a patch for the given JIRA issue. Sadly, 
the JIRA server doesn’t allow just anybody to supply patches, so you will have 
to email to Steve or Kevin and they can attach it to the issue for you.

Thanks!
Richard

Re: Using JavaFX deploy and having signing issues...

[Richard Bair]

 One last hurdle, you need to remove the media library for JavaFX 
 (lib/libjfxmedia.dylib) from your bundled JDK.  It uses QuickTime and that is 
 being disowned by apple.  This may be fixed in a later 8u update, but not in 
 8.0.0_b132.

Oh good grief, Apple! So what should we be using instead? This means I cannot 
make use of fx media in any app submitted to the app store?

Richard

Re: *PropertyBase vs Simple*Property

[Richard Bair]

Cool. What we then need to measure is the impact to dynamic footprint (i.e.: 
heap usage). Do the extra 3 fields per property object (bean, name, invalidated 
method) have any significant impact? Or are these property instances created so 
infrequently that it doesn’t make any real difference?

Richard

On Mar 21, 2014, at 12:53 PM, Tom Schindl tom.schi...@bestsolution.at wrote:

 Hi Richard,
 
 Coming back to this old thread and now that we are using lamdas all over
 I guess we could take one more look into that.
 
 I've prototyped an initial version by introducing a new internal type
 named InvalidatedSimpleObjectProperty (not the best name ever!) - see
 code pasted below.
 
 And now one can write code like this:
 
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new InvalidatedSimpleObjectProperty(this, 
 viewport, (o) - {
  invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
} );
}
return viewport;
}
 
 instead of
 
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new ObjectPropertyBaseRectangle2D() {
 
@Override
protected void invalidated() {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
}
 
@Override
public Object getBean() {
return ImageView.this;
}
 
@Override
public String getName() {
return viewport;
}
};
}
return viewport;
}
 
 Which allows us to get rid of most of the ObjectPropertyBase sublcasses.
 
 Tom
 
 
 package com.sun.javafx.property;
 
 import java.util.function.Consumer;
 
 import javafx.beans.property.SimpleObjectProperty;
 
 public final class InvalidatedSimpleObjectPropertyT extends 
 SimpleObjectPropertyT {
  private final ConsumerInvalidatedSimpleObjectPropertyT 
 invalidationConsumer;
  
/**
 * The constructor of {@code ObjectProperty}
 * 
 * @param initialValue
 *the initial value of the wrapped value
 * @param invalidationConsumer
 *  the consumer to be called when the bean is 
 invalidated
 */
public InvalidatedSimpleObjectProperty(T initialValue, final 
 ConsumerInvalidatedSimpleObjectPropertyT invalidationConsumer) {
super(initialValue);
if( invalidationConsumer == null ) {
  throw new IllegalArgumentException(Consumer can not be null);
}
this.invalidationConsumer = invalidationConsumer;
}
 
/**
 * The constructor of {@code ObjectProperty}
 * 
 * @param bean
 *the bean of this {@code ObjectProperty}
 * @param name
 *the name of this {@code ObjectProperty}
 * @param invalidationConsumer
 *  the consumer to be called when the bean is 
 invalidated
 */
public InvalidatedSimpleObjectProperty(Object bean, String name, final 
 ConsumerInvalidatedSimpleObjectPropertyT invalidationConsumer) {
   super(bean, name);
   if( invalidationConsumer == null ) {
  throw new IllegalArgumentException(Consumer can not be null);
   }
   this.invalidationConsumer = invalidationConsumer;
}
 
/**
 * The constructor of {@code ObjectProperty}
 * 
 * @param bean
 *the bean of this {@code ObjectProperty}
 * @param name
 *the name of this {@code ObjectProperty}
 * @param initialValue
 *the initial value of the wrapped value
 * @param invalidationConsumer
 *  the consumer to be called when the bean is 
 invalidated
 */
public InvalidatedSimpleObjectProperty(Object bean, String name, T 
 initialValue, final ConsumerInvalidatedSimpleObjectPropertyT 
 invalidationConsumer) {
super(bean,name,initialValue);
if( invalidationConsumer == null ) {
  throw new IllegalArgumentException(Consumer can not be null);
}
this.invalidationConsumer = invalidationConsumer;
}
 
@Override
protected void invalidated() {
  invalidationConsumer.accept(this);
}
 }
 
 
 On 22.01.13 10:30, Richard Bair wrote:
 Is the Java8 plan still there if not should the current Simple*Property
 subclasses who overload invalidated be changed to PropertyBase?
 
 It is unlikely that we'll be able to do anything major here in Java 8 just 
 because we don't really have Lambda yet that we can play with, and changing 
 over every property is a big job. Unless we knew it would be a major win. I 
 would say, if you encounter a Simple* property that has been subclassed

Re: Lambda Lambda

[Richard Bair]

InvalidationListener has one param, ChangeListener has 3. So the arity of the 
lambda tells the compiler which kind to produce. If there was ambiguity, the 
compiler would complain.

Richard

On Mar 20, 2014, at 12:54 PM, Scott Palmer swpal...@gmail.com wrote:

 So I'm looking at Java 8 stuff now and I see that addListener has
 methods.  One takes a ChangeListener, the other an
 InvalidationListener.
 
 So what does this do:
 
 Node n = getSomeNode();
 n.managedProperty().addListener(x - test(x));
 
 Well it seems it adds an InvalidationListener.
 
 So I tried this:
 
 n.managedProperty().ChangeListeneraddListener(x - test(x));
 
 which seems to be accepted syntax, but it still adds an InvalidationListener 
 !!!
 
 Help Please.
 
 Why didn't JavaFX 8 add two new methods:
 addChangeListener
 addInvalidationListener
 
 ?
 
 Scott

Re: Lambda Lambda

[Richard Bair]

I don’t know.

On Mar 20, 2014, at 1:03 PM, Scott Palmer swpal...@gmail.com wrote:

 So why doesn't this complain:
 n.managedProperty().ChangeListeneraddListener(x - test(x));
 
 ChangeListener has no business being there.
 
 Scott
 
 On Thu, Mar 20, 2014 at 4:02 PM, Scott Palmer swpal...@gmail.com wrote:
 Thanks.. just figured that out myself.
 As my colleague just said to me the world is good again
 
 On Thu, Mar 20, 2014 at 4:00 PM, Richard Bair richard.b...@oracle.com 
 wrote:
 InvalidationListener has one param, ChangeListener has 3. So the arity of 
 the lambda tells the compiler which kind to produce. If there was 
 ambiguity, the compiler would complain.
 
 Richard
 
 On Mar 20, 2014, at 12:54 PM, Scott Palmer swpal...@gmail.com wrote:
 
 So I'm looking at Java 8 stuff now and I see that addListener has
 methods.  One takes a ChangeListener, the other an
 InvalidationListener.
 
 So what does this do:
 
 Node n = getSomeNode();
 n.managedProperty().addListener(x - test(x));
 
 Well it seems it adds an InvalidationListener.
 
 So I tried this:
 
 n.managedProperty().ChangeListeneraddListener(x - test(x));
 
 which seems to be accepted syntax, but it still adds an 
 InvalidationListener !!!
 
 Help Please.
 
 Why didn't JavaFX 8 add two new methods:
 addChangeListener
 addInvalidationListener
 
 ?
 
 Scott
 

Re: EasyBind: custom bindings made easy (with lambdas)

[Richard Bair]

Ah, this is really nice!

BindingBoolean bb = EasyBind.select(control.sceneProperty()) 
.select(s - s.windowProperty()) 
.selectObject(w - w.showingProperty());

On Mar 19, 2014, at 9:12 AM, Tomas Mikula tomas.mik...@gmail.com wrote:

 Hi all,
 
 I just released EasyBind (http://www.fxmisc.org/easybind/), a tiny
 library with several factory methods to create bindings using lambdas.
 The most prominent feature is probably the type-safe select binding
 based on this feature request for JavaFX 9:
 https://javafx-jira.kenai.com/browse/RT-35923.
 
 Regards,
 Tomas

Re: Congratulations

[Richard Bair]

 So yes, a big THANK YOU to Richard and his team and everyone at Oracle and
 all the other individuals and 3rd parties who have contributed to getting
 JavaFX (and Java) to where it is today.
 
 You guys/gals should be really proud :-)

I agree, congrats to all the folks inside and outside Oracle that have been 
making tremendous contributions to JavaFX! A special thanks to Steve for really 
pushing OpenJFX as a real open source project with an open development process. 
We really want to work with the community on this project on an equal footing. 
We’ve had tons of valuable contributions in the form of bug fixes, blog posts, 
technical discussions, and patches. Keep up the great work! 8u20 has a big pile 
of bug fixes, so please do kick the tires on that one. Lots of great work going 
on in terms of Accessibility right now, also embedded work and as always 
performance work. Scene Builder is healthy and active, we’d love to see it 
embedded in all the IDEs and direct contributions from the community to Scene 
Builder would be fantastic. A big thanks to the porters brining JavaFX to 
Android/iOS and other platforms! Looking forward to 8u20 and Java 9!

Richard

Re: Congratulations

[Richard Bair]

Hi Neil,

Yes, I expect that feature planning for 9 and so forth should happen on this 
list and I hope will be in large part driven by those features / bugs / ideas 
that come from people in the community, and that they would include code 
contributions to help get it done :-)

Richard

On Mar 19, 2014, at 11:51 AM, ngalarn...@abinitio.com wrote:

 Congratulations and Thank You to all of the JavaFX folks! 
 
 Richard, in one of your Java One talks you spoke about opening up the OpenJFX 
 project further. 
 
 Will there be discussions on the list as to what is coming next? 
 
 
 Thanks, 
 
 Neil 
 
 
 
 
 From:Richard Bair richard.b...@oracle.com 
 To:Felix Bembrick felix.bembr...@gmail.com 
 Cc:openjfx-dev@openjdk.java.net Mailing 
 openjfx-dev@openjdk.java.net 
 Date:03/19/2014 02:46 PM 
 Subject:Re: Congratulations 
 Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net 
 
 
 
  So yes, a big THANK YOU to Richard and his team and everyone at Oracle and
  all the other individuals and 3rd parties who have contributed to getting
  JavaFX (and Java) to where it is today.
  
  You guys/gals should be really proud :-)
 
 I agree, congrats to all the folks inside and outside Oracle that have been 
 making tremendous contributions to JavaFX! A special thanks to Steve for 
 really pushing OpenJFX as a real open source project with an open development 
 process. We really want to work with the community on this project on an 
 equal footing. We’ve had tons of valuable contributions in the form of bug 
 fixes, blog posts, technical discussions, and patches. Keep up the great 
 work! 8u20 has a big pile of bug fixes, so please do kick the tires on that 
 one. Lots of great work going on in terms of Accessibility right now, also 
 embedded work and as always performance work. Scene Builder is healthy and 
 active, we’d love to see it embedded in all the IDEs and direct contributions 
 from the community to Scene Builder would be fantastic. A big thanks to the 
 porters brining JavaFX to Android/iOS and other platforms! Looking forward to 
 8u20 and Java 9!
 
 Richard 
 
 
 
 NOTICE from Ab Initio: This email (including any attachments) may contain 
 information that is subject to confidentiality obligations or is legally 
 privileged, and sender does not waive confidentiality or privilege. If 
 received in error, please notify the sender, delete this email, and make no 
 further use, disclosure, or distribution.

Re: FXML, Presentation Model bi-directional binding

[Richard Bair]

Sadly, still not possible :-(. Though I still think it's a great way to go!

 On Jan 20, 2014, at 7:45 PM, Christian Schudt christian.sch...@gmx.de wrote:
 
 Hi together,
 
 I just (re-)read Richard's excellent article 
 http://fxexperience.com/2011/10/fxml-why-it-rocks-and-the-next-phase/
 
 He talks about the next phase in FXML being the Presentation Model and the 
 use of bidirectional binding in FXML.
 
 I really like to make use of it because I think it's the way to go and 
 better than MVC pattern. (I've worked with PM pattern in Flex/MXML and it was 
 really comfortable.)
 
 Now this article is 2.5 years old and I wonder, what's the current state of 
 the next phase, i.e. bi-directional binding in FXML or at least 
 uni-directional binding.
 
 I just tried the proposed syntax out and it doesn't work with Java 8, so I 
 assume it's still not possible!?
 
 Thanks for answer,
 Best regard,
 
 Christian
 
 

Re: Future of Skins

[Richard Bair]

Could you write a single skin that delegates to one or more reusable skins?

On Jan 7, 2014, at 7:26 AM, John Hendrikx hj...@xs4all.nl wrote:

 On 7/01/2014 14:50, Tomas Mikula wrote:
 Interesting ideas. I'm wondering, do you switch skins often enough that you 
 are worried about performance (and thus care about reusability of skins)? 
 Because I don't see how reusability of skins saves you lines of code - 
 whether the code is in the constructor or in the initialize() method, it is 
 there somewhere. In my opinion, reusing objects is more complicated than 
 creating fresh instances and the only justification for it is performance.
 
 To address your last point first, if you already are required to write a 
 proper dispose method, then fresh instances should be just as easy/hard to 
 write as reusable ones.  Everything is already in place, just rename the 
 constructor.  Of course, if you did not write a proper dispose method, then 
 your object will stick around or cause other trouble.  With fresh instances 
 you won't notice this so readily -- in JavaFX for example, the problem of 
 having objects that are no longer actively reachable through the SceneGraph, 
 but are still participating in Event handling (because they registered 
 non-weak listeners) can be a nice source of surprises.  With reusable 
 objects, you'll notice the bugs in your cleanup code likely the first time 
 you reuse it.
 
 Anyway, for me, making Skins reusable makes them easier to use with bindings, 
 and it ofcourse saves creating a factory.  I see the skin of an object as 
 the same as say its background color.  There is no reason (anymore I think) 
 that one should be treated so differently from the other.
 
   private final Skin someExistingSkin = new SkinA();
   private final Skin someExistingSkin2 = new SkinB();
 
   void changeToSquareLook() {
  myControl.setSkin(someExistingSkin);
   }
 
   void changeToRoundLook() {
  myControl.setSkin(someExistingSkin2);
   }
 
 vs.
 
  private final SkinFactory skinFactory = new SkinFactory() {
 public Skin createSkin(Control control) {
 return new SkinA(control);
 }
  };
 
  private final SkinFactory skinFactory2 = new SkinFactory() {
 public Skin createSkin(Control control) {
 return new SkinB(control);
 }
  };
 
  void changeToSquareLook() {
 myControl.setSkin(skinFactory.createSkin(myControl));
  }
 
   void changeToRoundLook() {
 myControl.setSkin(skinFactory2.createSkin(myControl));
   }
 
 It's not really about performance, but ease of use.  The binding case 
 requires a ChangeListener instead of just bind().
 
 I agree with you on the problem of separation of skin initialization from 
 setSkin(). Another way to address this could be deprecating the original 
 setSkin() method and introducing
 
setSkin(SkinProviderC skinProvider);
 
 where SkinProvider is a SAM interface and thus the above method could be 
 called like this:
 
setSkin(control - new MySkin(control));
 
 I know this defeats reusability of skins altogether, so you (and others) may 
 disagree.
 Maybe if there was a skinProviderProperty... then I could bind to that 
 atleast.  Still introduces lots of factories (or functions).
 
 --John
 

Re: properties of custom controls in SceneBuilder

[Richard Bair]

Thanks!

On Jan 6, 2014, at 8:33 AM, Eric Le Ponner eric.le.pon...@oracle.com wrote:

 I would say it's deeply embedded.
 
 SB2 currently defines a fixed list of property classes that can be edited 
 in the Inspector panel.
 Extending this list with a new type means:
 - adding some specific metadata that help Scene Builder to edit/create FXML 
 text
 - adding some specific UI logic that enables the Inspector panel to present 
 and let the user edit the value
 Doing this requires a pretty deep understanding of SB2 architecture.
 
 Eric
 
 
 
 Le 6 janv. 2014 à 17:20, Richard Bair richard.b...@oracle.com a écrit :
 
 If somebody else wanted to contribute, where should they go looking for 
 those limitations and how to remove them? Or is it very deeply embedded in 
 the code?
 
 On Jan 3, 2014, at 2:15 AM, Eric Le Ponner eric.le.pon...@oracle.com wrote:
 
 Yes, SB currently makes a filtering :  for custom components, it displays:
 - properties that are inherited from JavaFX core classes
 - properties with basic java types (integer, double, string, boolean).
 
 We'll try to remove some of those limitations over the time.
 
 Eric
 
 
 Le 3 janv. 2014 à 11:01, Tom Eugelink t...@tbee.org a écrit :
 
 
 Adding the controls in JFXtras to SceneBuilder worked without a problem, 
 but scene builder does not show all their properties. For example 
 CalendarTextField has 5 properties like Locale, Calendar, DateFormat, but 
 only promptText is shown by SceneBuilder.
 
 
 
 
 
 
 

Re: properties of custom controls in SceneBuilder

[Richard Bair]

If somebody else wanted to contribute, where should they go looking for those 
limitations and how to remove them? Or is it very deeply embedded in the code?

On Jan 3, 2014, at 2:15 AM, Eric Le Ponner eric.le.pon...@oracle.com wrote:

 Yes, SB currently makes a filtering :  for custom components, it displays:
 - properties that are inherited from JavaFX core classes
 - properties with basic java types (integer, double, string, boolean).
 
 We'll try to remove some of those limitations over the time.
 
 Eric
 
 
 Le 3 janv. 2014 à 11:01, Tom Eugelink t...@tbee.org a écrit :
 
 
 Adding the controls in JFXtras to SceneBuilder worked without a problem, but 
 scene builder does not show all their properties. For example 
 CalendarTextField has 5 properties like Locale, Calendar, DateFormat, but 
 only promptText is shown by SceneBuilder.
 
 
 
 
 

Re: scenebuilder and migpane

[Richard Bair]

 MigLayout is a very popular layout engine in Swing and SWT (and also gaining 
 ground on Android), I think it would be good for SceneBuilder to better 
 support MigLayout.

+1, I’d love to see enough support in SceneBuilder that any 3rd party layout 
container could supply editor support, so that the SceneBuilder team doesn’t 
have to hard code support for different layout containers. This was one of the 
goals of the “Design Time API for Java Beans” JSR (273, or 277? I don’t 
remember) to do the same for Swing. We haven’t got that far with Scene Builder 
but I think the idea is great. MigLayout is widely used enough that we could 
just add hard-coded support for it (maybe you or another person could 
contribute that?). Ideally it would be something any 3rd party layout vendor 
could provide — but in practice there are not that many widely used 3rd party 
layouts — even in the Swing world.

Richard

Re: JavaFX on headless Jenkins

[Richard Bair]

Hi Tom!

On Jan 4, 2014, at 12:57 PM, Tom Eugelink t...@tbee.org wrote:

 I'm trying to run JavaFX UI tests using TestFX on a headless Jenkins server 
 (Ubuntu / Debian). I've gotten to the point where the UI is actually started 
 by Jenkins, but then the test fail with a no suitable pipeline found. Any 
 suggestions how to fix that?

This was one of my long-standing TODO items: have a “headless” glass that would 
allow us to run quantum / prism tests headless. However for running scene graph 
or UI control tests, you should be using the “StubToolkit” instead of 
QuantumToolkit. The StubToolkit is located in Graphics/src/test, so for using 
it for 3rd party tests (like JFXtras) you would need to jar up the classes 
produced during a test run of FX. Then just specify the stub toolkit via 
-Djavafx.toolkit=com.sun.javafx.pgstub.StubToolkit

Now, longer term I wanted to nuke the StubToolkit. If we had a headless Glass 
then we could test with Prism/Quantum directly instead of the stubs. But this 
isn’t straightforward so it hasn’t been attempted yet.

Hope that helps.
Richard

 
 :*test*
 Executing task ':test' (up-to-date check took 0.054 secs) due to:
  No history is available.
 Starting process 'Gradle Worker 1'. Working directory: 
 /var/lib/jenkins/workspace/JFXtras8.0 Command: 
 /usr/lib/jvm/jdk1.8.0-ea/bin/java 
 -Djava.security.manager=jarjar.org.gradle.process.internal.child.BootstrapSecurityManager
  -Dfile.encoding=UTF-8 -ea -cp 
 /var/lib/jenkins/.gradle/caches/1.9/workerMain/gradle-worker.jar 
 jarjar.org.gradle.process.internal.launcher.GradleWorkerMain
 Successfully started process 'Gradle Worker 1'
 Gradle Worker 1 executing tests.
 
 jfxtras.labs.scene.control.test.ListSpinnerEditableTest  
 enterSelectValueByTyping STANDARD_ERROR
Graphics Device initialization failed for :  es2, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing 
 QuantumRenderer: no suitable pipeline found
   at 
 com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:300)
   at 
 com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:244)
   at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:179)
   at 
 com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210)
   at 
 com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653)
   at 
 com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678)
   at 
 com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56)
   at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158)
   at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: 
 no suitable pipeline found
   at 
 com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:98)
   at 
 com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:128)
   ... 1 more
Exception in thread Thread-4 java.lang.RuntimeException: No toolkit found
   at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:191)
   at 
 com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210)
   at 
 com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653)
   at 
 com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678)
   at 
 com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56)
   at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158)
   at java.lang.Thread.run(Thread.java:744)
 
 

Re: [announce] InhiBeans: mitigate redundant recalculations

[Richard Bair]

Have you looked at https://github.com/Netflix/RxJava by chance? I've been dying 
to see somebody do an RxJava in JavaFX ever since devoxx and it looks like you 
may have inadvertently started down that path :-). 

Richard

On Dec 16, 2013, at 8:09 AM, Tomas Mikula tomas.mik...@gmail.com wrote:

 On Mon, Dec 16, 2013 at 1:47 AM, Tomas Mikula tomas.mik...@gmail.com wrote:
 On Mon, Dec 16, 2013 at 1:07 AM, Scott Palmer swpal...@gmail.com wrote:
 Interesting, no worse than John's pattern though.
 I thought of using a try/finally to make sure release was called and that
 naturally lead to thinking of try-with-resources, where the resource in
 this case is a binding of some sort (or a wrapper around a binding) that is
 invalidated on close() if needed.
 
 That is an interesting idea. I didn't intend blockWhile() to be safe
 with respect to exceptions, but merely
 
 void blockWhile(Runnable r) {
block();
r.run();
release();
 }
 
 Enhancement you are suggesting could be fleshed out as block()
 returning an AutoCloseable and the usage would be
 
 try(AutoCloseable a = relaxedArea.block()) {
obj.setWidth(w);
obj.setHeight(h);
 }
 
 OK, done. I implemented both:
 1. added the blockWhile() method;
 2. made bindings AutoCloseable, and block() returns `this`.
 
 Tomas

Re: Scene Builder is now open source!

[Richard Bair]

Really, really great news! Thanks Simon and Eric and the rest of the team for 
getting this done!

Richard

On Dec 3, 2013, at 7:04 AM, Simon Vienot simon.vie...@oracle.com wrote:

 Hello OpenJFXers !
 
 We're very happy to announce that Scene Builder is now open source, as a part 
 of the OpenJFX project.
 The whole Scene Builder functionality is available, including the SB Kit API 
 as well as the standalone SB application.
 The only part of the product which remains closed is the native 
 packaging/installer code.
 SB code is available in rt/apps/scenebuilder/ under the terms of a BSD-style 
 license, similar to JavaFX samples.
 
 You are all welcome to contribute.
 
 Thanks,
 -Simon.
 

Re: Scene Builder is now open source!

[Richard Bair]

And Yves! It looks like you made the magic happen :-)

Thanks!
Richard

On Dec 3, 2013, at 12:16 PM, Richard Bair richard.b...@oracle.com wrote:

 Really, really great news! Thanks Simon and Eric and the rest of the team for 
 getting this done!
 
 Richard
 
 On Dec 3, 2013, at 7:04 AM, Simon Vienot simon.vie...@oracle.com wrote:
 
 Hello OpenJFXers !
 
 We're very happy to announce that Scene Builder is now open source, as a 
 part of the OpenJFX project.
 The whole Scene Builder functionality is available, including the SB Kit API 
 as well as the standalone SB application.
 The only part of the product which remains closed is the native 
 packaging/installer code.
 SB code is available in rt/apps/scenebuilder/ under the terms of a BSD-style 
 license, similar to JavaFX samples.
 
 You are all welcome to contribute.
 
 Thanks,
 -Simon.
 
 

Re: How to activate JavaFX JMX support

[Richard Bair]

Frankly, I don't think it works. In 9 I wanted to revisit tooling and make JMX 
the way metrics are gathered (such as pulse logger stats and such that scenic 
view could use that instead of private Apis, etc)

 On Nov 12, 2013, at 1:38 AM, Sven Reimers sven.reim...@gmail.com wrote:
 
 Hi,
 
 looking into the mbeans available after attaching to the vm I can't see the
 mbeans open sourced last week.
 
 So is there a configuration to activate the registration?
 
 Thanks
 
 -Sven
 
 -- 
 Sven Reimers
 
 * Senior Expert Software Architect
 * NetBeans Dream Team Member: http://dreamteam.netbeans.org
 * Community Leader  NetBeans: http://community.java.net/netbeans
  Desktop Java:
 http://community.java.net/javadesktop
 * JUG Leader JUG Bodensee: http://www.jug-bodensee.de
 * Duke's Choice Award Winner 2009
 * Blog: https://www.java.net//blog/sven
 
 * XING: https://www.xing.com/profile/Sven_Reimers8
 * LinkedIn: http://www.linkedin.com/in/svenreimers
 
 Join the NetBeans Groups:
 * XING: http://www.xing.com/group-20148.82db20
 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home
 * LinkedIn: http://www.linkedin.com/groups?gid=1860468
   http://www.linkedin.com/groups?gid=107402
   http://www.linkedin.com/groups?gid=1684717
 * Oracle: https://mix.oracle.com/groups/18497

Re: JavaFX on iOS and Android: The real problem and challenge

[Richard Bair]

Totally, I think the normal process for this is to create a new OpenJDK 
project, is it not? Can you take a look at the OpenJDK bylaws and report back 
on the process? I think it would be awesome to do a port. Note that there are a 
few OpenJDK ports already which have ARM support, you might want to look there 
as a starting point?

Richard

On Nov 8, 2013, at 1:29 PM, Florian Brunner fbrun...@gmx.ch wrote:

 Yes, I agree, we need professional JVM ports for iOS, Android and Windows 8.
 
 @Oracle: Could you set up the according project sites for these 3 platforms 
 on openjdk.java.net and document what exactly has to be done to port OpenJDK 
 (at least some kind of JavaFX compact profile e.g. without the AWT stack) to 
 these platforms? Also the Mercurial repository and the build should be 
 prepared.
 
 I think if there were an easy starting point it would lower the barrier to 
 work on these ports.
 
 -Florian
 
 Am Donnerstag, 24. Oktober 2013, 08.41:32 schrieb Tobias Bley:
 Hello to the community,
 
 I read the last discussion about „JavaFX native look and feel“ and have to 
 get out of my mind the following:
 
 In my opinion the MAIN point is not „how to bring the native look and feel 
 to iOS/Android“, the real MAIN issue is: we need a professional JVM(!) which 
 works performant and reliable on iOS, Android and Windows 8! Only if we have 
 such a JVM, developers and companies are motivated to develop real 
 commercial apps with JavaFX and contribute stuff back to OpenJFX!
 
 RoboVM is a good „prototype“. Niklas is currently one of the most important 
 people for the JavaFX community. He and his company has build the first and 
 one and only real solution to deploy Java and JavaFX code to the iOS 
 platform! His work is really great! But: He is only one(!) person! This kind 
 of complex task I would expect from big companies like Oracle, IBM, SAP or 
 Twitter. But from this direction we don’t hear anything about it.
 
 It is not enough that people like Niklas (Trillian AB) or Matthias and me 
 (UltraMixer) are trying to bring JavaFX to iOS and Android. It’s all 
 experimental stuff! Yes, currently we can start JavaFX apps on a real iPhone 
 and iPad. And yes, we have managed to start JavaFX on a real Android device 
 using the Dalvik VM. BUT: this is not a long term solution and only 
 experimental! RoboVM on iOS uses the android class library instead of the 
 real Java = OpenJDK. Our „JavaFX on Android“ solution uses Google Dalvik VM 
 and the Android class library as well! So both solutions use the real Java 
 platform (=OpenJDK)!
 
 In my opinion there are only two solutions: 1) Oracle releases their JVM for 
 iOS and Android. 2) The „community“ starts a new company who develops a 
 professional, performant and reliable solution for „JavaFX on iOS and 
 Android“ which contains of a JVM and the 6 degrees Felix described in his 
 blog post, mainly native integration (API) and look and feel (skins, native 
 controls).
 
 Cheers,
 Tobi
 
 
 
 Am 23.10.2013 um 22:30 schrieb Richard Bair richard.b...@oracle.com:
 
 Yes, definitely.
 
 On Oct 23, 2013, at 11:52 AM, Scott Palmer swpal...@gmail.com wrote:
 
 This is starting to sound like it may also partially address the issue in 
 the desktop space of supplying a native surface (the heavyweight) to draw 
 in that is part of the scene graph.  It may not be the ideal solution, but 
 could be useful for specific use cases, like a video preview overlay. 
 Would that make any sense?
 
 
 Scott
 
 
 
 On Tue, Oct 22, 2013 at 7:59 PM, Richard Bair richard.b...@oracle.com 
 wrote:
 To do this we need to either solve the auto-layer problem in the NG nodes 
 / Glass / Quantum, or we need to ask the app developer to use SubScene 
 and put all the native stuff in a single SubScene, and all lightweight 
 content above and below it. For the short term, we could use the SubScene 
 approach (Just be careful and don't draw lightweight on top of 
 heavyweights unless you layer an entire sub scene above them) which is 
 probably a perfectly workable solution in the short term. Then somebody 
 just needs to write a set of skins (which can be done in an external 
 project) that map various UI controls directly to native controls. This 
 approach would allow people to have completely native controls while 
 using the FX API, or they can use the lightweight controls (with Modena 
 or with an iOS 7 skin or iOS 6 skin etc).
 
 I'm thinking about how to implement the auto-layer, and I'm not sure of 
 the best approach. It seems like you need to hook into the sync-time to 
 determine which nodes can be batched into the same layer, reusing 
 previous layers where possible. If there is a way to then setup the NG 
 peer side so that it thinks it was setup in sub scenes etc, although it 
 really wasn't, then that would leave prism out of the problem (which 
 makes this an easier thing to pull off). hmmm. SubScene itself has a 
 peer. So what I'm thinking is, suppose I have a package

Re: Android replaces Dalvik with ART

[Richard Bair]

I *really* doubt this has anything to do with the legal battle, it is much more 
likely to be the fact that Dalvik is painfully slow. Using an AOT compiler is 
not actually changing anything with regards to the fact that their development 
language is Java with a non-TCK compliant set of class libraries. I read a 
really horrible article today that was factually incorrect with regards to the 
technology (claiming that Dalvik executed Java byte-code!). I'm so used to 
reading completely bogus stuff in the press (about subjects that I know!) that 
I really wouldn't recommend believing the stated motivations unless we get 
somebody on record.

Besides which, AOT seems like a fantastic way to go, technically, so I don't 
think it really needs any more reason for it :-)

Richard

On Nov 7, 2013, at 11:24 AM, Tobias Bley t...@ultramixer.com wrote:

 Hi,
 
 after we reached the goal to use JavaFX on Android via Dalvik, Google 
 announces the successor of Dalvik, called ART (Android Runtime). The start to 
 move because of the legal issues with Java and Oracle….
 
 http://source.android.com/devices/tech/dalvik/art.html
 
 The question is now: How to use JFX on Android on top of ART? As I posted in 
 my blog.software4java.com, we need a own JVM to embed in Android apps.
 
 Best regards,
 Tobi
 

Re: Code Review Policies

[Richard Bair]

Awesome! Thanks guys. I hope everybody else sees what I see here -- a constant 
continually effort to improve OpenJFX and make it a real Open Source project in 
every sense of the word. Major thanks to Steve for pushing on this so hard.

Richard

On Nov 7, 2013, at 6:36 AM, Stephen F Northover steve.x.northo...@oracle.com 
wrote:

 Hello Committers,
 
 Let me summarize how to initiate a code review, since this changed recently.
 
 All information about how a bug was fixed needs to be in the JIRA. This means 
 that all patches, webrevs, discussions and who is doing the review needs to 
 be captured there.  The email to openjfx-dev is intended to inform the 
 community that a review is happening so others can join in, but it doesn't 
 need to contain detailed information about the fix.  People can get all that 
 from the JIRA.
 
 This about it this way:  What we are trying to avoid is having any 
 interesting information about the fix appear only in the mailing list.  The 
 bottom line is that the comment section of JIRA should contains the contents 
 of the email that previously you would have sent to the list.  If you want 
 the information to be in two places, that is fine, but it must be in the 
 JIRA.  However, the discussion and any subsequent action is in the JIRA.
 
 https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews
 
 Thanks,
 Steve and Daniel
 

Re: Code Review Policies

[Richard Bair]

Believe me, nothing is that easy when it comes to infrastructure in Oracle (or 
at Sun either, for that matter).

Richard

On Nov 7, 2013, at 4:08 PM, Mark Fortner phidia...@gmail.com wrote:

 Sorry, I didn't understand the connection between code review and external 
 hosting. You currently use JIRA (which is hosted on an Oracle server -- at 
 least that's what whois says), so adding Crucible should just be a matter of 
 sending email to your infrastructure people shouldn't it?
 
 Cheers,
 
 Mark
 
 
 
 On Thu, Nov 7, 2013 at 3:54 PM, Richard Bair richard.b...@oracle.com wrote:
 Yes, we've been looking at it. But until OpenJDK manages to get some code 
 review tool hosted externally, we want something everybody can use.
 
 Richard
 
 On Nov 7, 2013, at 3:53 PM, Mark Fortner phidia...@gmail.com wrote:
 
 Did you guys ever take a look at Crucible (part of the Atlassian suite)?  It 
 makes diff's easier to read, and lets you provide feedback in the context of 
 the code.
 
 Cheers,
 
 Mark
 
 
 
 On Thu, Nov 7, 2013 at 3:21 PM, Richard Bair richard.b...@oracle.com wrote:
 Awesome! Thanks guys. I hope everybody else sees what I see here -- a 
 constant continually effort to improve OpenJFX and make it a real Open 
 Source project in every sense of the word. Major thanks to Steve for pushing 
 on this so hard.
 
 Richard
 
 On Nov 7, 2013, at 6:36 AM, Stephen F Northover 
 steve.x.northo...@oracle.com wrote:
 
  Hello Committers,
 
  Let me summarize how to initiate a code review, since this changed 
  recently.
 
  All information about how a bug was fixed needs to be in the JIRA. This 
  means that all patches, webrevs, discussions and who is doing the review 
  needs to be captured there.  The email to openjfx-dev is intended to 
  inform the community that a review is happening so others can join in, but 
  it doesn't need to contain detailed information about the fix.  People can 
  get all that from the JIRA.
 
  This about it this way:  What we are trying to avoid is having any 
  interesting information about the fix appear only in the mailing list.  
  The bottom line is that the comment section of JIRA should contains the 
  contents of the email that previously you would have sent to the list.  If 
  you want the information to be in two places, that is fine, but it must be 
  in the JIRA.  However, the discussion and any subsequent action is in the 
  JIRA.
 
  https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews
 
  Thanks,
  Steve and Daniel
 
 
 
 
 

Re: iOS Default font is wrong

[Richard Bair]

And then eventually some iOS style sheet needs to be created that will give the 
right defaults for the other controls. I'm hoping to convince Hendrick and 
Claudette to take on that task :-)

 On Oct 30, 2013, at 6:38 AM, Stephen F Northover 
 steve.x.northo...@oracle.com wrote:
 
 Let's use UIButton as this seems to match the stack overflow discussion.
 
 Steve
 
 On 2013-10-30 7:51 AM, Oldrich Maticka wrote:
 I have tried simple app with several controls. Fonts in Interface Builder -
 
 UIButton - System 15.0
 UILabel  - System 17.0
 UITextField - System 14.0
 UITextView - System 14.0
 
 Same fontsize - 15.0 has UIButton's label created at runtime.
 
 UIFont class methods for getting system font information return:
 + labelFontSize 17.0
 + buttonFontSize  18.0
 + smallSystemFontSize 12.0
 + systemFontSize 14.0
 
 
 In fx Java_com_sun_javafx_font_MacFontFinder_getSystemFontSize returns 13.0
 
 We can use different CTFontUIFontType in this method to return something 
 better than 13.0 -
 e.g. with kCTFontPushButtonFontType as an argument to 
 CTFontCreateUIFontForLanguage() it returns 15.0, but we need to decide, what 
 we want to use as default. Should be our system default the size same as for 
 UIButton, UILabel or other control?
 
 
 I was using iPad3 (iOS 7.0, Xcode 5.0).
 
 Olda
 
 On 10/29/13 7:32 PM, Stephen F Northover wrote:
 I was going to create a dummy control (say a Button) and ask for the font.  
 Just an idea.
 
 Steve
 
 On 2013-10-29 2:18 PM, Felipe Heidrich wrote:
 The code Richard sent is creating a dummy font and asking for its size.
 
 The problem is that there are about 3 thousand different fonts on the Mac 
 ;-)
 
 Here we are creating a CTFont. For Mac OS X most native apps probably 
 would be using a NSFont (cause that is what cocoa controls take). Likewise 
 on iOS I think the common font is UIFont (cause I think that is what 
 UIKIt controls take).
 
 Could anyone fire up Xcode, create a dummy iOS app, create a UIFont and 
 see what is the size ?
 
 Felipe
 
 
 On Oct 29, 2013, at 8:40 AM, Stephen F Northover 
 steve.x.northo...@oracle.com wrote:
 
 If the OS is reporting the wrong value for the default a classic trick is 
 to create a dummy control that normally has the font we want and query 
 that.
 
 Steve
 
 On 2013-10-29 11:21 AM, Richard Bair wrote:
 Hi guys,
 
 The default font for iOS is supposed to be System Bold 15 (according to 
 http://stackoverflow.com/questions/17325152/what-size-font-is-the-title-in-a-default-uibutton
  anyway), and it does look more correct to me. Our code is getting to 
 this native method in MacFontFinder.c
 
 JNIEXPORT jfloat JNICALL 
 Java_com_sun_javafx_font_MacFontFinder_getSystemFontSize
   (JNIEnv *env, jclass obj)
 {
 CTFontRef font = CTFontCreateUIFontForLanguage(
  kCTFontSystemFontType,
  0.0, //get system font with default size
  NULL);
 jfloat systemFontDefaultSize = (jfloat) CTFontGetSize (font);
 CFRelease(font);
 return systemFontDefaultSize;
 }
 
 
 However it appears the return value is 13 instead of 15 (and I don't 
 know what the actual default font family / weight is that we're 
 returning). It is possible the answer coming from this native API call 
 is wrong. Any ideas?
 
 Richard
 

Re: JavaFX on iOS and Android - are we there yet?

[Richard Bair]

Yes, definitely.

 On Oct 23, 2013, at 11:52 AM, Scott Palmer swpal...@gmail.com wrote:
 
 This is starting to sound like it may also partially address the issue in the 
 desktop space of supplying a native surface (the heavyweight) to draw in that 
 is part of the scene graph.  It may not be the ideal solution, but could be 
 useful for specific use cases, like a video preview overlay. Would that make 
 any sense?
 
 
 Scott
  
 
 
 On Tue, Oct 22, 2013 at 7:59 PM, Richard Bair richard.b...@oracle.com 
 wrote:
 To do this we need to either solve the auto-layer problem in the NG nodes / 
 Glass / Quantum, or we need to ask the app developer to use SubScene and put 
 all the native stuff in a single SubScene, and all lightweight content above 
 and below it. For the short term, we could use the SubScene approach (Just 
 be careful and don't draw lightweight on top of heavyweights unless you 
 layer an entire sub scene above them) which is probably a perfectly 
 workable solution in the short term. Then somebody just needs to write a set 
 of skins (which can be done in an external project) that map various UI 
 controls directly to native controls. This approach would allow people to 
 have completely native controls while using the FX API, or they can use the 
 lightweight controls (with Modena or with an iOS 7 skin or iOS 6 skin etc).
 
 I'm thinking about how to implement the auto-layer, and I'm not sure of the 
 best approach. It seems like you need to hook into the sync-time to 
 determine which nodes can be batched into the same layer, reusing previous 
 layers where possible. If there is a way to then setup the NG peer side so 
 that it thinks it was setup in sub scenes etc, although it really wasn't, 
 then that would leave prism out of the problem (which makes this an easier 
 thing to pull off). hmmm. SubScene itself has a peer. So what I'm thinking 
 is, suppose I have a package:
 
 com.sun.javafx.ext.ios.controls
 
 and in this package you have all the skins. There is also someplace in here 
 a map of skin - sub scene peer, indicating which of the nodes is in which 
 sub scene peer (layer). Then when the sync takes place, a skin node looks 
 back at siblings etc to determine if it can be placed in the same layer as 
 something before it. If so, then it sets itself as a child on the sub scene 
 as needed. If not, then it creates a new sub scene peer and sets itself on 
 there and then carry on. So then it isn't sync'd to the real scene but 
 instead to one of these fake sub scenes that was created.
 
 The idea can be refined, but actually I think this approach might be 
 workable for doing auto-layering.
 
 Richard
 
 On Oct 22, 2013, at 4:10 PM, Felix Bembrick felix.bembr...@gmail.com wrote:
 
  Yes, having viable implementations of both options would be ideal.
 
  How long till Oracle and/or the community gets to that point? ;-)
 
 
  On 23 October 2013 10:06, Stephen F Northover
  steve.x.northo...@oracle.comwrote:
 
  Rather than arguing this point, the correct answer is to provide both and
  let the application developer choose.
 
  Do you guys know how old this argument is?  Hint: It predates Java.
 
  Steve
 
 
  On 2013-10-22 6:17 PM, Pedro Duque Vieira wrote:
 
  Even the most fab skins or CSS is not going to get us away from the need
  to
  integrate JavaFX controls with true native controls.  As has been 
  pointed
  out, there are some native controls on both iOS and Android for which
  there
  is no JavaFX equivalent and this will always be the case.  Even if
  someone
  were to develop near identical lightweight controls in JavaFX, they 
  would
  need to behave slightly differently on iOS than they do on Android and
  vice
  versa.
 
 
  I don't think this is exactly this straight forward. Ideally you would
  want
  to have this kind of native behavior on every platform. But having this
  native behavior involves having a different version of your app for each
  OS
  you want to deploy in, which might not be what the developers want.
  Remember JavaFX is a cross platform development kit and the major reason 
  a
  developer would choose JavaFX over doing native mobile development is 
  that
  his app can run on a variety of mobile platforms: windows 8, ipad,
  android,
  iPhone, etc with the same code base and *MOST* importantly with much less
  development time than building an app for each platform.
  For the sake of development time an app that doesn't go against any of 
  the
  different platforms UX but that has the least common denominator so that
  each user in each different platform understands the UI might be a better
  solution for the sake of development time. One such example is the back
  button that appears when you drill down a list on an ios app but doesn't
  appear in an android app because every android phone as a physical back
  button.
 
  I do agree with you that there are some places where a native looking
  control is ideal and doesn't involve any extra

Re: JavaFX on iOS and Android - are we there yet?

[Richard Bair]

Another approach which would be a *lot* easier to implement would be to add a 
Layer public API that would allow the app developer to specify what layers 
there are, and where they are (this has a lot of other benefits related to 
performance on embedded and mobile devices). Then, don't solve the heavyweight 
/ lightweight issue, but allow heavyweight native controls to be added 
wherever. Then you just be careful not to have any lightweights on the same 
layer as a heavyweight if they might overlap above the heavyweight.

Of course, you have this API already today in the form of SubScene! I haven't 
tried it in this context though.

Richard

On Oct 22, 2013, at 6:21 AM, David Ray cognitionmiss...@gmail.com wrote:

 +1 re: Native LF.  IMO also there is nothing sacred about the exactness of 
 Apple's ui. They 'll be changing it up a lot a also. Being someone who 
 prefers custom looks to bland native looks anyway, I never did get the 
 sacredness of repeating mirror-lookalike grey :). Just my opinion, I'm 
 sure there are those who disagree.
 
 David
 
 Sent from my iPhone
 
 On Oct 22, 2013, at 7:17 AM, Tobias Bley t...@ultramixer.com wrote:
 
 1) Look and Feel:
 
 IMO it’s enough to build „native looking“ css based skins! That could be 
 very quickly without complex technologies like CALayer etc.
 
 2) After starting RoboVM JavaFX needs round about 10 seconds to start the 
 simple list example on iPhone4. So it’s too long. I tried to use the 
 preloaded class via property „-Djavafx.preloader“ but it doesn’t work, my 
 preloaded class is not instantiated…
 
 Tobi
 
 
 
 Am 21.10.2013 um 21:48 schrieb Richard Bair richard.b...@oracle.com:
 
 1. Can you provide me with a detailed summary of where the iOS/Android
 ports are currently?  This includes the platform specific stuff to make
 either RoboVM or an Oracle JVM work?
 
 I would say, it is in a good prototype stage. It hasn't had heavy testing, 
 so the biggest risk is the unknown. Luckily, on iOS at least there are only 
 a very few devices so it should be relatively easy for an app developer to 
 feel confident it works for their app. But for the OpenJFX project, to test 
 and certify a whole variety of APIs, will be quite a challenge. We have a 
 huge pile of tests, we just need:
  1) To have a way to run our unit tests on the actual devices
  2) Have a way to run graphical tests on devices (basically a port of 
 Jemmy??)
 
 I haven't scoped either of these efforts, but both are ripe areas for 
 collaboration with anybody in the community.
 
 If it were heavily tested, I'd say most of the remaining work is actually 
 in the graphics / performance side. Path rendering performance is fairly 
 bad (though I've seen similar complaints for Cocoa path rendering 
 performance, so it may be we're not that bad relatively speaking, but it 
 is still horrendous IMO and needs to be looked at).
 
 The code is all there for the integration layer -- anybody with familiarity 
 with Objective-C and Cocoa, I'd say, go read the glass code! This is a huge 
 opportunity for community initial community involvement because:
  1) There is a ton of existing documentation and code in the Apple universe 
 describing all the sorts of things we need to do in Glass
  2) Glass is pretty decoupled from the rest of the platform, so you can 
 easily understand what is going on there without having to understand 
 everything else
 
 Contributing on the Graphics side is more work and requires more 
 specialized skills. The fortunate thing here is that the graphics code is 
 shared with embedded (and desktop Mac and Linux) so there is a lot of 
 overlap.
 
 So those would be the main things from my perspective: performance testing, 
 functional / unit testing, native platform integration, and graphics.
 
 Another thing we've designed for from the beginning, but never validated, 
 is the ability to use a native control as the skin. The iOS prototype hot 
 swaps a native text field in when a TextInputControl gets focus, but this 
 is kinda funky (and there are lots of bugs here). The right thing to do 
 here would be to have a set of native skins for controls, and the ability 
 to create multiple core layers. So if you have a scene graph where on the 
 bottom you draw stuff, then have a native control, then draw more stuff 
 over the native control, then what you would want is, on the Prism side, 
 use 3 hardware layers (one for below the native, one for the native, and 
 one for above the native). I don't know:
  1) How well this would work in practice with input events (but one could 
 imagine putting a native 'glass pane' on the top to intercept all events 
 and vector them through FX, forwarding to native controls as necessary as 
 part of the normal FX event dispatch) 
  2) How many layers you could have before things would explode.
 
 Alternatively, using image skinning to get the look right, and only do the 
 funky native control swap in for text input, like we're doing today.
 
 2

Re: JavaFX on iOS and Android - are we there yet?

[Richard Bair]

 1) Look and Feel:
 
 IMO it’s enough to build „native looking“ css based skins! That could be very 
 quickly without complex technologies like CALayer etc.

Generally this should be very easy for somebody to do. There is a ui kit 
already out there that designers use for mocking up UI designs for both the new 
iOS7 look and the previous looks. Should be straight forward to take and turn 
into an image based CSS theme.

 2) After starting RoboVM JavaFX needs round about 10 seconds to start the 
 simple list example on iPhone4. So it’s too long. I tried to use the 
 preloaded class via property „-Djavafx.preloader“ but it doesn’t work, my 
 preloaded class is not instantiated…

What is the state of the jfx78 back port, and how often is it updated? I'm 
wondering what the time is for getting a fix put in before it shows up in the 
back port.

Richard

Re: JavaFX on iOS and Android - are we there yet?

[Richard Bair]

 I would avoid image based CSS files… we should create pure CSS based skins 
 using pure css styles and SVG paths…

That would definitely be (a lot) more work, but if you're going to be scaling 
up the controls you will appreciate them being normal background fills  paths.

Richard

Re: JavaFX on iOS and Android - are we there yet?

[Richard Bair]

 javafx, like for instance: a toggle button (a control that looks like a
 flip switch)

These have are just styled CheckBoxes (or Toggle buttons, or Radio Buttons). 
We've done this for example for DukePad.

 , comboboxes where you change the value through a wheel, etc..

Yes, need this kind of integration.

 and in having controls that have the necessary properties so that they can
 be touchable.

Should already work.

Richard

Re: JavaFX on iOS and Android - are we there yet?

[Richard Bair]

On Oct 22, 2013, at 9:38 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com 
wrote:

 These have are just styled CheckBoxes (or Toggle buttons, or Radio Buttons). 
 We've done this for example for DukePad.
 Yes that's right but I think that as it is used so much on Android, ios and 
 windows 8 it should have a control representation. For instance the same can 
 be said of checkbox, you can make one out of a styled toggle button but as it 
 is used so much it merits being a control.

This is true. From a class count perspective (and embedded) it probably would 
have been better for us not to do CheckBox and RadioButton, but just do 
ToggleButton with some static final ints for doing the styling. But then again, 
maybe not.

  and in having controls that have the necessary properties so that they can
  be touchable.
 I'm talking about having the appropriate size for instance for you to touch 
 it. You can't use Modena straight out for a mobile app. Perhaps having a 
 Modena spinoff that has touch in mind.

This is something worth thinking about. I noticed the fonts weren't the right 
size, implying that the port on iOS isn't picking up the best font size, and 
all the UI controls are sized based on the font, so in theory this might be 
sufficient. But it is true a spin-off with bigger insets might be necessary 
(but it isn't clear to me at least that this will be needed).

 What about input controls that popup the ios keyboard for entering text. Is 
 this already available? If not how can these be achieved. Also we should keep 
 in mind that the keyboard has to change in accordance to what the user has to 
 enter: address, number, email, etc..

Yes, we already show the native keyboard. One mechanism we've discussed for 
input methods is to have some attributes you can add to a TextInputControl's 
properties map, which can then be used to show the right keyboard UI.

Richard

Re: JAVAFX on ANDROID

[Richard Bair]

 1. Is that mouse emulation supposed to be eliminated due to the latest 
 lensWindow changes? 
   I believe that must be handled in higher layers not in the input layer 
 itself.
 
 2. What is the best way to fix this issue? Reimplementing the mouse emulation 
 is not a real good solution.

JavaFX expects to get both Mouse and Touch events when you have a touch screen. 
However I believe multi-touch events are not delivered as mouse events 
(somebody on the embedded side correct me if I'm wrong on that). So an app that 
was designed with mouse events in mind should continue to work when a touch 
screen is provided.

 3. The Listview shows a scrollbar. That makes me believe that the control 
 doesn't really know that it is running
 in embedded mode. Maybe the mouse emulation is not possible if the embedded 
 mode is correcly enabled.
 Where do I enable the embedded mode? I though it is this property 
 android.com.sun.javafx.isEmbedded=true. That's of course enabled
 in javafx.platform.properties.

There's some bit of mess here where some places are explicitly checking iOS etc 
to hide/show stuff instead of just embedded. Jonathan do you remember all the 
places to check?

Richard

Re: JavaFX on iOS and Android - are we there yet?

[Richard Bair]

 1. Can you provide me with a detailed summary of where the iOS/Android
 ports are currently?  This includes the platform specific stuff to make
 either RoboVM or an Oracle JVM work?

I would say, it is in a good prototype stage. It hasn't had heavy testing, so 
the biggest risk is the unknown. Luckily, on iOS at least there are only a very 
few devices so it should be relatively easy for an app developer to feel 
confident it works for their app. But for the OpenJFX project, to test and 
certify a whole variety of APIs, will be quite a challenge. We have a huge pile 
of tests, we just need:
1) To have a way to run our unit tests on the actual devices
2) Have a way to run graphical tests on devices (basically a port of 
Jemmy??)

I haven't scoped either of these efforts, but both are ripe areas for 
collaboration with anybody in the community.

If it were heavily tested, I'd say most of the remaining work is actually in 
the graphics / performance side. Path rendering performance is fairly bad 
(though I've seen similar complaints for Cocoa path rendering performance, so 
it may be we're not that bad relatively speaking, but it is still horrendous 
IMO and needs to be looked at).

The code is all there for the integration layer -- anybody with familiarity 
with Objective-C and Cocoa, I'd say, go read the glass code! This is a huge 
opportunity for community initial community involvement because:
1) There is a ton of existing documentation and code in the Apple universe 
describing all the sorts of things we need to do in Glass
2) Glass is pretty decoupled from the rest of the platform, so you can 
easily understand what is going on there without having to understand 
everything else

Contributing on the Graphics side is more work and requires more specialized 
skills. The fortunate thing here is that the graphics code is shared with 
embedded (and desktop Mac and Linux) so there is a lot of overlap.

So those would be the main things from my perspective: performance testing, 
functional / unit testing, native platform integration, and graphics.

Another thing we've designed for from the beginning, but never validated, is 
the ability to use a native control as the skin. The iOS prototype hot swaps 
a native text field in when a TextInputControl gets focus, but this is kinda 
funky (and there are lots of bugs here). The right thing to do here would be 
to have a set of native skins for controls, and the ability to create multiple 
core layers. So if you have a scene graph where on the bottom you draw stuff, 
then have a native control, then draw more stuff over the native control, then 
what you would want is, on the Prism side, use 3 hardware layers (one for below 
the native, one for the native, and one for above the native). I don't know:
1) How well this would work in practice with input events (but one could 
imagine putting a native 'glass pane' on the top to intercept all events and 
vector them through FX, forwarding to native controls as necessary as part of 
the normal FX event dispatch) 
2) How many layers you could have before things would explode.

Alternatively, using image skinning to get the look right, and only do the 
funky native control swap in for text input, like we're doing today.

 2. Are the iOS and Android ports at roughly the same level of
 completeness/viability?

I think so, David / Tomas, can you guys add some insight as to where we're at 
from your perspective?

 3. Exactly what is left in making these ports viable?  Here the word
 viable is defined in my 6 Degrees of Separation post here
 http://justmy2bits.com/2013/09/30/javafx-on-ios-and-android-six-degrees-of-separation

1. Their look and feel is indistinguishable from native apps

As described above, there is work to be done here either by beefing up the 
emulation, or adding the ability to intersperse native controls. The latter 
approach I expect to be significant work, although technically feasible.

Also, I expect people will want to add more iOS specific controls (like 
breadcrumb bars) to make this easier to do (rather than everybody styling their 
own).

2. They must load as quickly as a native apps

I've heard RoboVM starts up very quickly. Also you will package your app with a 
splash screen. Also I believe the Preloader APIs work now with iOS (I haven't 
tested on RoboVM but try it out and let me know if it works! You will probably 
need to launch a bit differently, providing the preloader as a system property 
I think). So I expect this to work reasonably well.

3. They must perform as well as a native apps once loaded

This is the open question. We may find the graphics to be the bottleneck, or we 
may find that the CPU usage is the bottleneck. On the CPU side, one problem may 
be the large number of method calls to set / get property values. Going to a 
full lazy style for many properties on Node might help here, for instance.

4. They must be able to utilise all (or at least most) of 

Re: JavaFX on iOS and Android - are we there yet?

[Richard Bair]

 Personally I feel we *have* to go with the layering approach as I don't 
 believe look-and-feel emulation will ever give a true native experience (as 
 outlined in my 6 Degrees post).
 
 Has *any* work been done on this layering?

No there hasn't been.

 Are there other products on iOS for example that utilise a similar layering 
 approach that we might be able to learn from?  Maybe on other platforms?

The idea is used by Safari for handling web + plugin mixing, which is a similar 
problem.

 Is any work being done on the graphics performance issues at the moment or is 
 everyone tied up with getting JFX8 out the door?

Pretty much all hands on deck for JDK 8.

 I am willing to get involved with this layering development once I get my 
 soon-to-be-released new MacPro ;-)

One thing you could start with is to get some bounds on the problem. Create a 
stock-n-standard Cocoa app and create as many CALayers as you can, and just see 
what happens to performance. This will give you some idea of how many native 
controls you could mix in. You might be able to do something like this as well: 
given GridPane with 20 controls followed by some more scene graph nodes, you 
could analyze the graph and notice that instead of 22 layers here (one behind, 
20 controls, one above) you can get away with 3 since all the natives are on 
the same level. Its more complicated, but if you find that you cannot have more 
than a handful of layers and keep performance up, its your best bet. 

Also, it would be worth looking at the other guys (like MonoTouch). I think 
they all fall in one of two camps: emulation, or thin-layer over native. We're 
proposing a combination of the two here, which might be unchartered territory 
on iOS.

Richard

Re: Media is now opensource

[Richard Bair]

Sweet! See you there.

 On Oct 18, 2013, at 5:25 PM, Sven Reimers sven.reim...@gmail.com wrote:
 
 Put me down as interested Richard. We can chat a bit on it at Devoxx
 
 Sven
 
 Am 19.10.2013 02:08 schrieb Richard Bair richard.b...@oracle.com:
  That's pretty much it.  VP6, T2K, deploy, FX JMX tooling.
 
 VP6 won't ever be opened because it is licensed 3rd party code. However it 
 isn't used that much anymore, most folks are using h.264. T2K I will come 
 back to. Deploy code (meaning, Applets) is not planned to be open sourced, 
 and I don't think it can be, unless JavaSE open sources all the applet / 
 webstart code. The JMX tooling code really doesn't work well (last I tried 
 it didn't work at all…). However I have big plans for JMX tooling in the 9 
 timeframe which might come to fruition (anybody out there interested in 
 live-debugging JavaFX let me know, I've got a project for you!). I don't now 
 that we should bother open sourcing the JMX tooling code vs. just replacing 
 it.
 
 Kevin, if it is easy to open it, lets just do it and use it as a starting 
 point.
 
 For T2K, I'm a little unclear and hope someone can help clear up for me 
 under what circumstances we use T2K in the shipping product. My current 
 understanding was that we use native fonts for every platform except maybe 
 embedded, but that we want to switch from T2K to native fonts (Pango or 
 HarfBuzz or whatnot) soon. Is that right?
 
 The JDK uses an open source font library for OpenJDK, but T2K for the Oracle 
 JDK. On FX we just wanted to have a single implementation that was used by 
 both. The hope is that besides Applet code and VP6, everything in the Oracle 
 JavaFX would be available in OpenJFX, so that JavaFX is truly an open source 
 project built on open source code.
 
 For you guys at RedHat, the answer is: everything is open source. Go forth, 
 build, and prosper :-). I read on twitter Miho succeeded in a build of 
 OpenJFX based on OpenJDK. I think the doors are open for business. Other 
 than we still need the mercurial server moved from version .9 to something 
 modern so that we can have outside committers commit to the repo directly, 
 whereas right now it would require gate repos. Sadness. But if it takes a 
 Gate repo we'll use a darn gate repo so that we can be a real open source 
 project.
 
 Richard

Re: Media is now opensource

[Richard Bair]

We don't support it, and frankly there hasn't been any demand. I think along it 
easier to plug in codecs and letting developers do this (vs having built in 
support) is the way to go because shipping codecs with the platform (not app) 
is fraught with legal headaches.

 On Oct 18, 2013, at 5:29 PM, Felix Bembrick felix.bembr...@gmail.com wrote:
 
 Does JavaFX support VP8 and, if not, when will it support it?
 
 
 On 19 October 2013 11:16, Richard Bair richard.b...@oracle.com wrote:
  Is the fact that the VP6 decoder is not included because of a legal issue?
 
 Yes, we don't own the code (Google does!) so we can't release it. Google has 
 opened VP8, the successor to VP6, but not VP6.
 
 Richard
 

Re: Media is now opensource

[Richard Bair]

That sounds right to me.

On Oct 18, 2013, at 11:53 AM, Scott Palmer swpal...@gmail.com wrote:

 I propose the codecs be made pluggable.  The licensing issue can be left to 
 the application developer.
 
 https://javafx-jira.kenai.com/browse/RT-2684
 
 Once that is in place, support for whatever codec you wish can be added. 
 FFMPEG could be used as an example.
 I'm against adding any new codecs without first putting in a user-extensible 
 codec mechanism that does not require modifying JavaFX to support new 
 formats.  I.e. make the dog food first, then eat it.
 
 Scott
 
 On 2013-10-18, at 2:03 PM, Kirill Kirichenko kirill.kiriche...@oracle.com 
 wrote:
 
 Media is very regulated area in legal terms. Using different codecs may 
 involve using and even violating some license agreements.
 Anyway you're welcome to propose anything.
 
 
 On 18.10.2013 21:37, Robert Krüger wrote:
 Great news!
 
 Does this mean that it is now possible to add support for more
 demuxers/decoders e.g. by utilizing stuff from other projects (ffmpeg
 comes to mind)?
 
 On Fri, Oct 18, 2013 at 6:35 PM, Kirill Kirichenko
 kirill.kiriche...@oracle.com wrote:
 Hello OpenJFXers !
 We're happy to announce that Media part of JavaFX is now open source.
 Opensourcing touched all Media component except ON2 FLV demuxer and VP6
 decoder. The decoder will remain closed.
 
 You're all welcome to contribute.
 
 Thanks,
 K
 

Re: Media is now opensource

[Richard Bair]

 That's pretty much it.  VP6, T2K, deploy, FX JMX tooling.

VP6 won't ever be opened because it is licensed 3rd party code. However it 
isn't used that much anymore, most folks are using h.264. T2K I will come back 
to. Deploy code (meaning, Applets) is not planned to be open sourced, and I 
don't think it can be, unless JavaSE open sources all the applet / webstart 
code. The JMX tooling code really doesn't work well (last I tried it didn't 
work at all…). However I have big plans for JMX tooling in the 9 timeframe 
which might come to fruition (anybody out there interested in live-debugging 
JavaFX let me know, I've got a project for you!). I don't now that we should 
bother open sourcing the JMX tooling code vs. just replacing it.

Kevin, if it is easy to open it, lets just do it and use it as a starting point.

For T2K, I'm a little unclear and hope someone can help clear up for me under 
what circumstances we use T2K in the shipping product. My current understanding 
was that we use native fonts for every platform except maybe embedded, but that 
we want to switch from T2K to native fonts (Pango or HarfBuzz or whatnot) soon. 
Is that right?

The JDK uses an open source font library for OpenJDK, but T2K for the Oracle 
JDK. On FX we just wanted to have a single implementation that was used by 
both. The hope is that besides Applet code and VP6, everything in the Oracle 
JavaFX would be available in OpenJFX, so that JavaFX is truly an open source 
project built on open source code.

For you guys at RedHat, the answer is: everything is open source. Go forth, 
build, and prosper :-). I read on twitter Miho succeeded in a build of OpenJFX 
based on OpenJDK. I think the doors are open for business. Other than we still 
need the mercurial server moved from version .9 to something modern so that we 
can have outside committers commit to the repo directly, whereas right now it 
would require gate repos. Sadness. But if it takes a Gate repo we'll use a darn 
gate repo so that we can be a real open source project.

Richard

Re: Media is now opensource

[Richard Bair]

 Is the fact that the VP6 decoder is not included because of a legal issue?

Yes, we don't own the code (Google does!) so we can't release it. Google has 
opened VP8, the successor to VP6, but not VP6.

Richard

Re: Constructor annotation

[Richard Bair]

+1 this is my preference. It is useful for things other than FXML, and should 
be considered part of our javafx.beans API.

 On Oct 16, 2013, at 4:20 AM, Tom Schindl tom.schi...@bestsolution.at wrote:
 
 On 16.10.13 11:22, Eva Krejcirova wrote:
 Hi All,
 
 when we retired builders, we caused a problem for FXML which doesn't
 have a way to create classes without default constructors. Back then we
 decided to use an annotation for this but never actually got to
 implement it and we need to fix this for FX8. I am in the process of
 adding this functionality to FXMLLoader but we need to decide how the
 annotation will look like and I could use some help with this.
 
 We cannot use already existing ConstructorProperties for this, because
 it's java.beans package and we don't want to create to dependency on
 this package in JavaFX, so we need to introduce a new annotation.
 
 We have two options:
 
 1. Annotate the whole constructor:
 e.g.
@ConstructorArguments({a, b, list})
public ImmutableClass(int a, int b, Integer... list)
 
 2. Annotate the arguments:
 e.g.
public ImmutableClass(@FXMLArgument(a) int a,
 @FXMLArgument(b)int b, @FXMLArgument(list)Integer... list)
 
 
 Which option do you like more and how should the annotation be named?
 
 Option 2, but does it really have to hold FXML in the annotation name?
 Where would you put the annotation? I think it should NOT be in the
 FXML-Package-Namespace because the core should NOT depend on FXML!
 
 I'd go with @Argument or simply @NamedArgument (@Named is already used
 by javax.inject)
 
 Tom

Re: Half-baked API (Camera position)

[Richard Bair]

My quick vote would be throwing the exception, but is like to hear from Steve 
and Kevin. 

 On Oct 16, 2013, at 1:04 AM, Pavel Safrata pavel.safr...@oracle.com wrote:
 
 Hello,
 it looks like we can't help releasing a not-fully-baked piece of API with 
 FX8. We've added bunch of new APIs for 3D and did our best to make them work 
 well. Unfortunately, there's been not enough timepriority to fine-tune their 
 behavior in 2D world. Right now I'm concerned about camera position in scene. 
 It is inherent in the 3D perspective camera that it has its specific position 
 in world, but the 2D parallel camera as we have it projects everything to the 
 XY plane basically by ignoring the Z coordinate, so the camera position 
 doesn't matter all that much. However, some of the newly added APIs depend on 
 it:
 
 1. Near/far clip on camera. This obviously cannot work without knowing where 
 the camera is. Right now the parallel camera does no clipping though, so I 
 guess we are OK to go with it as a known limitation.
 
 2. PickResult on events which reports intersectedDistance between the 
 camera and the picked point. This is worse because we can't just not 
 support it - there will be some value and once somebody uses it we'll have a 
 backward compatibility issue. The state right now is that the camera is 
 (tentatively, by my arbitrary decision) at [0, 0, -1] and reports distances 
 from there (note that as the camera renders everything, for nodes in front 
 of Z=-1 it reports negative distances). This may change when the camera 
 position is properly discussed and specified.
 
 Note that this post is *not* meant to discuss the camera position. Even if we 
 could find the answer quickly (which I doubt), it's most probably too late to 
 apply the change for FX8.
 
 So finally here is my question: do you think it's OK to solve this by keeping 
 the current behavior and documenting the intersectedDistance in a way that 
 for parallel camera the numbers are unspecified and subject to change in 
 future versions? Or would you prefer something more drastic like throwing an 
 UnsupportedOperationException (losing the possibility to compare the 
 distances)?
 
 Thanks,
 Pavel

Re: Problem with Timeline keeping references around

[Richard Bair]

I saw some fix go flying by this morning, check the changelog on graphics and 
see if there is a fix.

Cheers
Richard

Re: Constructor annotation

[Richard Bair]

Looks good to me.

 On Oct 16, 2013, at 10:02 AM, Stephen F Northover 
 steve.x.northo...@oracle.com wrote:
 
 It seems we are settling on @NamedArgument ... anybody disagree strongly?
 
 Steve
 
 On 2013-10-16 11:45 AM, Richard Bair wrote:
 Ya that works too.
 
 On Oct 16, 2013, at 8:41 AM, Eva Krejcirova eva.krejcir...@oracle.com 
 wrote:
 
 Good point!
 In FX sources, we already use the @Default annotation which was used by 
 annotation processor when generating the builders. Because of this, it has 
 source retention policy, so it cannot be used by FXMLLoader. I was thinking 
 about promoting this to runtime annotation but maybe your solution is 
 better.
 
 We should solve this for FX8 otherwise the FXMLLoader will behave 
 differently from how the generated builders behaved.
 
 Eva
 
 On 16.10.2013 17:24, Tom Schindl wrote:
 One thing that just came to my mind is that maybe also need a way to
 define the default value to be used, with a builder I could e.g. define
 that the default for fields are different from their real native default.
 
 class MyBuilder {
   private boolean a = true;
   private int x = -1;
   private Insets i = new Insets(10);
 }
 
 If we want to have a full replacement for builders the annotation must
 have the possibility define this (in future).
 
 public @interface NamedArgument {
   String value();
   String defaultValue();
   ClassConverter converterClass();
 }
 
 If no converterClass is given we'd have to do our best to auto-convert
 the String. I don't want to say that we should implement the default
 value definition in FX8 but it would feel more natural with an
 annotation per argument.
 
 Tom
 
 On 16.10.13 17:12, Tom Schindl wrote:
 To me the JavaBean solution with one annotation looks error prone, does
 anybody know why they did not use an annotation per field?
 
 Tom
 
 On 16.10.13 16:58, Stephen F Northover wrote:
 +1 for base.  Should we not follow closely what Java Beans is doing for
 consistency?  I realize that we can't have the reference.
 
 Steve
 
 On 2013-10-16 10:53 AM, Kevin Rushforth wrote:
 Not to mention Tom's point that it can't be in the fxml module without
 created unwanted (and circular) module dependencies. Seems like it
 needs to be in the base module then, right?
 
 -- Kevin
 
 
 Richard Bair wrote:
 +1 this is my preference. It is useful for things other than FXML,
 and should be considered part of our javafx.beans API.
 
 On Oct 16, 2013, at 4:20 AM, Tom Schindl
 tom.schi...@bestsolution.at wrote:
 
 On 16.10.13 11:22, Eva Krejcirova wrote:
 Hi All,
 
 when we retired builders, we caused a problem for FXML which doesn't
 have a way to create classes without default constructors. Back
 then we
 decided to use an annotation for this but never actually got to
 implement it and we need to fix this for FX8. I am in the process of
 adding this functionality to FXMLLoader but we need to decide how the
 annotation will look like and I could use some help with this.
 
 We cannot use already existing ConstructorProperties for this, 
 because
 it's java.beans package and we don't want to create to dependency on
 this package in JavaFX, so we need to introduce a new annotation.
 
 We have two options:
 
 1. Annotate the whole constructor:
 e.g.
@ConstructorArguments({a, b, list})
public ImmutableClass(int a, int b, Integer... list)
 
 2. Annotate the arguments:
 e.g.
public ImmutableClass(@FXMLArgument(a) int a,
 @FXMLArgument(b)int b, @FXMLArgument(list)Integer... list)
 
 
 Which option do you like more and how should the annotation be named?
 Option 2, but does it really have to hold FXML in the annotation name?
 Where would you put the annotation? I think it should NOT be in the
 FXML-Package-Namespace because the core should NOT depend on FXML!
 
 I'd go with @Argument or simply @NamedArgument (@Named is already used
 by javax.inject)
 
 Tom
 

Re: Constructor annotation

[Richard Bair]

NamedArg, like a pirate :-)

 On Oct 16, 2013, at 10:27 AM, Stephen F Northover 
 steve.x.northo...@oracle.com wrote:
 
 Eva,
 
 Perhaps @NamedArg is shorter and makes the code more readable?
 
 If you don't have a JIRA already, please create one and paste in this 
 discussion.  Interested parties can add themselves to the watchers list.
 
 Steve
 
 On 2013-10-16 1:25 PM, Richard Bair wrote:
 Looks good to me.
 
 On Oct 16, 2013, at 10:02 AM, Stephen F Northover 
 steve.x.northo...@oracle.com wrote:
 
 It seems we are settling on @NamedArgument ... anybody disagree strongly?
 
 Steve
 
 On 2013-10-16 11:45 AM, Richard Bair wrote:
 Ya that works too.
 
 On Oct 16, 2013, at 8:41 AM, Eva Krejcirova eva.krejcir...@oracle.com 
 wrote:
 
 Good point!
 In FX sources, we already use the @Default annotation which was used by 
 annotation processor when generating the builders. Because of this, it 
 has source retention policy, so it cannot be used by FXMLLoader. I was 
 thinking about promoting this to runtime annotation but maybe your 
 solution is better.
 
 We should solve this for FX8 otherwise the FXMLLoader will behave 
 differently from how the generated builders behaved.
 
 Eva
 
 On 16.10.2013 17:24, Tom Schindl wrote:
 One thing that just came to my mind is that maybe also need a way to
 define the default value to be used, with a builder I could e.g. define
 that the default for fields are different from their real native default.
 
 class MyBuilder {
   private boolean a = true;
   private int x = -1;
   private Insets i = new Insets(10);
 }
 
 If we want to have a full replacement for builders the annotation must
 have the possibility define this (in future).
 
 public @interface NamedArgument {
   String value();
   String defaultValue();
   ClassConverter converterClass();
 }
 
 If no converterClass is given we'd have to do our best to auto-convert
 the String. I don't want to say that we should implement the default
 value definition in FX8 but it would feel more natural with an
 annotation per argument.
 
 Tom
 
 On 16.10.13 17:12, Tom Schindl wrote:
 To me the JavaBean solution with one annotation looks error prone, does
 anybody know why they did not use an annotation per field?
 
 Tom
 
 On 16.10.13 16:58, Stephen F Northover wrote:
 +1 for base.  Should we not follow closely what Java Beans is doing for
 consistency?  I realize that we can't have the reference.
 
 Steve
 
 On 2013-10-16 10:53 AM, Kevin Rushforth wrote:
 Not to mention Tom's point that it can't be in the fxml module without
 created unwanted (and circular) module dependencies. Seems like it
 needs to be in the base module then, right?
 
 -- Kevin
 
 
 Richard Bair wrote:
 +1 this is my preference. It is useful for things other than FXML,
 and should be considered part of our javafx.beans API.
 
 On Oct 16, 2013, at 4:20 AM, Tom Schindl
 tom.schi...@bestsolution.at wrote:
 
 On 16.10.13 11:22, Eva Krejcirova wrote:
 Hi All,
 
 when we retired builders, we caused a problem for FXML which 
 doesn't
 have a way to create classes without default constructors. Back
 then we
 decided to use an annotation for this but never actually got to
 implement it and we need to fix this for FX8. I am in the process 
 of
 adding this functionality to FXMLLoader but we need to decide how 
 the
 annotation will look like and I could use some help with this.
 
 We cannot use already existing ConstructorProperties for this, 
 because
 it's java.beans package and we don't want to create to dependency 
 on
 this package in JavaFX, so we need to introduce a new annotation.
 
 We have two options:
 
 1. Annotate the whole constructor:
 e.g.
@ConstructorArguments({a, b, list})
public ImmutableClass(int a, int b, Integer... list)
 
 2. Annotate the arguments:
 e.g.
public ImmutableClass(@FXMLArgument(a) int a,
 @FXMLArgument(b)int b, @FXMLArgument(list)Integer... list)
 
 
 Which option do you like more and how should the annotation be 
 named?
 Option 2, but does it really have to hold FXML in the annotation 
 name?
 Where would you put the annotation? I think it should NOT be in the
 FXML-Package-Namespace because the core should NOT depend on FXML!
 
 I'd go with @Argument or simply @NamedArgument (@Named is already 
 used
 by javax.inject)
 
 Tom
 

Re: Half-baked API (Camera position)

[Richard Bair]

I don't see how returning something wrong is any different than throwing an 
exception from a compatibility perspective. Bugs are bugs.

On Oct 16, 2013, at 3:46 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote:

 I can see your point. There are cases where it can make sense to have a 
 restriction now and relax it later, but this isn't exactly that case. It's 
 really more of a case of not being currently implemented correctly in some 
 modes.
 
 I guess the other option (which Pavel also mentioned) is to continue to 
 return something plausible, but not really correct, and file it as a bug 
 against FX 8.
 
 -- Kevin
 
 
 Stephen F Northover wrote:
 Initial position:
 
 I don't really want to see any exception.  Throwing an exception is 
 unexpected and should really be reserved for when something bad happens, not 
 when we can't decide how an API works.  If the exception goes in, it's API 
 and it stays forever.
 
 Steve
 
 On 2013-10-16 5:23 PM, Kevin Rushforth wrote:
 Steve: if Pavel throws IllegalStateException(not yet supported for 
 parallel camera) or similar, do you think that would be OK or do you not 
 want to see any exception?
 
 -- Kevin
 
 
 Kevin Rushforth wrote:
 Would IllegalStateException be better here? Usually UOE is for operations 
 that are simply not supported by the class in question. In this case, the 
 operation is only unsupported if the camera on the scene (i.e., the state 
 of an object) is of a certain type which can change at runtime.
 
 I'm OK either way, just want it to be a deliberate decision.
 
 -- Kevin
 
 
 Pavel Safrata wrote:
 As I've said, we intend to fix it in the future, so the situation should 
 not be impossible. It is mostly used that way in the existing code, but 
 there definitely are precedents for throwing it just temporarily. For 
 instance:
 
 nodeOrientationProperty().getCssMetaData:
throw new UnsupportedOperationException(Not supported yet.);
 
 or
 
 MeshView.impl_computeContains():
throw new UnsupportedOperationException(Not supported yet.);
 (internal but directly accessible to users via contains())
 
 Pavel
 
 On 16.10.2013 20:10, Stephen F Northover wrote:
 I took a quick look through JavaFX to find how this exception is used. 
 It is mostly used to indicate impossible situation.  Is that the 
 situation we have here?
 
 Personally, for me, if we throw the exception, then we will generally 
 just leave it that way forever.
 
 Steve
 
 On 2013-10-16 11:22 AM, Pavel Safrata wrote:
 On 16.10.2013 17:03, Stephen F Northover wrote:
 Could do something useful with what was there now?  We can always fix 
 this in future by adding another API to govern the interpretation of 
 the value.
 
 Not much useful. Anyway, any such stuff can be quite easily done by 
 reading the intersectedPoint's Z coordinate.
 
 
 Throwing the exception indicates that the call is unsupported, but 
 application code can be written to catch the exception and when we 
 implement the API, it can break (I realize that this is unlikely).
 
 The exception can tell by the message that the operation will be 
 supported in the future.
 
 Pavel
 
 
 Steve
 
 On 2013-10-16 10:46 AM, Richard Bair wrote:
 My quick vote would be throwing the exception, but is like to hear 
 from Steve and Kevin.
 
 On Oct 16, 2013, at 1:04 AM, Pavel Safrata 
 pavel.safr...@oracle.com wrote:
 
 Hello,
 it looks like we can't help releasing a not-fully-baked piece of API 
 with FX8. We've added bunch of new APIs for 3D and did our best to 
 make them work well. Unfortunately, there's been not enough 
 timepriority to fine-tune their behavior in 2D world. Right now I'm 
 concerned about camera position in scene. It is inherent in the 3D 
 perspective camera that it has its specific position in world, but 
 the 2D parallel camera as we have it projects everything to the XY 
 plane basically by ignoring the Z coordinate, so the camera position 
 doesn't matter all that much. However, some of the newly added APIs 
 depend on it:
 
 1. Near/far clip on camera. This obviously cannot work without 
 knowing where the camera is. Right now the parallel camera does no 
 clipping though, so I guess we are OK to go with it as a known 
 limitation.
 
 2. PickResult on events which reports intersectedDistance between 
 the camera and the picked point. This is worse because we can't just 
 not support it - there will be some value and once somebody uses 
 it we'll have a backward compatibility issue. The state right now is 
 that the camera is (tentatively, by my arbitrary decision) at [0, 0, 
 -1] and reports distances from there (note that as the camera 
 renders everything, for nodes in front of Z=-1 it reports negative 
 distances). This may change when the camera position is properly 
 discussed and specified.
 
 Note that this post is *not* meant to discuss the camera position. 
 Even if we could find the answer quickly (which I doubt), it's most 
 probably too late to apply the change for FX8

Re: JAVAFX on ANDROID

[Richard Bair]

Hi Matthias,

 The main point of irritation comes from an quite unclear position about 
 providing the JVM and JFX of the Java-platform. 
 That's why I will sumarize what I heard between the lines:
 
 1. there is NO official jvm planned for iOS and Android in the near future.
 2. jfx8 is beeing officially maintained until some point for iOS and Android 
 but the actual port is left to the open source community.
 3. Linux ARM support is beeing focused officially on the Freescale 
 ARM-platform.

That is right.

 our conclusion is:
 1. that's not that bad anymore since we have RoboVM for iOS and Davlik on 
 Android.
 2. this statement should have been made 1 year ago. Probably, I missed it but 
 it was not clear to my team as well until last week.
   That's why we took the challenge to do it our selves.

You rock :-)

 3. This is good for the open source development since we probably can rely on 
 the CPU optimized parts for ARM.

This exactly. All the work we do for embedded translates directly to iOS and 
android, since it is the same hardware and graphics chips.

Cheers
Richard

Re: JAVAFX on ANDROID

[Richard Bair]

As frustrating as it is, the fact is that today Oracle has no announced plans 
to release any official JVM for Android and iOS. That being the case, the 
biggest hurdle to getting FX on iOS and Android is the VM. On the iOS side 
there has been some success with RoboVM. On Android you can just use Dalvik if 
you back port to Java 6, or you have to find another VM (XMLVM maybe?? Anybody 
convince Excelsior to support Android?) that can do the job.

There are two parts the problem of a VM. One is the VM technology itself, 
which is probably the lesser of the two issues because there are a handful of 
decent VMs around (if you include Dalvik, you've already got one on Android). 
The second problem are the class libraries. Generally JavaFX doesn't rely on 
too much from JavaSE beyond what is in the base module; threading and 
collections and concurrency and so forth. However we are using the diamond 
operator and in a few places we might use multi-catch (although I don't know of 
such places myself) and definitely we use default methods in interfaces in one 
location (ObservableList). Generally we've tried to make it easy to back port 
to 7, but haven't tried to keep 6 up to date. I would be very interested in the 
list of code changes Matthias had to make to better understand the situation.

As far as fonts (from Matthias' email) I believe the Android port currently 
uses T2K but Felipe and Tomas were talking about using the new Font support 
which would delegate directly to Android APIs. This might be one area that 
Matthias' and Felipe and Tomas can work closely on to get a contribution to 
make this happen!

 How much time do you think it would take community designers to develop this?

RoboVM for iOS I think is basically at this stage, where they've got something 
up and running to the point of being able to do performance analysis and 
looking for bugs. It has been a several month process with stops and starts. 
Tom and the others working on RoboVM might be able to give a better estimate.

 Does it support swing and javafx or just javafx like the Pi port? What parts 
 of java8 don't work on your standalone VM?

I couldn't tell you what does / doesn't work on the standalone VM as that would 
break all kinds of confidential legal mumbo-jumbo. But I can tell you I've 
never seen a port of AWT to iOS or Android.

Richard

 -Original Message-
 From: Tomas Brandalik tomas.branda...@oracle.com
 Sender: openjfx-dev-boun...@openjdk.java.net
 Date: Fri, 11 Oct 2013 06:52:06 
 To: openjfx-dev@openjdk.java.net
 Subject: Re: JAVAFX on ANDROID
 
 COMPILE_TARGETS=android
 Good, then use FX78 and you can give it a try. I have my local fork of 
 javafx for testing DalvikLauncher. Standalone Vm for Android is not 
 available for download.
 
 -Tomas
 
 FX78 should be compatible with Java6 because RoboVM is built on dalvik
 classlib and JavaFX works there!
 
 Tom
 
 On 10.10.13 22:42, Tobi wrote:
 Hi Tomas,
 
 How did you test the Dalviklauncher? Do you have a Java6 compatible jFX 
 version?
 
 And how did you test the JavaSELauncher? Do you have a JVM for android? 
 Where can we download it?
 
 Am 10.10.2013 um 22:01 schrieb Tomas Brandaliktomas.branda...@oracle.com:
 
 Hi Tobi and Philippe,
 Android port is being developed in open source so all developers can see 
 every progress. There is nothing to hide. You can understand it as an 
 example of porting javafx runtime to a linux based platform not a product 
 with a roadmap.
 As you've noticed there are 2 launchers DalvikLauncher and JavaSELauncher. 
 Have a look at DalvikLauncher it is quite simple how it launches an 
 application. What you need to try it out is an java6 (dalvik vm 
 limitation)  compatible javafx fork.
 On the other hand JavaSELauncher uses standalone vm which is not part of 
 the port. It expects that the vm is packaged with an apk. The launcher 
 unpacks vm, installs it, setup classpath, main class debug port etc (all 
 specified in manifest) and launches it . These are the 2 options which can 
 be further extended by the community.
 
 best regards
 -Tomas
 
 On 10/10/2013 06:10 PM, Tobias Bley wrote:
 Tomas from Oracle is working on the Android port of JavaFX. He has 
 developed a DalvikLauncher and a JavaSELauncher. So he is able to tell 
 you (and me :)) more about that important theme „JavaFX on Android“.
 
 Best regards,
 Tobi
 
 
 Am 10.10.2013 um 16:55 schrieb Philippe 
 TIFFEAUphilippe.tiff...@steria.com:
 
 Hello,
 
 Someone can make a clear answer about JavaFX on ANDROID ?
 
 If it works how to use ? Otherwise the roadmap is 
 
 Best Regard.
 
 This email and any attachments may contain confidential information and 
 intellectual property (including copyright material). It is only for the 
 use of the addressee(s) in accordance with any instructions contained 
 within it. If you are not the addressee, you are prohibited from 
 copying, forwarding, disclosing, saving or otherwise using it in any 
 way. If you receive this email 

Re: Keyboard events

[Richard Bair]

That being said, this seems like a very common use case, and I wonder if there 
is something more we could do (in the longer term, short term do as Artem 
suggests)

 On Oct 7, 2013, at 3:56 AM, Artem Ananiev artem.anan...@oracle.com wrote:
 
 
 On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote:
 Hi,
 
 I have the following use case:
 When the user presses shift and the mouse is hover the chart component the
 cursor must change to an open hand cursor signaling to the user that the
 chart is ready for a panning action.
 The problem is that for this to be possible I want the chart to be able to
 listen to keyboard events even when it doesn't have focus.
 
 I think this is not possible and I wonder why. Swing was the same, you
 could only listen to keyboard events if the control had focus. Is this a
 technical limitation? If there is no technical limitation I think it would
 be better to remove this restriction, I think it is limiting and the above
 scenario is a good use case to show that.
 
 This is not a technical limitation, it's just the way how it's supposed to 
 work. All the key events are dispatched to the component in focus, this is 
 what input focus is.
 
 Scenario you described should be easier to implement in FX than in Swing. In 
 AWT/Swing, input events are dispatched to a single component, while FX is 
 much more flexible. All the events are delivered to a Scene first, then 
 dispatched to the focused component (or component under mouse, for mouse 
 events), then bubbled up back to the Scene. What you need is to register a 
 custom event filter for the scene and listen to all the key events.
 
 See Scene.addEventFilter() and Scene.addEventHandler() for details.
 
 Thanks,
 
 Artem
 
 Thanks, best regards,
 

Re: Lambdafication (was Re: Default methods in JFX-8)

[Richard Bair]

 diamonds?
 
 Will now try to apply all those changes and figure out if this still
 builds... up next: go through the other modules...
 
 -Sven
 
 
 On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair richard.b...@oracle.com
 richard.b...@oracle.comwrote:
 
 
 
 Brian was telling me at J1 that whether parallel gets you performance
 or
 not depends on the size of the collection and the complexity of the
 work to
 perform. There is definitely a point at which parallel helps -- and a
 point
 at which it hurts.
 
 Richard
 
 On Oct 3, 2013, at 3:33 PM, Hervé Girod herve.gi...@gmail.com 
 herve.gi...@gmail.com wrote:
 
 
 
 Here is a nice example, taking advantage of the ease of going
 
 
 parallel. Apparently the performance without parallel will also further
 improve.
 http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/
 
 Hervé
 
 Sent from my iPad
 
 
 
 On 4 oct. 2013, at 00:20, David Grieve david.gri...@oracle.com 
 david.gri...@oracle.com
 
 wrote:
 
 
 And what about Stream? I like the declarative code that comes from
 
 
 using Stream and I can see places in the code where Stream could be
 used,
 but I wonder about its performance relative to iterators and/or enhanced
 for loops.
 
 
 On Oct 3, 2013, at 4:45 PM, Richard Bair richard.b...@oracle.com 
 richard.b...@oracle.com
 
 wrote:
 
 
  Hello, OpenJFX Community.
 
 There's a question about using Java 8 features in FX.
 
 I've been working on the support for InputMethods in JFXPanel which
 
 
  is an important feature for many users who speak hieroglyphic
 languages.
 
 
  The issue is tracked under:
 
 
  https://javafx-jira.kenai.com/browse/RT-13248
 
  In order to have a high-quality support we need to change
 
 
  javafx.scene.input.InputMethodRequests interface and introduce 3 new
 methods. This is not needed for pure FX applications right now, but
 absolutely required for InputMethods in the JFXPanel. However, the
 interface is public and it was present since FX2.0, so changing it would
 become a breaking change. So the only way to avoid the problem is using
 the
 default methods. Those would return some stub values, the JDK is OK with
 that, as it would not crash or throw exceptions, but text composition
 would
 not work correctly.
 
 
  I know that we want to avoid using the Java 8 features in the
 
 
  JFX-8, so I wanted to ask - is it OK to use the default methods here?
 
 
  If you are staying away from JDK8 features for the JFX78 backport,
 
 
  don't worry.  There are more issues with new JDK8 APIs than with the
 new
 language features.
 
 
  For example there were default methods put into some collections
 
 
  classes that we solved by pushing them down to the first implements.
 But
 the Date and Time picker depends on the new time package.  The threeten
 backport won't be updated until after 8 ships, so that has been removed
 so
 far.
 
 
  I'de be interested to know what a wholesale lamdaization would
 
 
  result in speed wise and code size wise (both source and compiled).
 From
 what I can tell the IDEs can lambda and de-lambda fairly easily, so it
 jsut
 makes the backport more of a busy work proposition.  If there were
 performance gains it would also make a great front page story in the
 next
 java magazine or a case study..
 
 
  After having used Lambda's for JavaOne, I'd love to make the
 
 
  conversion, even if in the end the performance was the same, because
 the
 savings in noise in the Java files is so big. At one time I just took
 the
 concurrent classes and lambda-ized them to measure the impact on those
 classes. You could maybe pick a package and just lambda-ize that one
 package and see what happens in terms of size reduction. We might see:
 
 
   + A reduction in the overall class size (not pack-200'd)
 - An increase in startup time (have to spin up synthetic classes
 
 
  created at usage time)
 
 
   +/- And increase or decrease in performance
 + A decrease in source code
 
 It would be interesting to get some data for these points and see
 
 
  what effect lambda's have. Especially if an IDE can just do it in
 bulk…
 
 
  Richard
 
 
   --
 Sven Reimers
 
 * Senior Expert Software Architect
 * NetBeans Dream Team Member: http://dreamteam.netbeans.org
 * Community Leader  NetBeans: http://community.java.net/netbeans
  Desktop Java:
 http://community.java.net/javadesktop
 * Duke's Choice Award Winner 2009
 * Blog: http://nbguru.blogspot.com
 
 * XING: https://www.xing.com/profile/Sven_Reimers8
 * LinkedIn: http://www.linkedin.com/in/svenreimers
 
 Join the NetBeans Groups:
 * XING: http://www.xing.com/group-20148.82db20
 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home
 * LinkedIn: http://www.linkedin.com/groups?gid=1860468
   http://www.linkedin.com/groups?gid=107402
   http://www.linkedin.com/groups?gid=1684717
 * Oracle: https://mix.oracle.com/groups/18497
 
 
 --
 Sven Reimers
 
 * Senior Expert Software Architect

Re: Building on Mac with latest Xcode

[Richard Bair]

I just ran into this as well. Instead of editing mac.gradle, you should copy 
gradle.properties.template to gradle.properties, and add 

MACOSX_MIN_VERSION=10.8

There should be a more robust way for mac.gradle to find the right version if 
the old one isn't available.

Richard

On Oct 7, 2013, at 1:15 PM, Sven Reimers sven.reim...@gmail.com wrote:

 Hi,
 
 since I had to once more reinstall my Mac short before Java One I lost a
 couple of updates, so I finally got the latest XCode installed, which does
 not include MacOSX 10.7 SDK.
 
 Fixing building is easy - just change minimum version in
 buildSrc/mac.gradle to 10.8 does the trick.
 
 So what is the official correct way to circumvent the problem?
 
 Seems the latest XCode version that shipped 10.7 SDK is 4.4 (if I get this
 correct from https://developer.apple.com/downloads/index.action?q=xcode
 
 Should deinstall the actual version and get back to 4.4?
 
 Any comments appreciated.
 
 Thanks
 
 -Sven
 
 -- 
 Sven Reimers
 
 * Senior Expert Software Architect
 * NetBeans Dream Team Member: http://dreamteam.netbeans.org
 * Community Leader  NetBeans: http://community.java.net/netbeans
  Desktop Java:
 http://community.java.net/javadesktop
 * Duke's Choice Award Winner 2009
 * Blog: http://nbguru.blogspot.com
 
 * XING: https://www.xing.com/profile/Sven_Reimers8
 * LinkedIn: http://www.linkedin.com/in/svenreimers
 
 Join the NetBeans Groups:
 * XING: http://www.xing.com/group-20148.82db20
 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home
 * LinkedIn: http://www.linkedin.com/groups?gid=1860468
   http://www.linkedin.com/groups?gid=107402
   http://www.linkedin.com/groups?gid=1684717
 * Oracle: https://mix.oracle.com/groups/18497

Re: bugfix mode

[Richard Bair]

This page http://openjdk.java.net/projects/jdk8/milestones has the actual dates 
for JDK 8. The only place where we have a waiver to deviate for JavaFX is that 
our ZBB and Rampdown phase 2 are both scheduled for December 4.

Richard

On Oct 4, 2013, at 7:24 AM, Tom Eugelink t...@tbee.org wrote:

 
 Ok, clear. Then it is time I start looking at the issues that are reported on 
 MigLayout and the CSS errors Im getting.
 
 Tom
 
 
 On 2013-10-04 16:03, Richard Bair wrote:
 We are presently in full-on bug fixing mode. After October 24 only major, 
 critical, and blocker bugs are being looked at, and December 4 is the last 
 day, with only show stopper bugs fixable past that date.
 
 So if you have bugs, by all means now is the time to file and fix. It might 
 already be too late to fix any additional minor or medium bugs unless they 
 come with a patch and test attached.
 
 Richard
 
 On Oct 3, 2013, at 9:55 PM, Tom Eugelink t...@tbee.org wrote:
 
 
 Dear JFX team,
 
 There are a number of issues in my open source projects with JFX8 that need 
 looking at, but I'm postponing that until JFX8 reaches a level of maturity 
 that will limit the risk on having to redo things, aka that JFX8 is going 
 into bugfix mode, prior to release. Are there any estimates on when that 
 phase will begin? I think I remember a recent mail with that topic.
 
 Regards,
 
 Tom
 
 
 
 

Re: Cylinder divisions and PerspectiveCamera fixedEyePosition should be mutable

[Richard Bair]

I would turn that around and say that unless there is a compelling reason for 
something to be immutable, it should be mutable. Mutability is important for 
tools as well as for FXML as well as for developers.

Immutable state is awesome for thread-safety or any type of concurrency. But 
these types of classes are not of that nature, they're UI only classes, and as 
such their state should be mutable (and like all mutable state in FX, the range 
of possible values should not be hindered by the evil unbind pattern).

Richard

On Oct 4, 2013, at 12:46 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote:

 Yes, that pretty much captures the thinking behind it.
 
 My thought is that there is no real reason that subdivisions need to be 
 immutable, although I wouldn't want to change it at this late date for FX 8 
 unless it is needed for FXML support.
 
 The fixedEyeAtCameraZero mode is not something I think should be mutable, 
 since the camera behaves fairly differently in each mode. Having said that, 
 there is no reason it couldn't be made mutable in a subsequent release if 
 there was a good reason to do so.
 
 -- Kevin
 
 
 Chien Yang wrote:
 We did discuss making divisions in the predefined 3D shapes mutable in 
 earlier meeting. However we decided against it since it is a heavy weight 
 operation as the supporting mesh will has to be regenerated. I believe the 
 constructor with the divisions argument will not have much use in the future 
 when we move away from mesh implementation of our predefined 3D shapes.
 
 The fixedEyeAtCameraZero flag in PerspectiveCamera is a setup flag to the 
 camera and once set it shouldn't be changed. The perspective projection 
 matrix is constructed differently depending on the flag. In the default 
 mode, JavaFX controls the eye to achieve a projection plane at Z=0 so that 
 simple adding of 3D shapes into a 2D scene looks intuitive. The other mode, 
 where eye is fixed a camera zero, is well suitable for movable camera in the 
 3d space.
 
 - Chien
 
 On 10/4/2013 9:28 AM, Richard Bair wrote:
 Why are they not? It isn't immediately obvious to me why these are not 
 mutable? I was reading https://javafx-jira.kenai.com/browse/RT-29577 and 
 this struck me as odd.
 
 Richard

Re: Enabling Glass thread checks

[Richard Bair]

I always disliked FX Application thread, which is why I don't use it. The FXAT 
or FAT are acronyms we ought to avoid. EDT was great for Swing because it was 
super short, but we don't want to reuse EDT because that would be confusing. 
Personally I tend to use FX Thread because it is clear that this is the thread 
for JavaFX (and as far as users of the toolkit goes, the only thread that 
matters). Oh well.


On Oct 4, 2013, at 12:38 PM, steve.x.northo...@oracle.com wrote:

 We are BAD.  It should really be FX Application Thread but the GUI, 
 event nature of the thread is critical to what it is. That's why the terms 
 keep getting added.
 
 Steve
 
 On 04/10/2013 3:36 PM, Richard Bair wrote:
 Ya, event thread, fx thread, ui thread, app thread, FX Application 
 thread --- they're all the same thing. It would be better if we settled on 
 one name.
 
 Richard
 
 On Oct 4, 2013, at 12:00 PM, steve.x.northo...@oracle.com wrote:
 
 It's the JavaFX Application Thread.  We tend to use the term event thread 
 and UI thread to indicate that the thread is a distinguished UI thread 
 that processes operating system events by running an event loop.
 
 Steve
 
 On 04/10/2013 2:45 PM, John Smith wrote:
 IllegalStateException(This operation is permitted on the event thread 
 only)
 What is the event thread?
 
 Current warnings about thread rule violations appear to be something like 
 below (from: 
 http://stackoverflow.com/questions/12182592/javafx-2-x-swing-not-on-fx-application-thread):
 
Exception in thread AWT-EventQueue-0 java.lang.IllegalStateException: 
 Not on FX application thread; currentThread = AWT-EventQueue-0
 
 It is very confusing if warnings about what thread you should be on might 
 use different names for what is perhaps the same thing.
 
 If I do System.out.println(Thread.currentThread().getName()); in a start() 
 method, I get:
 
   JavaFX Application Thread
 
 The JavaFX Architecture overview 
 (http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm#A1107438)
  only mentions these threads:
 
 JavaFX application thread: This is the primary thread used by JavaFX 
 application developers. Any live scene, which is a scene that is part of 
 a window, must be accessed from this thread. A scene graph can be created 
 and manipulated in a background thread, but when its root node is attached 
 to any live object in the scene, that scene graph must be accessed from 
 the JavaFX application thread. This enables developers to create complex 
 scene graphs on a background thread while keeping animations on 'live' 
 scenes smooth and fast. The JavaFX application thread is a different 
 thread from the Swing and AWT Event Dispatch Thread (EDT), so care must be 
 taken when embedding JavaFX code into Swing applications.
 
 Prism render thread: This thread handles the rendering separately from 
 the event dispatcher. It allows frame N to be rendered while frame N +1 is 
 being processed. This ability to perform concurrent processing is a big 
 advantage, especially on modern systems that have multiple processors. The 
 Prism render thread may also have multiple rasterization threads that help 
 off-load work that needs to be done in rendering.
 
 Media thread: This thread runs in the background and synchronizes the 
 latest frames through the scene graph by using the JavaFX application 
 thread.
 
 -Original Message-
 From: openjfx-dev-boun...@openjdk.java.net 
 [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Petr Pchelko
 Sent: Friday, October 04, 2013 1:40 AM
 To: OpenJFX list
 Subject: Enabling Glass thread checks
 
 Hello, OpenJFX.
 
 FX is a single threaded UI toolkit. Glass (the underlying native window 
 toolkit portability layer for FX) is being changed to ensure it is 
 accessed from the UI thread. You can follow progress in 
 https://javafx-jira.kenai.com/browse/RT-26891
 
 We are reenabling the Glass thread checks ones again. Previous attempts 
 failed, because we've been finding some threading issues, however now all 
 the threading issues have been fixed and we are in a good state to switch 
 on the checks again.
 
 The following exception would mean that you've hit a thread check: 
 IllegalStateException(This operation is permitted on the event thread 
 only).
 In that case please check your threading and if everything seems correct - 
 please contact the Glass team.
 
 Thank you.
 With best regards. Petr.
 

Re: Cylinder divisions and PerspectiveCamera fixedEyePosition should be mutable

[Richard Bair]

Depends on whether it is usable from SceneBuilder and FXML, and the following:
   - We must *not* expose a ReadOnly property for these properties (and I don't 
think we do)
   - The FXML changes must be backwards compatible (they should be but we need 
to verify)
   - The SceneBuilder can do something reasonable as is (not sure).

Richard

On Oct 4, 2013, at 1:08 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote:

 Certainly for divisions there is no reason to keep them immutable. For 
 fixedEyeAtCameraZero, I don't think the reasons for keeping it immutable are 
 compelling.
 
 Making either change in FX 8 is a different matter, though, given how late we 
 are. The implementation assumes immutability and we would need to change it, 
 implement it, test it, and then fix any bugs as a result. Seems like we could 
 add mutability in a subsequent release.
 
 -- Kevin
 
 
 Richard Bair wrote:
 
 I would turn that around and say that unless there is a compelling reason 
 for something to be immutable, it should be mutable. Mutability is important 
 for tools as well as for FXML as well as for developers.
 
 Immutable state is awesome for thread-safety or any type of concurrency. But 
 these types of classes are not of that nature, they're UI only classes, and 
 as such their state should be mutable (and like all mutable state in FX, the 
 range of possible values should not be hindered by the evil unbind 
 pattern).
 
 Richard
 
 On Oct 4, 2013, at 12:46 PM, Kevin Rushforth kevin.rushfo...@oracle.com 
 wrote:
 
   
 Yes, that pretty much captures the thinking behind it.
 
 My thought is that there is no real reason that subdivisions need to be 
 immutable, although I wouldn't want to change it at this late date for FX 8 
 unless it is needed for FXML support.
 
 The fixedEyeAtCameraZero mode is not something I think should be mutable, 
 since the camera behaves fairly differently in each mode. Having said that, 
 there is no reason it couldn't be made mutable in a subsequent release if 
 there was a good reason to do so.
 
 -- Kevin
 
 
 Chien Yang wrote:
 
 We did discuss making divisions in the predefined 3D shapes mutable in 
 earlier meeting. However we decided against it since it is a heavy weight 
 operation as the supporting mesh will has to be regenerated. I believe the 
 constructor with the divisions argument will not have much use in the 
 future when we move away from mesh implementation of our predefined 3D 
 shapes.
 
 The fixedEyeAtCameraZero flag in PerspectiveCamera is a setup flag to the 
 camera and once set it shouldn't be changed. The perspective projection 
 matrix is constructed differently depending on the flag. In the default 
 mode, JavaFX controls the eye to achieve a projection plane at Z=0 so that 
 simple adding of 3D shapes into a 2D scene looks intuitive. The other 
 mode, where eye is fixed a camera zero, is well suitable for movable 
 camera in the 3d space.
 
 - Chien
 
 On 10/4/2013 9:28 AM, Richard Bair wrote:
   
 Why are they not? It isn't immediately obvious to me why these are not 
 mutable? I was reading https://javafx-jira.kenai.com/browse/RT-29577 and 
 this struck me as odd.
 
 Richard
 
 
   

Re: FXMLLoader templates

[Richard Bair]

After reviewing the situation with Martin my feeling was that this API is just 
not ready for prime-time. In fact, I'd like to think of how FXML fits in from a 
more holistic perspective, meaning, it might be time to consider a different 
approach to loading FXML files than the way FXMLLoader was designed to be used. 
I've never had that settled feeling about FXMLLoader (whereas most of the 
functionality in FXML itself I've been quite pleased with). And as Tom 
mentioned, there is now a much faster alternative anyway (it just won't work as 
well for dynamically loaded FXML, unless you do the compilation step locally).

Richard

On Oct 1, 2013, at 12:15 AM, Martin Sladecek martin.slade...@oracle.com wrote:

 After discussion with Richard, we decided to remove the template flag from 
 FXMLLoader for 8.0.
 This API is not mature yet, due to the reasons described below and should be 
 completely re-designed for some next release.
 
 This means that loading the same fxml multiple times will still require 
 multiple FXMLLoader instances.
 
 Any comments?
 
 Thanks,
 -Martin
 
 On 09/20/2013 02:22 PM, Martin Sladecek wrote:
 Hi,
 I would like to discuss a 8.0 feature of FXMLLoader - the template flag.
 I was introduced with this issue: 
 https://javafx-jira.kenai.com/browse/RT-23413, but unfortunately, it never 
 worked: https://javafx-jira.kenai.com/browse/RT-28121. I was trying to fix 
 the issue, but the whole concept of a flag for loading templates seems 
 hardly usable and incorrect to me and should be replaced with something more 
 appropriate.
 
 The reason is the handling of root, controller and the namespace before and 
 after the load. Both are treated in 2 different ways. Before the load, they 
 are used to adjust the following load - by setting the root (for fx:root 
 tag), setting the namespace and a controller.
 However, after the load, these properties (though not FX-properties) can be 
 used to query what was just loaded. The root of the FXML, the namespace with 
 all ids and the controller.
 
 Now that's not very useful when you want to use template loading. My 
 solution for RT-28121 (when keeping the old API) is to save the namespace 
 after setTemplate(true) was called, using this namespace on each load(), 
 clearing it at the begging of load() +  disallow setController() for this 
 mode.
 
 But that doesn't cover all of the relevant use-cases I can think of. 
 Actually, without changing the API, I doubt we can support all such 
 use-cases.
 
 Here's the set I'm working with:
 1) setup some template namespace, n times do { adjust namespace (based on 
 template namespace) , load) }
 
 2) n times do {load, query id from namespace}
 
 3) n times do {setController(new Controller) load }
 
 4) n times do {load, query newly created controller}
 
 5,6) same as 3,4 but with root
 
 So while in 1,3 we would need to clear namespace/controller after each load, 
 in 2,4 we need to clear it before each load. In case 3), forgetting to set a 
 new controller would otherwise result in 2 instances with the same 
 controller.
 
 One solution might be to split this to 2 independent calls. 
 setController/getLoadedController, ObservableMap getNamespace() and Map 
 getLoadedNamespace (unmodifiable).
 
 Another might be a completely new class FXMLTemplate.
 It might yield new pre-set FXMLLoaders that can be adjusted and loaded, but 
 it means generating a temporary object for each call.
 Also, FXMLLoader would need to be updated, so that it's only possible to 
 call load() once.
 
 Other ideas / use-cases?
 
 Thanks,
 -Martin
 

Lambdafication (was Re: Default methods in JFX-8)

[Richard Bair]

 Hello, OpenJFX Community.
 
 There's a question about using Java 8 features in FX.
 
 I've been working on the support for InputMethods in JFXPanel which is an 
 important feature for many users who speak hieroglyphic languages.
 The issue is tracked under: https://javafx-jira.kenai.com/browse/RT-13248
 
 In order to have a high-quality support we need to change 
 javafx.scene.input.InputMethodRequests interface and introduce 3 new methods. 
 This is not needed for pure FX applications right now, but absolutely 
 required for InputMethods in the JFXPanel. However, the interface is public 
 and it was present since FX2.0, so changing it would become a breaking 
 change. So the only way to avoid the problem is using the default methods. 
 Those would return some stub values, the JDK is OK with that, as it would not 
 crash or throw exceptions, but text composition would not work correctly.
 
 I know that we want to avoid using the Java 8 features in the JFX-8, so I 
 wanted to ask - is it OK to use the default methods here?
 
 
 If you are staying away from JDK8 features for the JFX78 backport, don't 
 worry.  There are more issues with new JDK8 APIs than with the new language 
 features.  
 
 For example there were default methods put into some collections classes that 
 we solved by pushing them down to the first implements.  But the Date and 
 Time picker depends on the new time package.  The threeten backport won't be 
 updated until after 8 ships, so that has been removed so far.
 
 I'de be interested to know what a wholesale lamdaization would result in 
 speed wise and code size wise (both source and compiled).  From what I can 
 tell the IDEs can lambda and de-lambda fairly easily, so it jsut makes the 
 backport more of a busy work proposition.  If there were performance gains it 
 would also make a great front page story in the next java magazine or a case 
 study..

After having used Lambda's for JavaOne, I'd love to make the conversion, even 
if in the end the performance was the same, because the savings in noise in the 
Java files is so big. At one time I just took the concurrent classes and 
lambda-ized them to measure the impact on those classes. You could maybe pick a 
package and just lambda-ize that one package and see what happens in terms of 
size reduction. We might see:

+ A reduction in the overall class size (not pack-200'd)
- An increase in startup time (have to spin up synthetic classes created at 
usage time)
+/- And increase or decrease in performance
+ A decrease in source code

It would be interesting to get some data for these points and see what effect 
lambda's have. Especially if an IDE can just do it in bulk…

Richard

Re: Default methods in JFX-8

[Richard Bair]

  What code needs to call these new methods?
 
 These are used in the JFXPanel to provide the needed information to the 
 AWT/Swing, so that it could properly position the text composition window and 
 track what is going on with the text.
 
 I don't know enough about the domain to know what other options you have, 
 besides adding InputMethodRequests2 or whatever and having to do an 
 instanceof test and cast. But that might actually be the better way to 
 handle this situation
 We could add some internal extension of the interface and use instanceof 
 checks. It would be done in a single place and would not make a lot of harm. 
 The only problem with this approach is that third-party text-input component 
 would not be able to support IM inside the JFXPanel.

I'm not sure there are any 3rd party text input controls that don't extend from 
TextInputControl. If a 3rd party text input control does extend from 
TextInputControl / TextInputControlSkin, will it work?

If we use an internal interface, will this fact leak through the public API? 
That is, if I enumerated the hierarchy of a public API member, will I see this 
non-public interface somewhere on it? Or is the only way to get a hold of some 
internal object and cast it?

I'm wondering if we can punt on the problem until somebody encounters it, and 
in the meantime just use a private interface.

Thanks
Richard

Re: Lambdafication (was Re: Default methods in JFX-8)

[Richard Bair]

Brian was telling me at J1 that whether parallel gets you performance or not 
depends on the size of the collection and the complexity of the work to 
perform. There is definitely a point at which parallel helps -- and a point at 
which it hurts.

Richard

On Oct 3, 2013, at 3:33 PM, Hervé Girod herve.gi...@gmail.com wrote:

 Here is a nice example, taking advantage of the ease of going parallel. 
 Apparently the performance without parallel will also further improve. 
 http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/
 
 Hervé
 
 Sent from my iPad
 
 On 4 oct. 2013, at 00:20, David Grieve david.gri...@oracle.com wrote:
 
 And what about Stream? I like the declarative code that comes from using 
 Stream and I can see places in the code where Stream could be used, but I 
 wonder about its performance relative to iterators and/or enhanced for 
 loops. 
 
 On Oct 3, 2013, at 4:45 PM, Richard Bair richard.b...@oracle.com wrote:
 
 Hello, OpenJFX Community.
 
 There's a question about using Java 8 features in FX.
 
 I've been working on the support for InputMethods in JFXPanel which is an 
 important feature for many users who speak hieroglyphic languages.
 The issue is tracked under: https://javafx-jira.kenai.com/browse/RT-13248
 
 In order to have a high-quality support we need to change 
 javafx.scene.input.InputMethodRequests interface and introduce 3 new 
 methods. This is not needed for pure FX applications right now, but 
 absolutely required for InputMethods in the JFXPanel. However, the 
 interface is public and it was present since FX2.0, so changing it would 
 become a breaking change. So the only way to avoid the problem is using 
 the default methods. Those would return some stub values, the JDK is OK 
 with that, as it would not crash or throw exceptions, but text composition 
 would not work correctly.
 
 I know that we want to avoid using the Java 8 features in the JFX-8, so I 
 wanted to ask - is it OK to use the default methods here?
 
 
 If you are staying away from JDK8 features for the JFX78 backport, don't 
 worry.  There are more issues with new JDK8 APIs than with the new 
 language features.  
 
 For example there were default methods put into some collections classes 
 that we solved by pushing them down to the first implements.  But the Date 
 and Time picker depends on the new time package.  The threeten backport 
 won't be updated until after 8 ships, so that has been removed so far.
 
 I'de be interested to know what a wholesale lamdaization would result in 
 speed wise and code size wise (both source and compiled).  From what I can 
 tell the IDEs can lambda and de-lambda fairly easily, so it jsut makes the 
 backport more of a busy work proposition.  If there were performance gains 
 it would also make a great front page story in the next java magazine or a 
 case study..
 
 After having used Lambda's for JavaOne, I'd love to make the conversion, 
 even if in the end the performance was the same, because the savings in 
 noise in the Java files is so big. At one time I just took the concurrent 
 classes and lambda-ized them to measure the impact on those classes. You 
 could maybe pick a package and just lambda-ize that one package and see 
 what happens in terms of size reduction. We might see:
 
  + A reduction in the overall class size (not pack-200'd)
  - An increase in startup time (have to spin up synthetic classes created 
 at usage time)
  +/- And increase or decrease in performance
  + A decrease in source code
 
 It would be interesting to get some data for these points and see what 
 effect lambda's have. Especially if an IDE can just do it in bulk…
 
 Richard
 

[API-REVIEW] RT-32848: Add CENTER constant to BackgroundPosition

[Richard Bair]

Simple API addition to BackgroundPosition:

/**
 * A BackgroundPosition which will center a BackgroundImage.
 */
public static final BackgroundPosition CENTER = new BackgroundPosition(
Side.LEFT, .5, true, Side.TOP, .5, true);

No implementation changes.

Re: CFV: New OpenJFX Committer: Joseph Andresen

[Richard Bair]

Vote: yes

On Sep 25, 2013, at 8:17 AM, Artem Ananiev artem.anan...@oracle.com wrote:

 
 I hereby nominate Joe Andresen to OpenJFX Committer.
 
 Joe is a member of JavaFX Graphics team at Oracle. His first changeset in 
 Prism is dated by 2009, and total number of commits is close to one hundred. 
 Full list of Joe's changesets in the open workspace is available from command 
 line:
 
hg log -u Joseph Andresen
 
 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,
 
 Artem

Re: Bounds constructor validation

[Richard Bair]

I see this is not going to work, since isEmpty() defines itself as where one 
component's max (maxX, maxY, maxZ) is less than the corresponding min. So we 
make sense, at least, out of -1 (although as far as the implementation is 
concerned, any negative value works just as well).

On Oct 1, 2013, at 3:13 PM, Richard Bair richard.b...@oracle.com wrote:

 Hi,
 
 I'm looking at https://javafx-jira.kenai.com/browse/RT-23446, where the 
 argument is made that the width / height of a node (specifically, a Region's 
 prefWidth, minWidth, maxWidth, prefHeight, minHeight, maxHeight) should never 
 be negative. While looking at this, I noticed that in Node, the prefWidth 
 method relies on the layoutBounds.getWidth(). However, the Bounds class 
 itself does not appear to do any validation of the parameters passed to the 
 Bounds. There are no checks for NaN, and no checks for negative width, 
 height, depth.
 
 Is there any reason why we should allow NaN, or negative width / height / 
 depth for Bounds?
 
 Richard

Re: Moving on to a round house kick (forked from Re: JavaOne roundup?)

[Richard Bair]

 2. Wow, there is a JavaFX enabled Dukepad. Beeing a soldering nerd myself, 
 hacking firmware and much cool stuff
 in my spare time it really kicked me in the first place. Then I grounded when 
 I have seen that it was a childish puzzle
 with lego blocks.

What?

 The longer I think about that, the longer I am getting angry to see a 100 men 
 powered development 
 team to build a demo on a demo board for a hand full nerds.

I don't know where you got that impression. Jasper did the design, and there 
were a couple of people who spent a couple weeks working on software. And that 
wasn't writing the DukePad software, predominantly, but it was fixing 
performance issues in Prism that affect all platforms.

The value is in embedded development. Before JavaOne we didn't have all the 
agreements in place to work with Freescale. The Raspberry PI has a nice 
following, is great for educational purposes and home-brew, so it was a great 
choice to build a demo on top of (as opposed to, say, a BeagleBoard or 
BeagleBone which is either more expensive or doesn't have the same size 
following). Having an actual project to work on also teases out bugs and 
performance issues, and most of the work leading up to JavaOne was in finding 
and fixing these issues. These same issues will affect any embedded project, 
including the RoboVM / iOS / Android work.

 Well that would be ok, if Oracle said that this is a demo
 on a prototyping board and the important platforms will follow soon. No word 
 about iOS, Android, Windows8. 

Do you mean Windows Phone 8? Because Windows 8 is a given.

 Do you really believe that there are many people to build a Tablet like this? 
 I am really sure non of the major 
 hardware manufacturer will build a tablet on top of this platform soon since 
 Android is also free to us and is 
 much more attractive to the end-user. The only thing that I can image is that 
 Oracle comes up with their own
 iPad-Killer in the near future (don't wait too long) otherwise this decision 
 make no sense to me.

No, none of this. DukePad is not a product. We made that pretty clear, it's an 
open source hardware/software design for the Raspberry PI community. We will 
make no money off the designs and Oracle isn't selling anything here. For us it 
was a vehicle on which we could demonstrate our ability to run well on embedded 
devices, and find and fix bugs along the way. Oracle isn't going to produce a 
mobile device. DukePad was not any kind of product announcement. Those kinds of 
things happen in strategy keynotes, not in technical keynotes.

Richard

Re: losing the validation listener

[Richard Bair]

Thanks Tom!

On Sep 27, 2013, at 1:12 PM, Tom Eugelink t...@tbee.org wrote:

 
 Hi Richard,
 
 I tried to reproduce the bug and so far it has not occurred anymore. So it 
 seems it has magically resolved itself.
 
 Regards,
 
 Tom
 
 
 On 2013-09-26 21:56, Richard Bair wrote:
 Hi Tom,
 
 Did this issue ever get resolved? It sounds very strange indeed, and we 
 should have a JIRA filed for it if there is not one already.
 
 Thanks
 Richard
 
 On Apr 8, 2013, at 3:48 AM, Tom Eugelink t...@tbee.org wrote:
 
 Hi Werner,
 
 It indeed is very similar (my code is public on Github, so no use adding it 
 here), especially the selectedToggleProperty listener. I chose to reuse as 
 much of the existing approach, being the getUserData().
 
 What would be of interest to me is:
 - the exact declaration of the enumValueProperty
 - how you listen to changes on enumValueProperty
 - and of course: what happens if you hide/disable the toggles with only one 
 listener attached
 
 Tom
 
 
 On 2013-04-08 11:51, Werner Lehmann wrote:
 Hi Tom,
 
 I did something similar: toggle group for toggles which correspond to enum 
 members. This one assume that the toggles correspond to the enum members 
 in their declared order. It also uses an invalidation listener and 
 disabling/enabling a toggle keeps the listener functional as I just tested 
 with a test application.
 
 public class MintEnumToggleGroupE extends EnumE extends ToggleGroup
 {
  public MintEnumToggleGroup(ClassE enumClass)
  {
this.enumClass = enumClass;
 
selectedToggleProperty().addListener(new InvalidationListener()
{
  @Override
  public void invalidated(Observable observable)
  {
Toggle toggle = getSelectedToggle();
E value = null;
if (toggle != null)
{
  int ordinal =
MintEnumToggleGroup.this.getToggles().indexOf(toggle);
  value = MintEnumToggleGroup.this.enumClass
.getEnumConstants()[ordinal];
}
if (enumValue.get() != value)
  enumValue.set(value);
  }
});
 
...
  }
 
  /**
   * Bidirectionally bindable property representing the enum member
   * of the selected toggle.
   */
  public ObjectPropertyE enumValueProperty() { return enumValue; }
  public E getEnumValue() { return enumValueProperty().get(); }
  public void setEnumValue(E value) { enumValueProperty().set(value); }
 }
 
 
 Looks similar to what you are doing. Let me know if you want to look at 
 the full source (toggle group and testcase).
 
 Rgds
 Werner
 
 On 07.04.2013 21:28, Tom Eugelink wrote:
 Again some strange behavior I could use some pointers with. In JFXtras 
 I've created an extended ToggleGroup which has a value property.
 https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/scene/control/ToggleGroupValue.java
 
 Basically what it does is listen to the selectedToggleProperty of 
 ToggleGroup, and upon invalidation gets the user data associated with the 
 now active toggle and puts that in the valueProperty. Simple, and now you 
 can register and listen to the value of the toggle group. Which is 
 exactly what I do in my basketball application by registering to the 
 invalidated event.
  toggleGroup.valueProperty().addListener(new InvalidationListener() 
 {...});
 
 Now I have one very strange behavior; if I disable or hide the toggles, 
 and then re-enable/show them again, the invalidation listener is no 
 longer called. Some how it seems to have been removed from the listeners 
 list. But the API documentation explicitly says it is a strong reference.
 http://docs.oracle.com/javafx/2/api/javafx/beans/Observable.html#addListener(javafx.beans.InvalidationListener)
 
 If I add a second dummy listener, then the first listener is not removed 
 when disabled/hidden.
 
 It very much reeks like a garbage collection thing. Any suggestions?
 
 Tom
 
 
 

Re: losing the validation listener

[Richard Bair]

Hi Tom,

Did this issue ever get resolved? It sounds very strange indeed, and we should 
have a JIRA filed for it if there is not one already.

Thanks
Richard

On Apr 8, 2013, at 3:48 AM, Tom Eugelink t...@tbee.org wrote:

 
 Hi Werner,
 
 It indeed is very similar (my code is public on Github, so no use adding it 
 here), especially the selectedToggleProperty listener. I chose to reuse as 
 much of the existing approach, being the getUserData().
 
 What would be of interest to me is:
 - the exact declaration of the enumValueProperty
 - how you listen to changes on enumValueProperty
 - and of course: what happens if you hide/disable the toggles with only one 
 listener attached
 
 Tom
 
 
 On 2013-04-08 11:51, Werner Lehmann wrote:
 Hi Tom,
 
 I did something similar: toggle group for toggles which correspond to enum 
 members. This one assume that the toggles correspond to the enum members in 
 their declared order. It also uses an invalidation listener and 
 disabling/enabling a toggle keeps the listener functional as I just tested 
 with a test application.
 
 public class MintEnumToggleGroupE extends EnumE extends ToggleGroup
 {
  public MintEnumToggleGroup(ClassE enumClass)
  {
this.enumClass = enumClass;
 
selectedToggleProperty().addListener(new InvalidationListener()
{
  @Override
  public void invalidated(Observable observable)
  {
Toggle toggle = getSelectedToggle();
E value = null;
if (toggle != null)
{
  int ordinal =
MintEnumToggleGroup.this.getToggles().indexOf(toggle);
  value = MintEnumToggleGroup.this.enumClass
.getEnumConstants()[ordinal];
}
if (enumValue.get() != value)
  enumValue.set(value);
  }
});
 
...
  }
 
  /**
   * Bidirectionally bindable property representing the enum member
   * of the selected toggle.
   */
  public ObjectPropertyE enumValueProperty() { return enumValue; }
  public E getEnumValue() { return enumValueProperty().get(); }
  public void setEnumValue(E value) { enumValueProperty().set(value); }
 }
 
 
 Looks similar to what you are doing. Let me know if you want to look at the 
 full source (toggle group and testcase).
 
 Rgds
 Werner
 
 On 07.04.2013 21:28, Tom Eugelink wrote:
 
 Again some strange behavior I could use some pointers with. In JFXtras I've 
 created an extended ToggleGroup which has a value property.
 https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/scene/control/ToggleGroupValue.java
 
 Basically what it does is listen to the selectedToggleProperty of 
 ToggleGroup, and upon invalidation gets the user data associated with the 
 now active toggle and puts that in the valueProperty. Simple, and now you 
 can register and listen to the value of the toggle group. Which is exactly 
 what I do in my basketball application by registering to the invalidated 
 event.
  toggleGroup.valueProperty().addListener(new InvalidationListener() 
 {...});
 
 Now I have one very strange behavior; if I disable or hide the toggles, and 
 then re-enable/show them again, the invalidation listener is no longer 
 called. Some how it seems to have been removed from the listeners list. But 
 the API documentation explicitly says it is a strong reference.
 http://docs.oracle.com/javafx/2/api/javafx/beans/Observable.html#addListener(javafx.beans.InvalidationListener)
 
 If I add a second dummy listener, then the first listener is not removed 
 when disabled/hidden.
 
 It very much reeks like a garbage collection thing. Any suggestions?
 
 Tom
 
 

Re: Strange NullPointerException when I use a certain CSS.

[Richard Bair]

Hi Scott,

Did this ever get answered? Is the issue reproducible on the latest 8 builds?

Thanks
Richard

On May 8, 2013, at 7:10 AM, Scott Palmer swpal...@gmail.com wrote:

 JavaFX 2.2.21-b11
 I have a TextField where I have set the skin to the following:
 
private static class MyEditorSkin extends TextFieldSkin {
 
public MyEditorSkin (TextField tf) {
super(tf);
}
 
public MyEditorSkin (TextField tf, TextFieldBehavior tfb) {
super(tf, tfb);
}
 
public FontMetrics getFontMetrics() {
return fontMetrics.getValue();
}
}
 
 e.g. myTextField.setSkin(new MyEditorSkin(myTextField));
 
 Elsewhere in my code I do:
Skin? skin = tf.getSkin();
if (skin instanceof MyEditorSkin) {
FontMetrics fm = ((MyEditorSkin) skin).getFontMetrics();
...
 
 This was the only way I could see to get at the Font metrics used in a
 TextField.  (I need to position some popups near the caret and using the
 public methods to get the caret position in characters combined with
 finding the width of the preceding characters seemed to be the simplest
 way.)
 
 Anyway.. my code has been working fine, but I just got a new style-sheet
 from our graphic designer and when I use the new CSS suddenly the TextField
 is throwing the following exception and I can't move the caret with the
 cursor keys or type properly in it.
 
 Exception in thread JavaFX Application Thread
 java.lang.NullPointerException
at
 com.sun.javafx.scene.control.skin.TextInputControlSkin.setCaretAnimating(TextInputControlSkin.java:585)
at
 com.sun.javafx.scene.control.behavior.TextFieldBehavior.setCaretAnimating(TextFieldBehavior.java:164)
at
 com.sun.javafx.scene.control.behavior.TextInputControlBehavior.callAction(TextInputControlBehavior.java:124)
at
 com.sun.javafx.scene.control.behavior.BehaviorBase.callActionForEvent(BehaviorBase.java:157)
at
 com.sun.javafx.scene.control.behavior.TextInputControlBehavior.callActionForEvent(TextInputControlBehavior.java:117)
at
 com.sun.javafx.scene.control.behavior.BehaviorBase$1.handle(BehaviorBase.java:121)
at
 com.sun.javafx.scene.control.behavior.BehaviorBase$1.handle(BehaviorBase.java:119)
at
 com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:64)
at
 com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:217)
at
 com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:170)
at
 com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:38)
at
 com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:37)
at
 com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:92)
at
 com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:35)
at
 com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:92)
at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:53)
at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:28)
at javafx.event.Event.fireEvent(Event.java:171)
at javafx.scene.Scene$KeyHandler.process(Scene.java:3513)
at javafx.scene.Scene$KeyHandler.access$2300(Scene.java:3472)
at javafx.scene.Scene.impl_processKeyEvent(Scene.java:1904)
at javafx.scene.Scene$ScenePeerListener.keyEvent(Scene.java:2270)
...
 Also happens on focus gained.
 
 Looking at that line of source it seems that the only thing that could be
 null is the caretTimeline.  But the caret is blinking away happily.  I
 search the code and it seems the only way the caretTimeline can become null
 is if dispose() is called on the TextInputControlSkin.  I don't understand
 when this would happen or how different CSS that does little more than set
 colours and backgrounds and borders would affect it.
 
 I'm not sure if I'm doing something wrong or if this warrants a bug report.
 
 In JavaFX 8.0.0-ea-b87  it is worse.. I can't even show the Scene with my
 control without getting the following:
 
 Exception in thread JavaFX Application Thread
 java.lang.NullPointerException
at com.sun.javafx.css.StyleCacheEntry.put(StyleCacheEntry.java:82)
at
 javafx.scene.CssStyleHelper.transitionToState(CssStyleHelper.java:784)
at javafx.scene.Node.impl_processCSS(Node.java:8541)
at javafx.scene.Parent.impl_processCSS(Parent.java:1191)
at javafx.scene.Parent.impl_processCSS(Parent.java:1191)
at javafx.scene.control.Control.impl_processCSS(Control.java:861)
at javafx.scene.Parent.impl_processCSS(Parent.java:1191)
at javafx.scene.Parent.impl_processCSS(Parent.java:1191)
at javafx.scene.Parent.impl_processCSS(Parent.java:1191)
at