date:20130809

Scale the imageview?

On Aug 9, 2013, at 8:57 PM, John Hendrikx  wrote:

> On 10/08/2013 05:46, John Hendrikx wrote:
>> On 9/08/2013 20:15, Richard Bair wrote:
 Also the proposed clear() or empty() option only applies to Canvas correct?
 i.e. WritableImages don't suffer from these kind of issues and don't 
 require such methods?
>>> That is correct (WritableImage we don't provide a 2D API to use to fill the 
>>> buffer, you just bash the pixels yourself however you like, so we don't 
>>> have to buffer anything up).
>> Hm, I didn't realize WritableImage had the same kind PixelWriter interface.  
>> For my usecase, where I just render full frames to a PixelWriter so JavaFX 
>> can display them in some fashion, why should I not use a WriteableImage 
>> instead?
>> 
>> Looking at the docs, I see that one limitation is that the WritableImage 
>> cannot be resized after construction (something that I do use with Canvas), 
>> but I think I could work around that by just recreating the Image when its 
>> size changes... I could just wrap a class around it that does this 
>> transparently.
>> 
>> Going to take a look if I can rip out the Canvas code and replace it with a 
>> resizable WritableImage and see what the results are for full screen video 
>> playback...
> Foiled before I even could get started :/
> 
> I need the scaleX and scaleY properties of Canvas as well... basically, my 
> input video data is always decoded at native size (say 1920x1080) and then 
> scaled down or up to fit the screen.  Since I offer a feature that can switch 
> to a different attached monitor at any time, even during playback, I cannot 
> tell my video source to scale the video for me (it does not offer a way to 
> alter this after playback starts).  I haven't given up entirely on 
> WritableImage, but this complicates sufficiently that I cannot just create a 
> drop-in replacement for Canvas that suits my usecase.
> 
> --John
> 
>

Re: Canvas blowing up (was Re: JavaFX Media issues)


On 10/08/2013 05:46, John Hendrikx wrote:

On 9/08/2013 20:15, Richard Bair wrote:
Also the proposed clear() or empty() option only applies to Canvas 
correct?
i.e. WritableImages don't suffer from these kind of issues and don't 
require such methods?
That is correct (WritableImage we don't provide a 2D API to use to 
fill the buffer, you just bash the pixels yourself however you like, 
so we don't have to buffer anything up).
Hm, I didn't realize WritableImage had the same kind PixelWriter 
interface.  For my usecase, where I just render full frames to a 
PixelWriter so JavaFX can display them in some fashion, why should I 
not use a WriteableImage instead?


Looking at the docs, I see that one limitation is that the 
WritableImage cannot be resized after construction (something that I 
do use with Canvas), but I think I could work around that by just 
recreating the Image when its size changes... I could just wrap a 
class around it that does this transparently.


Going to take a look if I can rip out the Canvas code and replace it 
with a resizable WritableImage and see what the results are for full 
screen video playback...



Foiled before I even could get started :/

I need the scaleX and scaleY properties of Canvas as well... basically, 
my input video data is always decoded at native size (say 1920x1080) and 
then scaled down or up to fit the screen.  Since I offer a feature that 
can switch to a different attached monitor at any time, even during 
playback, I cannot tell my video source to scale the video for me (it 
does not offer a way to alter this after playback starts).  I haven't 
given up entirely on WritableImage, but this complicates sufficiently 
that I cannot just create a drop-in replacement for Canvas that suits my 
usecase.


--John

Re: Canvas blowing up (was Re: JavaFX Media issues)


On 9/08/2013 20:15, Richard Bair wrote:

Also the proposed clear() or empty() option only applies to Canvas correct?
i.e. WritableImages don't suffer from these kind of issues and don't require 
such methods?

That is correct (WritableImage we don't provide a 2D API to use to fill the 
buffer, you just bash the pixels yourself however you like, so we don't have to 
buffer anything up).
Hm, I didn't realize WritableImage had the same kind PixelWriter 
interface.  For my usecase, where I just render full frames to a 
PixelWriter so JavaFX can display them in some fashion, why should I not 
use a WriteableImage instead?


Looking at the docs, I see that one limitation is that the WritableImage 
cannot be resized after construction (something that I do use with 
Canvas), but I think I could work around that by just recreating the 
Image when its size changes... I could just wrap a class around it that 
does this transparently.


Going to take a look if I can rip out the Canvas code and replace it 
with a resizable WritableImage and see what the results are for full 
screen video playback...


--John

Re: Canvas blowing up (was Re: JavaFX Media issues)

On 9/08/2013 17:23, Richard Bair wrote:

I mean, it looks like it is working for a few seconds,
but then as the memory fills with the Canvas backlog it can lead to the GC
using a lot more CPU, thus reducing the ability for Canvas to process its
command queue even further, well it just collapses in on itself and dies.

Forking the thread.

The problem with Canvas is that if you have a canvas and you scribble on it,
and then scribble on it some more, and then scribble on it some more, then in
order for us to get the right result in the end, we need to replay all those
scribbles in order. If pulses are not happening, we still need to remember
these scribbles so we can draw the right result.
That's currently how it works, but I guess for quite a few users it is
unexpected that a Canvas, which looks like basically a texture where you
can draw on, has any other (significant) memory requirements apart from
the initial allocation of the buffer based on its size. I visualize the
Canvas as a pixel buffer with low level tools to help you manipulate it,
and these manipulations occur... well, immediately (like settings bits
in memory). Any memory allocated associated with the action you just
did should disappear as soon as the action is 'applied' to the texture.

Perhaps we'd need more of a flush() style command that forces Canvas to
apply all outstanding actions now and consolidate them into the texture
so memory can be freed.

BUT, if you issue a command to the canvas which will cause it to "clear" all
its contents, then we could throw away any previously buffered data. Right now the only
way to do that would be a fillRect with a solid fill where the fillRect encompasses the
entire canvas area, or a clearRect where the clearRect encompasses the entire canvas area.
I think that's definitely a worthwhile solution to investigate. For my
use-case it would likely solve any OOM issues, as I can easily "clear"
the canvas each frame (or better yet, Canvas could notice that the
PixelWriter I use covers its full area). Lacking that, I'd prefer to
have a command that just discards previous actions than requiring an
unnecessary clear/fill when I know that my next command is going to set
all pixels anyway.

This seems like a very simple fix. GraphicsContext.clearRect and GraphicsContext.fillRect should
both (under the right conditions) throw away the previously buffered commands. Then all you have to
do is be sure to make one of these calls (likely just a clearRect) before each frame, and we'll
never buffer more than a single frame's worth of data. We could also add a "clear" method
which is "clearRect(0, 0, w, h)" to make this more foolproof, and then document it as a
best practice to clear the canvas before each rendering if you intend to redraw the entire thing on
each frame.

If you're making use of manually operated "dirty rects" so that you only clear the
damaged area to repaint, then we couldn't employ this technique and we'd have to buffer 'till
kingdom come. So we still need a mechanism exposed in the scene graph of "liveness" and
associated events so that when the scene is no longer live (for example, when minimized) you could
stop your animation timer, but for your specific media use case this isn't as important.
For my media use-case (and perhaps Scott's) it would definitely solve
the issue -- I don't intend to do anything else with Canvas, all other
things I want to draw will occur in normal JavaFX controls layered
transparently on top of the Canvas.

I still think though that it is rather unexpected behaviour for Canvas
that it can use significantly more memory (under certain conditions)
than just the pre-allocated buffer -- even more so when you use
PixelWriter -- I really expected that to go straight to the buffer, not
make yet another copy.

--John

hg: openjfx/8/graphics/rt: EnsembleApp: rename IS_BEAGLE to IS_EMBEDDED, correctly set IS_IOS

Changeset: 984368f375ed
Author:snorthov
Date:  2013-08-09 18:42 -0400
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/984368f375ed

EnsembleApp: rename IS_BEAGLE to IS_EMBEDDED, correctly set IS_IOS

! apps/samples/Ensemble8/src/app/java/ensemble/EnsembleApp.java
! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SamplePage.java
! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SourceTab.java

hg: openjfx/8/graphics/rt: RT-15314 Allow trusted apps to disable the fullscreen overlay warning

Changeset: a05473e09c47
Author:ddhill
Date:  2013-08-09 18:08 -0400
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a05473e09c47

RT-15314 Allow trusted apps to disable the fullscreen overlay warning

! modules/graphics/src/main/java/com/sun/javafx/tk/DummyToolkit.java
! modules/graphics/src/main/java/com/sun/javafx/tk/TKSceneListener.java
! modules/graphics/src/main/java/com/sun/javafx/tk/TKStage.java
! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java
! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedScene.java
! 
modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java
! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/OverlayWarning.java
! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java
! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java
! modules/graphics/src/main/java/javafx/scene/Scene.java
! modules/graphics/src/main/java/javafx/scene/input/KeyCombination.java
! modules/graphics/src/main/java/javafx/stage/PopupWindow.java
! modules/graphics/src/main/java/javafx/stage/Stage.java
! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubToolkit.java

hg: openjfx/8/graphics/rt: 2 new changesets

Changeset: 8d527964b7aa
Author:Chien Yang 
Date:  2013-08-09 14:25 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8d527964b7aa

Fix to RT-31537: Intel 965GM creates awful screens and unusable
Reviewed by Kevin

! modules/graphics/src/main/native-prism-d3d/D3DBadHardware.h

Changeset: b0a1b8b91e3b
Author:Chien Yang 
Date:  2013-08-09 14:27 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b0a1b8b91e3b

Fix to RT-32202: Reduce the scope of NGShape3D's members and methods
Reviewed by Kevin

! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java

hg: openjfx/8/controls/rt: 2 new changesets

Changeset: b2a8e6dff797
Author:David Grieve
Date:  2013-08-09 16:07 -0400
URL:   http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b2a8e6dff797

RT-32248: if no cascading styles, return empty list

! modules/graphics/src/main/java/com/sun/javafx/css/StyleMap.java

Changeset: 6fa61e99aaa4
Author:David Grieve
Date:  2013-08-09 16:08 -0400
URL:   http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6fa61e99aaa4

Automated merge with 
ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt

hg: openjfx/8/controls/rt: RT-32237: iOS: TextField resizes when first character typed

Changeset: 3b38cdb047cf
Author:rbair
Date:  2013-08-09 12:54 -0700
URL:   http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3b38cdb047cf

RT-32237: iOS: TextField resizes when first character typed

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListCellBehavior.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/BehaviorSkinBase.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollBarSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableColumnHeader.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextAreaSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextFieldSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextInputControlSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java

hg: openjfx/8/controls/rt: 2 new changesets

Changeset: 9ec9e4cc1eab
Author:David Grieve
Date:  2013-08-09 15:03 -0400
URL:   http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9ec9e4cc1eab

RT-31321: hide implementation details in private methods

! modules/graphics/src/main/java/com/sun/javafx/css/Stylesheet.java
! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java
! modules/graphics/src/main/java/com/sun/javafx/css/parser/Css2Bin.java
! modules/graphics/src/stub/java/com/sun/javafx/css/StylesheetTest.java
! modules/graphics/src/stub/java/com/sun/javafx/css/parser/CSSParserTest.java

Changeset: bccfc1c97086
Author:David Grieve
Date:  2013-08-09 15:23 -0400
URL:   http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bccfc1c97086

RT-31691: Fix for unit test failures caused by previous changeset for this bug. 
Replaced call to impl_processCSS

! modules/controls/src/main/java/javafx/scene/control/Control.java

RE: JavaFX Media issues

2013-08-09 Thread John Smith

> Unfortunately the media team is rather starved for resources these days

Seems to be common to every part of JavaFX development :-(

Thanks for your work on this and for posting the reference to the umbrella 
media input issue.

-Original Message-
From: David DeHaven [mailto:david.deha...@oracle.com] 
Sent: Friday, August 09, 2013 11:38 AM
To: John Smith
Cc: Richard Bair; Felix Bembrick; openjfx-dev@openjdk.java.net List
Subject: Re: JavaFX Media issues

>> So called arbitrary input stream support is among the features for the 
>> future.
> 
> Could somebody post back a reference to the jira, I've seen the feature 
> referred to from other jiras, but I've never been able to find the actual 
> jira reference for this.  Thanks!

Here's an umbrella issue that would cover this:
https://javafx-jira.kenai.com/browse/RT-14938

Unfortunately the media team is rather starved for resources these days (even 
more so than in the past).

-DrD-

Re: JavaFX Media issues

2013-08-09 Thread David DeHaven

>> So called arbitrary input stream support is among the features for the 
>> future.
> 
> Could somebody post back a reference to the jira, I've seen the feature 
> referred to from other jiras, but I've never been able to find the actual 
> jira reference for this.  Thanks!

Here's an umbrella issue that would cover this:
https://javafx-jira.kenai.com/browse/RT-14938

Unfortunately the media team is rather starved for resources these days (even 
more so than in the past).

-DrD-

RE: JavaFX Media issues

2013-08-09 Thread John Smith

> So called arbitrary input stream support is among the features for the future.

Could somebody post back a reference to the jira, I've seen the feature 
referred to from other jiras, but I've never been able to find the actual jira 
reference for this.  Thanks!

-Original Message-
From: openjfx-dev-boun...@openjdk.java.net 
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Richard Bair
Sent: Friday, August 09, 2013 8:35 AM
To: Felix Bembrick
Cc: openjfx-dev@openjdk.java.net List
Subject: Re: JavaFX Media issues

Forwarded from Kiriil Kirichenko who is getting his mailing list credentials 
sorted out...

>> *From: *Felix Bembrick > >
>> *Subject: **JavaFX Media issues*
>> *Date: *August 8, 2013 1:31:37 PM PDT
>> *To: *"openjfx-dev@openjdk.java.net
>>  List"
>> mailto:openjfx-dev@openjdk.java.net>>
>> 
>> I am having a look at JavaFX media support and have a couple of questions:
>> 
>> 1. It seems that the only way to load media files is by specifying a 
>> source such as a file path etc.  This is not going to work well for 
>> me as all of my application's content (which includes data, digital 
>> assets, media etc.) is stored in a database on the server and is 
>> loaded through an IO stream.
>> Why doesn't Media support loading of files through a stream?  That 
>> would seem like a common use case to me!

This is correct. So called arbitrary input stream support is among the features 
for the future.

>> 2. I am unable to locate any reference to JavaFX Media in the 
>> JavaDocs for JDK 8 which I found here:
>> 
>> http://download.java.net/jdk8/jfxdocs/index.html
>> 
>> Is this just a glitch?

A glitch related to javadoc execution. FXMedia is still there.

>> 3. Is buffering of media something planned for the future in JavaFX?

What do you mean by buffering ? We have progressive buffer for http links. See 
MediaPlayer.bufferProgressTimeProperty

>> 4. What about live streaming of media content?

We support Http Live Streaming: MpegTS which contains H264 + AAC.

Re: Canvas blowing up (was Re: JavaFX Media issues)

> Also the proposed clear() or empty() option only applies to Canvas correct? 
> i.e. WritableImages don't suffer from these kind of issues and don't require 
> such methods?

That is correct (WritableImage we don't provide a 2D API to use to fill the 
buffer, you just bash the pixels yourself however you like, so we don't have to 
buffer anything up).

Richard

RE: Canvas blowing up (was Re: JavaFX Media issues)

2013-08-09 Thread John Smith

This question was recently asked on StackOverflow as well:
http://stackoverflow.com/questions/18097404/how-can-i-free-canvas-memory "How 
can I free Canvas memory?"
So others have been running into these kind of issues.

Also the proposed clear() or empty() option only applies to Canvas correct? 
i.e. WritableImages don't suffer from these kind of issues and don't require 
such methods?

Regards,
John

-Original Message-
From: openjfx-dev-boun...@openjdk.java.net 
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Richard Bair
Sent: Friday, August 09, 2013 9:43 AM
To: Dr. Michael Paus
Cc: openjfx-dev@openjdk.java.net
Subject: Re: Canvas blowing up (was Re: JavaFX Media issues)

> What would be the performance penalty for using this quick-fix? The 
> clear/fill commands do not just clear the command buffer. They also 
> fill the canvas area with a certain color. So in normal operation the canvas 
> is always filled twice for each frame, isn't it?

That would be correct. Another option is to add, instead of "clear()" an 
explicit "empty()" method or something that would just blow away the buffer.

Richard

Re: How to raise JavaFX iOS bugs?

Please keep filing any bugs you see and add me to the watch list.  I do 
run RoboVM and am able to test there.


Thanks,
Steve

On 09/08/2013 1:54 PM, Daniel Zwolenski wrote:

Is there going to be an answer on what JVM is going to be used for the JavaOne 
iOS demo?

I'd also like to know what JVM you are testing on for these fixes?


On 10/08/2013, at 12:46 AM, steve.x.northo...@oracle.com wrote:


On 08/08/2013 6:08 PM, Daniel Zwolenski wrote:

No, I didn't get a chance. Probably easier for you to just raise it now?

See https://javafx-jira.kenai.com/browse/RT-32237


It's going to be a pretty big round loop to get ios fixes in. It first needs to 
go into jfx then needs to be merged into the backport, then that needs to be 
deployed to maven, then the maven plugin needs to be updated to refer to the 
new version, then the maven plugin needs to be deployed to maven.

I could simplify the last step by allowing the version of jfx backport to be 
configurable.

As I've raised in previous emails, help would be good. I don't suppose any 
oracle people could be allocated to merging changed into the backport on a 
regular basis (eg weekly) - even on an unofficial, non-publicly-commited 
arrangement?


On 09/08/2013, at 7:38 AM, steve.x.northo...@oracle.com wrote:


Hi Daniel,

Did you log a bug for the TextField problem?  If you have not done so, please do.  If you 
use "iOS:" as a prefix for the title of the bug and use iOS as a label, that 
should help people find iOS related bugs.  I have a fix for the problem you are seeing.  
The text skin thinks that because iOS has touch, it needs to show resize handles in the 
text field.

Steve

On 01/08/2013 6:08 PM, Daniel Zwolenski wrote:

So now the Maven stuff is working (
http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/),
I'm gradually starting to muck around with the iOS stuff.

There are problems - how do I raise them? Should I log JIRAs? Should I
bring them up here, etc? Will you guys start running jfx on iOS now that
it's possible and are bug fixes within your allowance to work on given iOS
is not a supported platform?

For example, in the hello world example, I've included a TextField. When I
start typing in it on my iPad the field starts changing size to accommodate
the auto-correction popup, which looks very weird. Should I log that as a
bug against Controls?

Re: How to raise JavaFX iOS bugs?

2013-08-09 Thread Daniel Zwolenski

Is there going to be an answer on what JVM is going to be used for the JavaOne 
iOS demo?

I'd also like to know what JVM you are testing on for these fixes? 


On 10/08/2013, at 12:46 AM, steve.x.northo...@oracle.com wrote:

> 
> On 08/08/2013 6:08 PM, Daniel Zwolenski wrote:
>> No, I didn't get a chance. Probably easier for you to just raise it now?
> 
> See https://javafx-jira.kenai.com/browse/RT-32237
> 
>> 
>> It's going to be a pretty big round loop to get ios fixes in. It first needs 
>> to go into jfx then needs to be merged into the backport, then that needs to 
>> be deployed to maven, then the maven plugin needs to be updated to refer to 
>> the new version, then the maven plugin needs to be deployed to maven.
>> 
>> I could simplify the last step by allowing the version of jfx backport to be 
>> configurable.
>> 
>> As I've raised in previous emails, help would be good. I don't suppose any 
>> oracle people could be allocated to merging changed into the backport on a 
>> regular basis (eg weekly) - even on an unofficial, non-publicly-commited 
>> arrangement?
>> 
>> 
>> On 09/08/2013, at 7:38 AM, steve.x.northo...@oracle.com wrote:
>> 
>>> Hi Daniel,
>>> 
>>> Did you log a bug for the TextField problem?  If you have not done so, 
>>> please do.  If you use "iOS:" as a prefix for the title of the bug and use 
>>> iOS as a label, that should help people find iOS related bugs.  I have a 
>>> fix for the problem you are seeing.  The text skin thinks that because iOS 
>>> has touch, it needs to show resize handles in the text field.
>>> 
>>> Steve
>>> 
>>> On 01/08/2013 6:08 PM, Daniel Zwolenski wrote:
 So now the Maven stuff is working (
 http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/),
 I'm gradually starting to muck around with the iOS stuff.
 
 There are problems - how do I raise them? Should I log JIRAs? Should I
 bring them up here, etc? Will you guys start running jfx on iOS now that
 it's possible and are bug fixes within your allowance to work on given iOS
 is not a supported platform?
 
 For example, in the hello world example, I've included a TextField. When I
 start typing in it on my iPad the field starts changing size to accommodate
 the auto-correction popup, which looks very weird. Should I log that as a
 bug against Controls?
>

hg: openjfx/8/controls/rt: RT-30182 : Indeterminate ProgressIndicators appear to spin anti-clockwise.

Changeset: 2cad03be8d6b
Author:mickf
Date:  2013-08-09 18:42 +0100
URL:   http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2cad03be8d6b

RT-30182 : Indeterminate ProgressIndicators appear to spin anti-clockwise.

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java
! 
modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css

Re: Canvas blowing up (was Re: JavaFX Media issues)

> What would be the performance penalty for using this quick-fix? The 
> clear/fill commands do not
> just clear the command buffer. They also fill the canvas area with a certain 
> color. So in normal
> operation the canvas is always filled twice for each frame, isn't it?

That would be correct. Another option is to add, instead of "clear()" an 
explicit "empty()" method or something that would just blow away the buffer.

Richard

Re: Canvas blowing up (was Re: JavaFX Media issues)

We would still do the fill but we could throw away any buffered commands 
that happened before the fill.


Steve

On 09/08/2013 12:16 PM, Dr. Michael Paus wrote:
What would be the performance penalty for using this quick-fix? The 
clear/fill commands do not
just clear the command buffer. They also fill the canvas area with a 
certain color. So in normal

operation the canvas is always filled twice for each frame, isn't it?


Am 09.08.13 17:23, schrieb Richard Bair:

I mean, it looks like it is working for a few seconds,
but then as the memory fills with the Canvas backlog it can lead to 
the GC
using a lot more CPU, thus reducing the ability for Canvas to 
process its
command queue even further, well it just collapses in on itself  and 
dies.

Forking the thread.

The problem with Canvas is that if you have a canvas and you scribble 
on it, and then scribble on it some more, and then scribble on it 
some more, then in order for us to get the right result in the end, 
we need to replay all those scribbles in order. If pulses are not 
happening, we still need to remember these scribbles so we can draw 
the right result.


BUT, if you issue a command to the canvas which will cause it to 
"clear" all its contents, then we could throw away any previously 
buffered data. Right now the only way to do that would be a fillRect 
with a solid fill where the fillRect encompasses the entire canvas 
area, or a clearRect where the clearRect encompasses the entire 
canvas area.


This seems like a very simple fix. GraphicsContext.clearRect and 
GraphicsContext.fillRect should both (under the right conditions) 
throw away the previously buffered commands. Then all you have to do 
is be sure to make one of these calls (likely just a clearRect) 
before each frame, and we'll never buffer more than a single frame's 
worth of data. We could also add a "clear" method which is 
"clearRect(0, 0, w, h)" to make this more foolproof, and then 
document it as a best practice to clear the canvas before each 
rendering if you intend to redraw the entire thing on each frame.


If you're making use of manually operated "dirty rects" so that you 
only clear the damaged area to repaint, then we couldn't employ this 
technique and we'd have to buffer 'till kingdom come. So we still 
need a mechanism exposed in the scene graph of "liveness" and 
associated events so that when the scene is no longer live (for 
example, when minimized) you could stop your animation timer, but for 
your specific media use case this isn't as important.


Richard

Re: Canvas blowing up (was Re: JavaFX Media issues)

> That's okay for a quick hack.  In the case of a video preview surface, I will 
> be explicitly setting the value for every pixel from a ByteBuffer.  You could 
> save the extra step of doing a rectFill or clearRect if you knew that every 
> pixel was about to be overwritten.  It's a reasonable optimization.. but as a 
> fix for this issue it's still only a half-fix hack.

I wouldn't call it a hack, just an obvious optimization that would happen to 
help in this case.

> "If pulses are not happening, we still need to remember these scribbles so we 
> can draw the right result."
> 
> No.  If pulses are not happening you need to block or force a pulse somehow. 
> Otherwise I don't see how having the unbounded queue is ever going to be 100% 
> reliable.

I agree it would be better to render the thing. We still need a way to tell 
people that what they're doing isn't visible so they can stop their timer or 
whatnot to avoid wasted CPU cycles / battery drain.

> Since we are talking about painting to the Canvas surface as opposed to 
> directly modifying the scene graph, why does the painting have to happen 
> "later" when a pulse occurs?  It's not like you have any other thread writing 
> to the Canvas.  Why can't the Platform thread actually *do* the scribbles,and 
> the pulse just refreshes the portion of the Canvas that is visible on the 
> screen?  Is it some D3D/OpenGL multi-threading complication?

No doubt drawing to the actual screen in this case won't work (since the 
surface is likely "lost"), but if we're doing double buffering then we should 
still be able to draw to the texture. There might be nasty details to work 
through (windows / graphics guys?). At the high level we short-cut out of doing 
a pulse if the window is not actually visible so we don't waste CPU resources, 
but from a high level it would be easy enough to keep track of whether we have 
dirty canvas' and need to render them anyway. I don't know about the low levels 
whether they would blow up.

Richard

Re: Canvas blowing up (was Re: JavaFX Media issues)

2013-08-09 Thread Scott Palmer

That's okay for a quick hack.  In the case of a video preview surface, I
will be explicitly setting the value for every pixel from a ByteBuffer.
 You could save the extra step of doing a rectFill or clearRect if you knew
that every pixel was about to be overwritten.  It's a reasonable
optimization.. but as a fix for this issue it's still only a half-fix hack.

"If pulses are not happening, we still need to remember these scribbles so
we can draw the right result."

No.  If pulses are not happening you need to block or force a pulse
somehow. Otherwise I don't see how having the unbounded queue is ever going
to be 100% reliable.

Since we are talking about painting to the Canvas surface as opposed to
directly modifying the scene graph, why does the painting have to happen
"later" when a pulse occurs?  It's not like you have any other thread
writing to the Canvas.  Why can't the Platform thread actually *do* the
scribbles,and the pulse just refreshes the portion of the Canvas that is
visible on the screen?  Is it some D3D/OpenGL multi-threading complication?

Regards,

Scott



On Fri, Aug 9, 2013 at 11:43 AM,  wrote:

> This is a great idea.  We should just enter a tweak and do it.  If the
> area that is being cleared is larger than the current size of the canvas,
> we can throw away all pending draw commands.
>
> Steve
>
>
> On 09/08/2013 11:23 AM, Richard Bair wrote:
>
>> I mean, it looks like it is working for a few seconds,
>>> but then as the memory fills with the Canvas backlog it can lead to the
>>> GC
>>> using a lot more CPU, thus reducing the ability for Canvas to process its
>>> command queue even further, well it just collapses in on itself  and
>>> dies.
>>>
>> Forking the thread.
>>
>> The problem with Canvas is that if you have a canvas and you scribble on
>> it, and then scribble on it some more, and then scribble on it some more,
>> then in order for us to get the right result in the end, we need to replay
>> all those scribbles in order. If pulses are not happening, we still need to
>> remember these scribbles so we can draw the right result.
>>
>> BUT, if you issue a command to the canvas which will cause it to "clear"
>> all its contents, then we could throw away any previously buffered data.
>> Right now the only way to do that would be a fillRect with a solid fill
>> where the fillRect encompasses the entire canvas area, or a clearRect where
>> the clearRect encompasses the entire canvas area.
>>
>> This seems like a very simple fix. GraphicsContext.clearRect and
>> GraphicsContext.fillRect should both (under the right conditions) throw
>> away the previously buffered commands. Then all you have to do is be sure
>> to make one of these calls (likely just a clearRect) before each frame, and
>> we'll never buffer more than a single frame's worth of data. We could also
>> add a "clear" method which is "clearRect(0, 0, w, h)" to make this more
>> foolproof, and then document it as a best practice to clear the canvas
>> before each rendering if you intend to redraw the entire thing on each
>> frame.
>>
>> If you're making use of manually operated "dirty rects" so that you only
>> clear the damaged area to repaint, then we couldn't employ this technique
>> and we'd have to buffer 'till kingdom come. So we still need a mechanism
>> exposed in the scene graph of "liveness" and associated events so that when
>> the scene is no longer live (for example, when minimized) you could stop
>> your animation timer, but for your specific media use case this isn't as
>> important.
>>
>> Richard
>>
>
>

Re: Canvas blowing up (was Re: JavaFX Media issues)

2013-08-09 Thread Dr. Michael Paus

What would be the performance penalty for using this quick-fix? The
clear/fill commands do not
just clear the command buffer. They also fill the canvas area with a
certain color. So in normal

operation the canvas is always filled twice for each frame, isn't it?

Am 09.08.13 17:23, schrieb Richard Bair:

Forking the thread.

Richard

Re: Mailing list woes

The thing that I'm always burned by is when replies come back out of order. 
Sometimes I even get my own replies to myself before the original message!

On Aug 9, 2013, at 5:45 AM, Felix Bembrick  wrote:

> I am not sure who this is directed at but there seem to be some glitches in
> the mailing list software that manages this list.
> 
> I notice that sometimes when I post to this list I do not always get that
> message being sent to me via the list so I was wondering if I am actually
> receiving every message that is posted to the list.  I compared notes with
> a friend of mine who also subscribes to this list and we analysed the posts
> that we had both received over the past week.
> 
> To both of our surprise we discovered that I received some posts that he
> never received and vice versa.  There does not appear to be any pattern as
> to which posts make it into our inboxes and which don't.
> 
> I'd say we are both receiving about 19 out of every 20 messages or slightly
> less than that.  We definitely established that neither of us has received
> *every* message sent to the list.
> 
> We have also all but ruled out spam filter issues as this is my Gmail
> account and all spam goes into the Spam folder and they certainly haven't
> been ending up in there.  Similarly he has a POP3 account and actually has
> opted to receive *all* spam sent to him which he then uses an Outlook
> message rule to place it in his Junk folder.
> 
> Is anyone else experiencing this?  If you are, you probably don't realise
> it. I only noticed because a couple of my posts didn't come back from the
> list.
> 
> Felix

Re: Canvas blowing up (was Re: JavaFX Media issues)

This is a great idea. We should just enter a tweak and do it. If the
area that is being cleared is larger than the current size of the
canvas, we can throw away all pending draw commands.

Steve

On 09/08/2013 11:23 AM, Richard Bair wrote:

Forking the thread.

Richard

Re: Mailing list woes

Maybe the discuss (http://mail.openjdk.java.net/mailman/listinfo/discuss) 
mailing list is the right place?

Richard

On Aug 9, 2013, at 5:45 AM, Felix Bembrick  wrote:

> I am not sure who this is directed at but there seem to be some glitches in
> the mailing list software that manages this list.
> 
> I notice that sometimes when I post to this list I do not always get that
> message being sent to me via the list so I was wondering if I am actually
> receiving every message that is posted to the list.  I compared notes with
> a friend of mine who also subscribes to this list and we analysed the posts
> that we had both received over the past week.
> 
> To both of our surprise we discovered that I received some posts that he
> never received and vice versa.  There does not appear to be any pattern as
> to which posts make it into our inboxes and which don't.
> 
> I'd say we are both receiving about 19 out of every 20 messages or slightly
> less than that.  We definitely established that neither of us has received
> *every* message sent to the list.
> 
> We have also all but ruled out spam filter issues as this is my Gmail
> account and all spam goes into the Spam folder and they certainly haven't
> been ending up in there.  Similarly he has a POP3 account and actually has
> opted to receive *all* spam sent to him which he then uses an Outlook
> message rule to place it in his Junk folder.
> 
> Is anyone else experiencing this?  If you are, you probably don't realise
> it. I only noticed because a couple of my posts didn't come back from the
> list.
> 
> Felix

Re: JavaFX Media issues

Forwarded from Kiriil Kirichenko who is getting his mailing list credentials 
sorted out...

>> *From: *Felix Bembrick > >
>> *Subject: **JavaFX Media issues*
>> *Date: *August 8, 2013 1:31:37 PM PDT
>> *To: *"openjfx-dev@openjdk.java.net
>>  List"
>> mailto:openjfx-dev@openjdk.java.net>>
>> 
>> I am having a look at JavaFX media support and have a couple of questions:
>> 
>> 1. It seems that the only way to load media files is by specifying a
>> source
>> such as a file path etc.  This is not going to work well for me as all of
>> my application's content (which includes data, digital assets, media etc.)
>> is stored in a database on the server and is loaded through an IO stream.
>> Why doesn't Media support loading of files through a stream?  That would
>> seem like a common use case to me!

This is correct. So called arbitrary input stream support is among the features 
for the future.

>> 2. I am unable to locate any reference to JavaFX Media in the JavaDocs for
>> JDK 8 which I found here:
>> 
>> http://download.java.net/jdk8/jfxdocs/index.html
>> 
>> Is this just a glitch?

A glitch related to javadoc execution. FXMedia is still there.

>> 3. Is buffering of media something planned for the future in JavaFX?

What do you mean by buffering ? We have progressive buffer for http links. See 
MediaPlayer.bufferProgressTimeProperty

>> 4. What about live streaming of media content?

We support Http Live Streaming: MpegTS which contains H264 + AAC.

hg: openjfx/8/graphics/rt: SW pipeline: fix for RT-32227 - setContentWidth + setContentHeight functions on SWTexture

Changeset: 4873e7422e65
Author:Martin Soch 
Date:  2013-08-09 17:30 +0200
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4873e7422e65

SW pipeline: fix for RT-32227 - setContentWidth + setContentHeight functions on 
SWTexture

! modules/graphics/src/main/java/com/sun/prism/sw/SWArgbPreTexture.java
! modules/graphics/src/main/java/com/sun/prism/sw/SWMaskTexture.java
! modules/graphics/src/main/java/com/sun/prism/sw/SWTexture.java

Re: Canvas blowing up (was Re: JavaFX Media issues)

https://javafx-jira.kenai.com/browse/RT-32242

On Aug 9, 2013, at 8:23 AM, Richard Bair  wrote:

>> I mean, it looks like it is working for a few seconds,
>> but then as the memory fills with the Canvas backlog it can lead to the GC
>> using a lot more CPU, thus reducing the ability for Canvas to process its
>> command queue even further, well it just collapses in on itself  and dies.
> 
> Forking the thread.
> 
> The problem with Canvas is that if you have a canvas and you scribble on it, 
> and then scribble on it some more, and then scribble on it some more, then in 
> order for us to get the right result in the end, we need to replay all those 
> scribbles in order. If pulses are not happening, we still need to remember 
> these scribbles so we can draw the right result.
> 
> BUT, if you issue a command to the canvas which will cause it to "clear" all 
> its contents, then we could throw away any previously buffered data. Right 
> now the only way to do that would be a fillRect with a solid fill where the 
> fillRect encompasses the entire canvas area, or a clearRect where the 
> clearRect encompasses the entire canvas area.
> 
> This seems like a very simple fix. GraphicsContext.clearRect and 
> GraphicsContext.fillRect should both (under the right conditions) throw away 
> the previously buffered commands. Then all you have to do is be sure to make 
> one of these calls (likely just a clearRect) before each frame, and we'll 
> never buffer more than a single frame's worth of data. We could also add a 
> "clear" method which is "clearRect(0, 0, w, h)" to make this more foolproof, 
> and then document it as a best practice to clear the canvas before each 
> rendering if you intend to redraw the entire thing on each frame.
> 
> If you're making use of manually operated "dirty rects" so that you only 
> clear the damaged area to repaint, then we couldn't employ this technique and 
> we'd have to buffer 'till kingdom come. So we still need a mechanism exposed 
> in the scene graph of "liveness" and associated events so that when the scene 
> is no longer live (for example, when minimized) you could stop your animation 
> timer, but for your specific media use case this isn't as important.
> 
> Richard

Canvas blowing up (was Re: JavaFX Media issues)

> I mean, it looks like it is working for a few seconds,
> but then as the memory fills with the Canvas backlog it can lead to the GC
> using a lot more CPU, thus reducing the ability for Canvas to process its
> command queue even further, well it just collapses in on itself  and dies.

Forking the thread.

The problem with Canvas is that if you have a canvas and you scribble on it, 
and then scribble on it some more, and then scribble on it some more, then in 
order for us to get the right result in the end, we need to replay all those 
scribbles in order. If pulses are not happening, we still need to remember 
these scribbles so we can draw the right result.

BUT, if you issue a command to the canvas which will cause it to "clear" all 
its contents, then we could throw away any previously buffered data. Right now 
the only way to do that would be a fillRect with a solid fill where the 
fillRect encompasses the entire canvas area, or a clearRect where the clearRect 
encompasses the entire canvas area.

This seems like a very simple fix. GraphicsContext.clearRect and 
GraphicsContext.fillRect should both (under the right conditions) throw away 
the previously buffered commands. Then all you have to do is be sure to make 
one of these calls (likely just a clearRect) before each frame, and we'll never 
buffer more than a single frame's worth of data. We could also add a "clear" 
method which is "clearRect(0, 0, w, h)" to make this more foolproof, and then 
document it as a best practice to clear the canvas before each rendering if you 
intend to redraw the entire thing on each frame.

If you're making use of manually operated "dirty rects" so that you only clear 
the damaged area to repaint, then we couldn't employ this technique and we'd 
have to buffer 'till kingdom come. So we still need a mechanism exposed in the 
scene graph of "liveness" and associated events so that when the scene is no 
longer live (for example, when minimized) you could stop your animation timer, 
but for your specific media use case this isn't as important.

Richard

hg: openjfx/8/graphics/rt: SWT glass: fix defaults to potentially enable live resize on other platforms

Changeset: 4618b11c75f9
Author:snorthov
Date:  2013-08-09 10:43 -0400
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4618b11c75f9

SWT glass: fix defaults to potentially enable live resize on other platforms

! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java

Re: How to raise JavaFX iOS bugs?



On 08/08/2013 6:08 PM, Daniel Zwolenski wrote:

No, I didn't get a chance. Probably easier for you to just raise it now?


See https://javafx-jira.kenai.com/browse/RT-32237



It's going to be a pretty big round loop to get ios fixes in. It first needs to 
go into jfx then needs to be merged into the backport, then that needs to be 
deployed to maven, then the maven plugin needs to be updated to refer to the 
new version, then the maven plugin needs to be deployed to maven.

I could simplify the last step by allowing the version of jfx backport to be 
configurable.

As I've raised in previous emails, help would be good. I don't suppose any 
oracle people could be allocated to merging changed into the backport on a 
regular basis (eg weekly) - even on an unofficial, non-publicly-commited 
arrangement?


On 09/08/2013, at 7:38 AM, steve.x.northo...@oracle.com wrote:


Hi Daniel,

Did you log a bug for the TextField problem?  If you have not done so, please do.  If you 
use "iOS:" as a prefix for the title of the bug and use iOS as a label, that 
should help people find iOS related bugs.  I have a fix for the problem you are seeing.  
The text skin thinks that because iOS has touch, it needs to show resize handles in the 
text field.

Steve

On 01/08/2013 6:08 PM, Daniel Zwolenski wrote:

So now the Maven stuff is working (
http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/),
I'm gradually starting to muck around with the iOS stuff.

There are problems - how do I raise them? Should I log JIRAs? Should I
bring them up here, etc? Will you guys start running jfx on iOS now that
it's possible and are bug fixes within your allowance to work on given iOS
is not a supported platform?

For example, in the hello world example, I've included a TextField. When I
start typing in it on my iPad the field starts changing size to accommodate
the auto-correction popup, which looks very weird. Should I log that as a
bug against Controls?

Re: Mailing list woes

2013-08-09 Thread Jeff Martin


> I only noticed because a couple of my posts didn't come back from the list.



I've noticed this, too. Perhaps the list is losing things to a junk filter.

jeff


On Aug 9, 2013, at 7:45 AM, Felix Bembrick  wrote:

> I am not sure who this is directed at but there seem to be some glitches in
> the mailing list software that manages this list.
> 
> I notice that sometimes when I post to this list I do not always get that
> message being sent to me via the list so I was wondering if I am actually
> receiving every message that is posted to the list.  I compared notes with
> a friend of mine who also subscribes to this list and we analysed the posts
> that we had both received over the past week.
> 
> To both of our surprise we discovered that I received some posts that he
> never received and vice versa.  There does not appear to be any pattern as
> to which posts make it into our inboxes and which don't.
> 
> I'd say we are both receiving about 19 out of every 20 messages or slightly
> less than that.  We definitely established that neither of us has received
> *every* message sent to the list.
> 
> We have also all but ruled out spam filter issues as this is my Gmail
> account and all spam goes into the Spam folder and they certainly haven't
> been ending up in there.  Similarly he has a POP3 account and actually has
> opted to receive *all* spam sent to him which he then uses an Outlook
> message rule to place it in his Junk folder.
> 
> Is anyone else experiencing this?  If you are, you probably don't realise
> it. I only noticed because a couple of my posts didn't come back from the
> list.
> 
> Felix

hg: openjfx/8/controls/rt: 2 new changesets

Changeset: 53570eadb90b
Author:David Grieve
Date:  2013-08-09 09:20 -0400
URL:   http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/53570eadb90b

RT-31691: if css is being reapplied but we're using cached values, force a 
lookup on properties not in the cache

! modules/controls/src/main/java/javafx/scene/control/Control.java
! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java
! modules/graphics/src/main/java/javafx/scene/Node.java

Changeset: ef2ca9c96bc5
Author:David Grieve
Date:  2013-08-09 09:21 -0400
URL:   http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ef2ca9c96bc5

Automated merge with 
ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt

Mailing list woes

2013-08-09 Thread Felix Bembrick

I am not sure who this is directed at but there seem to be some glitches in
the mailing list software that manages this list.

I notice that sometimes when I post to this list I do not always get that
message being sent to me via the list so I was wondering if I am actually
receiving every message that is posted to the list.  I compared notes with
a friend of mine who also subscribes to this list and we analysed the posts
that we had both received over the past week.

To both of our surprise we discovered that I received some posts that he
never received and vice versa.  There does not appear to be any pattern as
to which posts make it into our inboxes and which don't.

I'd say we are both receiving about 19 out of every 20 messages or slightly
less than that.  We definitely established that neither of us has received
*every* message sent to the list.

We have also all but ruled out spam filter issues as this is my Gmail
account and all spam goes into the Spam folder and they certainly haven't
been ending up in there.  Similarly he has a POP3 account and actually has
opted to receive *all* spam sent to him which he then uses an Outlook
message rule to place it in his Junk folder.

Is anyone else experiencing this?  If you are, you probably don't realise
it. I only noticed because a couple of my posts didn't come back from the
list.

Felix

hello and macosx build trouble

2013-08-09 Thread René Jansen

Hello,
let me first introduce myself as this is my first post on this list. I am 
working on integrating jsr223 support in the netrexx 3.03 compiler/interpreter  
(www.netrexx.org) and I am testing with (apart from netrexx code itself of 
course) Nashorn and I want to add some examples of how to script JavaFX in 
addition to using JavaFX in compiled code. For both I need a working JavaFx 
installation, and I chose the path of building it myself (which most of the 
time leads to better understanding. I started with building OpenJDK 8, and 
apart from the need to unset my classpath first (as I found out) and edit the 
gcc.make file of hotspot, this succeeded.

Now I am trying to build OpenJFX. I have gone past the hurdle of the Gradle 
buiildfile requiring a JDK build number larger than 100 - I set this to 0 and 
it happily trucks on - but now if have hit a showstopper that I need your help 
with. These is the complete message stream I receive:


The ConfigurationContainer.add() method has been deprecated and is scheduled to 
be removed in Gradle 2.0. Please use the create() method instead.
:buildSrc:generateGrammarSource UP-TO-DATE
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy UP-TO-DATE
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes UP-TO-DATE
:buildSrc:jar UP-TO-DATE
:buildSrc:assemble UP-TO-DATE
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test
:buildSrc:check
:buildSrc:build
Missing or incorrect path to 'jfxrt.jar': 
'/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/jfxrt.jar'.
 Perhaps bad JDK_HOME? 
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
Unsupported gradle version 1.6 in use. Only 1.4 is supported
OS_NAME: mac os x
OS_ARCH: x86_64
JAVA_HOME: /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
JDK_HOME: /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
java.runtime.version: 1.8.0-internal-rvjansen_2013_08_01_16_03-b00
java version: 1.8.0
java build number: 00
minimum java build number: 0
COMPILE_TARGETS: mac
COMPILE_FLAGS_FILES: buildSrc/mac.gradle
BINARY_STUB: 
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/jfxrt.jar
HUDSON_JOB_NAME: not_hudson
HUDSON_BUILD_NUMBER: 
PROMOTED_BUILD_NUMBER: 00
PRODUCT_NAME: OpenJFX
RAW_VERSION: 8.0.0
RELEASE_NAME: 8.0
RELEASE_MILESTONE: ea
UPDATE_STUB_CACHE: false
The CompileOptions.useAnt property has been deprecated and is scheduled to be 
removed in Gradle 2.0. There is no replacement for this property.
:checkJfxrtJar
:updateCacheIfNeeded UP-TO-DATE
:verifyJava
:base:processVersionInfo UP-TO-DATE
:base:compileJava UP-TO-DATE
:base:processResources UP-TO-DATE
:base:classes UP-TO-DATE
:base:jar UP-TO-DATE
:graphics:compileJava

FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all dependencies for configuration ':graphics:compile'.
> Could not find :plugin:.
 Required by:
 rt:graphics:unspecified

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.

BUILD FAILED

Total time: 18.243 secs
===

OSX is 10.8.4, Xcode is up to date.

Anyone able to get me past this?

best regards,

René Jansen.

use custom behavior class for TableView

2013-08-09 Thread Sven Ehrke


Hi, 

I would like to use a custom Behavior class for a TableView and so I started as 
usual with a 'MyTableViewSkin' 
class which I can activate via the css file. In order to reuse functionality of 
'TableViewSkin' and 'TableViewBehavior' I started to 
let ' MyTableViewSkin' inherit from 'TableViewSkin and planned to let it's 
constructor simply call the super constructor like this: 


super(tableView, new MyTableViewBehavior(tableView)); 


Unfortunately 'TableViewSkin' only defines the constructor 


'TableViewSkin(final TableView tableView) ' 


and thus hides the one from ' TableViewSkinBase ' : 


TableViewSkinBase(final C control, final B behavior) 


which makes it impossible to call it. 
Was this done on purpose and if yes how am I supposed to attach a custom 
behavior class ? 




Thanks! 


Regards, 
Sven

hg: openjfx/8/graphics/rt: Android: RT-32218 Add TextField and TextArea skins for Android.

Changeset: 5963868d92d9
Author:tb115823 
Date:  2013-08-09 11:21 +0200
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5963868d92d9

Android: RT-32218 Add TextField and TextArea skins for Android.

! build.gradle
! buildSrc/android.gradle
+ 
modules/controls/src/android/java/com/sun/javafx/scene/control/skin/TextAreaSkinAndroid.java
+ 
modules/controls/src/android/java/com/sun/javafx/scene/control/skin/TextFieldSkinAndroid.java
+ 
modules/controls/src/android/resources/com/sun/javafx/scene/control/skin/caspian/android.css
+ 
modules/controls/src/android/resources/com/sun/javafx/scene/control/skin/modena/android.css
! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java
+ netbeans/android/controls/build.xml
+ netbeans/android/controls/manifest.mf
+ netbeans/android/controls/nbproject/build-impl.xml
+ netbeans/android/controls/nbproject/genfiles.properties
+ netbeans/android/controls/nbproject/project.properties
+ netbeans/android/controls/nbproject/project.xml

Re: JavaFX Media issues