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

2013-11-06 Thread hang . vo
Changeset: 03dffb2bdc75
Author:Martin Sladecek 
Date:  2013-11-06 09:16 +0100
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/03dffb2bdc75

RT-34091
Multiple properties in Controls override set() instead of invalidated()
Reviewed-by: jgiles, dgrieve

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/AccordionSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/InputField.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableColumnHeader.java
! modules/controls/src/main/java/javafx/scene/control/Accordion.java
! modules/controls/src/main/java/javafx/scene/control/Control.java
! modules/controls/src/main/java/javafx/scene/control/ListView.java
! modules/controls/src/main/java/javafx/scene/control/PopupControl.java
! modules/controls/src/main/java/javafx/scene/control/TextArea.java
! modules/controls/src/main/java/javafx/scene/control/TextField.java

Changeset: d408298723b6
Author:bae
Date:  2013-11-06 08:37 +
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d408298723b6

RT-17000: Some jpeg files are rendered incorrectly
Reviewed-by: kcr, prr

! modules/graphics/src/main/java/com/sun/javafx/iio/jpeg/JPEGImageLoader.java
! modules/graphics/src/main/native-iio/jpegloader.c
! modules/graphics/src/main/native-iio/libjpeg7/jdcolor.c

Changeset: 7b1fbb71071b
Author:Assaf Yavani
Date:  2013-11-06 13:24 +0200
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7b1fbb71071b

[RT-34045] EGLFB: No move or drag events on simple touch screen
Summary: There were 2 issues:
1) bug in udevInput - wrong if statement that cause a fault parsing of events
2) unit tests errors

Tested-by: updated LinuxInputTest

Reviewed-by: ddhill

! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c

Changeset: 143bcf17d534
Author:Martin Sladecek 
Date:  2013-11-06 12:41 +0100
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/143bcf17d534

RT-34088: SortedList broken when adding new elements to underlying list

! modules/base/src/main/java/javafx/collections/transformation/SortedList.java
! modules/base/src/test/java/javafx/collections/SortedListTest.java

Changeset: 22f48880a877
Author:Assaf Yavani
Date:  2013-11-06 13:50 +0200
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/22f48880a877

[MINOR] RT-33614 Lens:HelloSanity:Controls::ScrollPane jitter when holding the 
finger on the pane
Summary: touch events threshold was to small and caused to many events to be 
send when finger was touching the screen without moving

Tested-by: LinuxInputTest

Reviewed-by:  dblaukop ddhill

! 
modules/graphics/src/main/java/com/sun/glass/ui/lens/LensTouchInputSupport.java
! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c

Changeset: f4081e2d5c83
Author:Anthony Petrov 
Date:  2013-11-06 17:18 +0400
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f4081e2d5c83

RT-33352: Win: Image and html cannot be dnd or clipboarded at the same time.
Reviewed-by: snorthov

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

Changeset: 6f4354f6bd7d
Author:Felipe Heidrich 
Date:  2013-11-06 08:26 -0800
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6f4354f6bd7d

RT-33971: [Graphics, Text] Alignment not work in win7
Reviewed-by: Kevin Rushforth

! modules/graphics/src/main/java/com/sun/javafx/text/GlyphLayout.java



RE: Serializing JFXPanel with java.beans.XMLEncoder

2013-11-06 Thread Lidierth, Malcolm
OK - the original null pointer exception was because of the issue with WebView 
that is now on JIRA.

I now get a more easily understood exception:

java.lang.NoSuchMethodException: javafx.scene.Scene.()javafx.scene.Scene

as Scene has no null constructor.

So I guess my question now relates to optimism: the beans encoder handles 
JFXPanel fine, but
am I right that  I will need to populate that JFXPanel by writing my own 
classes/delegates to create the scene - and that standard FX components do not 
have ready-made delegates as do the Swing components that will be invoked 
through the get/set methods using a default persistence delegate? I guess that 
would be asking a lot.





From: Artem Ananiev 
Sent: Tuesday, November 05, 2013 5:21 PM
To: Lidierth, Malcolm
Cc: openjfx-dev@openjdk.java.net
Subject: Re: Serializing JFXPanel with java.beans.XMLEncoder

Hi, Lidierth,

could you provide the exception stack trace, please? It would help to
understand whether you're over-optimistic or not :)

Thanks,

Artem

On 11/5/2013 9:14 PM, Lidierth Malcolm wrote:
> When I add a JFXPanel to a Swing hierarchy that is then written to XML
> using java.beans.XMLEncoder, all is well as long as the JFXPanel is empty.
> When it has content, I see a NullPointerException.
>
> Before I dig into the origins, am I being over-optimistic? : should I
> expect java.beans.XMLEncoder to cope here?
>
> ML
>

Re: Use ScenePulseListener to avoid expensive recalculations?

2013-11-06 Thread Yennick Trevels
Isn't it somewhat counter-intuitive to perform such changes in one of the
computePref*() methods? You're adding children in a method which is
supposed to compute the preferred width/height.

There should be a better way to do this. In Apache Flex for example,
there's a commitProperties() and updateDisplayList() method in which you
can do these things, which are called somewhat similar to a pulse in JavaFx
(except that you have to invalidate them yourself).


On Tue, Nov 5, 2013 at 8:10 PM, Jonathan Giles wrote:

> You're right in that controls don't tend to use ScenePulseListener. This
> may be due to an oversight on our part, or just that our requirements
> differ (I don't honestly know).
>
> You're also right that it is important to batch up property changes and
> do them once per pulse, rather than as they come in. If this is not done
> you do indeed get a severe performance hit (I remember back in the day
> before I optimised many of the controls in this way, the performance
> impact of not doing this was staggering).
>
> The way I do it is simple: in places where I receive events from
> properties / bindings / listeners, where I know that there is
> potentially a lot of changes coming through, I create a boolean (e.g.
> 'refreshView' or somesuch). I then set this boolean to true, and in the
> appropriate place in the code (most commonly layoutChildren(), but
> sometimes in the computePref*() methods), I start the method with code
> like this:
>
> if (refreshView) {
> doExpensiveOperationThatShouldHappenOnlyOncePerPulse();
> refreshView = false;
> }
>
> The reason why I sometimes use layoutChildren() and sometimes the
> computePref*() methods comes down to the (new) rule in JavaFX 8.0 that
> you can not change the children list of a node within the
> layoutChildren() method. Because of this, if I need to modify the
> children list, I put the above code in the computePref*() method.
>
> I hope that helps.
>
> -- Jonathan
>
> On 6/11/2013 3:58 a.m., John Hendrikx wrote:
> > Hi List,
> >
> > I'm considering using a ScenePulseListener to avoid expensive
> > recalculations when multiple bindings trigger an action.
> >
> > My problem is this:
> >
> > I like to build Views (Controls) that are dumb and expose properties
> > that can be manipulated by whatever is using the View.  The View
> > listens to its own Properties and adjusts its state accordingly.  Some
> > of these adjustments are related (like width + height) and can be
> > expensive when calculated immediately.  So I would like to mark the
> > View as "invalid" and recalculate its state (if invalid) on the next
> > Pulse.
> >
> > My current use case I'm looking at is a View that wraps (amongst
> > others) a TreeView.  The View exposes an ObservableList and a
> > BooleanProperty that decides whether the first level of the Tree
> > should be displayed as Tabs or as Nodes (which has an impact on what
> > Nodes actually are added to the TreeView, and which are added as
> > Tabs).  User code will thus often set a new list of nodes + change the
> > boolean to show tabs or nodes.  The View currently naively has
> > InvalidationListeners on both of these properties which cause
> > TreeNodes to be created after the first change... then discarded and
> > recreated after the second change by the user code, ie:
> >
> >   view.nodesProperty().setAll(nodes);   // Recreates all
> > Tabs/TreeNodes with the current value of expand top level, as we donot
> > know another change might be incoming...
> >   view.expandTopLevelProperty().set(false);   // Recreates all
> > Tabs/TreeNodes again if expand top level was changed...
> >
> > This specific problem might be done in a better way, but the point
> > remains, how do I avoid expensive calculations when multiple
> > properties get changed one after the other by the user code?  I'm
> > assuming that JavaFX controls already avoid these kinds of things, and
> > I'd like to know whether using a ScenePulseListener is the way to go,
> > or that it can/should be done in a different way -- examining the code
> > for TreeView (and its superclasses), I couldn't find uses of
> > ScenePulseListener...
> >
> > --John
> >
> >
> >
> >
>
>


did anyone encountered this?

2013-11-06 Thread Assaf Yavnai

:apps:experiments:3DViewer:compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':apps:experiments:3DViewer:compileJava'.
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 18

* 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: 39.292 secs
assaf@assaf-Latitude-E6410:~/ws/udev-refactoring/rt$ java -versionjava 
version "1.8.0-ea"

Java(TM) SE Runtime Environment (build 1.8.0-ea-b113)
Java HotSpot(TM) Server VM (build 25.0-b55, mixed mode)

Thanks,
Assaf


Re: did anyone encountered this?

2013-11-06 Thread Artem Ananiev


Yes, I've seen this many times. I didn't spend much time trying to 
understand what is the problem, though. The workaround is simple: just 
delete 3DViewer "build" folder.


Thanks,

Artem

On 11/6/2013 5:35 PM, Assaf Yavnai wrote:

:apps:experiments:3DViewer:compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':apps:experiments:3DViewer:compileJava'.
 > java.lang.ClassFormatError: Invalid Constant Pool entry Type 18

* 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: 39.292 secs
assaf@assaf-Latitude-E6410:~/ws/udev-refactoring/rt$ java -versionjava
version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b113)
Java HotSpot(TM) Server VM (build 25.0-b55, mixed mode)

Thanks,
Assaf


Re: did anyone encountered this?

2013-11-06 Thread Kevin Rushforth
I see this from time to time. This is a bug in the version of ant that 
is used by gradle for dependencies. It has been reported that gradle 1.8 
may have a newer version of ant that fixes this bug.


In the mean time, a less intrusive workaround is:

   gradle -PUSE_DEPEND=false ...

If enough people are getting bitten by this, should we consider making 
USE_DEPEND=false the default?


-- Kevin


Artem Ananiev wrote:


Yes, I've seen this many times. I didn't spend much time trying to 
understand what is the problem, though. The workaround is simple: just 
delete 3DViewer "build" folder.


Thanks,

Artem

On 11/6/2013 5:35 PM, Assaf Yavnai wrote:

:apps:experiments:3DViewer:compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':apps:experiments:3DViewer:compileJava'.
 > java.lang.ClassFormatError: Invalid Constant Pool entry Type 18

* 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: 39.292 secs
assaf@assaf-Latitude-E6410:~/ws/udev-refactoring/rt$ java -versionjava
version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b113)
Java HotSpot(TM) Server VM (build 25.0-b55, mixed mode)

Thanks,
Assaf


hg: openjfx/8/graphics/rt: SW pipeline: fix for perf. regression in image rendering (RT-34076)

2013-11-06 Thread hang . vo
Changeset: 1cbc110be452
Author:Martin Soch 
Date:  2013-11-06 18:51 +0100
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1cbc110be452

SW pipeline: fix for perf. regression in image rendering (RT-34076)

! modules/graphics/src/main/native-prism-sw/PiscesPaint.c



Re: JFXPanel with WebView in JDK8

2013-11-06 Thread Artem Ananiev

Hi, Lidierth,

what JDK8 version do you run your app? This exception is expected, when 
an old JDK8 build is used.


Thanks,

Artem

On 11/5/2013 11:37 PM, Lidierth Malcolm wrote:


NOTE: THIS EXCEPTION OCCURS WITH JDK8, BUT NOT WITH JDK7

public class NewFXMain1 {

 public static void main(String[] args) throws InterruptedException,
InvocationTargetException {

 EventQueue.invokeAndWait(new Runnable() {

 // Create the Swing components on the EDT
 @Override
 public void run() {
 JFrame f = new JFrame();
 f.getContentPane().setPreferredSize(new Dimension(500,
500));
 f.pack();
 f.setVisible(true);
 final JFXPanel jfx = new JFXPanel();
 f.getContentPane().add(jfx);

 // FX Thread
 Platform.runLater(new Runnable() {
 @Override
 public void run() {
 WebView browser = new WebView();
 WebEngine webEngine = browser.getEngine();
 // This is a reference to a web page on the
Waterloo web site
webEngine.load("http://waterloo.sourceforge.net/devwebpage/MathJax/mathjax.html";);

 Scene s = new Scene(browser);
 jfx.setScene(s);
 }
 });

 }
 });
 }
}


This gives (Note: using JDK8 and Running from NetBeans 7.4):

Executing
C:\Users\malcolm\Documents\waterloo\Sources\Java\kcl-waterloo-jfx\dist\run1852659813\kcl-waterloo-jfx.jar
using platform C:\Program Files\Java\jdk1.8.0/bin/java
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
 at
javafx.embed.swing.JFXPanel.getInputMethodRequests(JFXPanel.java:744)
 at
sun.awt.im.InputMethodAdapter.haveActiveClient(InputMethodAdapter.java:61)
 at sun.awt.windows.WInputMethod.activate(WInputMethod.java:285)
 at sun.awt.im.InputContext.activateInputMethod(InputContext.java:396)
 at sun.awt.im.InputContext.focusGained(InputContext.java:338)
 at sun.awt.im.InputContext.dispatchEvent(InputContext.java:245)
 at
sun.awt.im.InputMethodContext.dispatchEvent(InputMethodContext.java:196)
 at java.awt.Component.dispatchEventImpl(Component.java:4817)
 at java.awt.Container.dispatchEventImpl(Container.java:2293)
 at java.awt.Component.dispatchEvent(Component.java:4707)
 at
java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1954)

 at
java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:986)

 at
java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:610)

 at java.awt.Component.dispatchEventImpl(Component.java:4756)
 at java.awt.Container.dispatchEventImpl(Container.java:2293)
 at java.awt.Component.dispatchEvent(Component.java:4707)
 at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:746)
 at java.awt.EventQueue.access$400(EventQueue.java:97)
 at java.awt.EventQueue$3.run(EventQueue.java:697)
 at java.awt.EventQueue$3.run(EventQueue.java:691)
 at java.security.AccessController.doPrivileged(Native Method)
 at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)

 at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86)

 at java.awt.EventQueue$4.run(EventQueue.java:719)
 at java.awt.EventQueue$4.run(EventQueue.java:717)
 at java.security.AccessController.doPrivileged(Native Method)
 at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)

 at java.awt.EventQueue.dispatchEvent(EventQueue.java:716)
 at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:220)

 at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:135)

 at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:123)

 at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:119)
 at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:111)
 at java.awt.EventDispatchThread.run(EventDispatchThread.java:97)



Re: Use ScenePulseListener to avoid expensive recalculations?

2013-11-06 Thread John Hendrikx

On 5/11/2013 20:10, Jonathan Giles wrote:

You're right in that controls don't tend to use ScenePulseListener. This
may be due to an oversight on our part, or just that our requirements
differ (I don't honestly know).

You're also right that it is important to batch up property changes and
do them once per pulse, rather than as they come in. If this is not done
you do indeed get a severe performance hit (I remember back in the day
before I optimised many of the controls in this way, the performance
impact of not doing this was staggering).

The way I do it is simple: in places where I receive events from
properties / bindings / listeners, where I know that there is
potentially a lot of changes coming through, I create a boolean (e.g.
'refreshView' or somesuch). I then set this boolean to true, and in the
appropriate place in the code (most commonly layoutChildren(), but
sometimes in the computePref*() methods), I start the method with code
like this:

if (refreshView) {
 doExpensiveOperationThatShouldHappenOnlyOncePerPulse();
 refreshView = false;
}

The reason why I sometimes use layoutChildren() and sometimes the
computePref*() methods comes down to the (new) rule in JavaFX 8.0 that
you can not change the children list of a node within the
layoutChildren() method. Because of this, if I need to modify the
children list, I put the above code in the computePref*() method.


I'm not sure in which circumstances layoutChildren() will be called or 
if I can mark my control as needing layout, since the properties I want 
to trigger on are not directly attached to anything that JavaFX will be 
monitoring.  The ScenePulseListener therefore seems like a good choice 
-- the reason I'm asking about is that I cannot find any examples and 
the documentation for it is also pretty lean.


I'll experiment with a ScenePulseListener and see how it pans out, it 
looks like it would be an elegant solution.


Thanks Jonathan!




I hope that helps.

-- Jonathan

On 6/11/2013 3:58 a.m., John Hendrikx wrote:

Hi List,

I'm considering using a ScenePulseListener to avoid expensive
recalculations when multiple bindings trigger an action.

My problem is this:

I like to build Views (Controls) that are dumb and expose properties
that can be manipulated by whatever is using the View.  The View
listens to its own Properties and adjusts its state accordingly.  Some
of these adjustments are related (like width + height) and can be
expensive when calculated immediately.  So I would like to mark the
View as "invalid" and recalculate its state (if invalid) on the next
Pulse.

My current use case I'm looking at is a View that wraps (amongst
others) a TreeView.  The View exposes an ObservableList and a
BooleanProperty that decides whether the first level of the Tree
should be displayed as Tabs or as Nodes (which has an impact on what
Nodes actually are added to the TreeView, and which are added as
Tabs).  User code will thus often set a new list of nodes + change the
boolean to show tabs or nodes.  The View currently naively has
InvalidationListeners on both of these properties which cause
TreeNodes to be created after the first change... then discarded and
recreated after the second change by the user code, ie:

   view.nodesProperty().setAll(nodes);   // Recreates all
Tabs/TreeNodes with the current value of expand top level, as we donot
know another change might be incoming...
   view.expandTopLevelProperty().set(false);   // Recreates all
Tabs/TreeNodes again if expand top level was changed...

This specific problem might be done in a better way, but the point
remains, how do I avoid expensive calculations when multiple
properties get changed one after the other by the user code?  I'm
assuming that JavaFX controls already avoid these kinds of things, and
I'd like to know whether using a ScenePulseListener is the way to go,
or that it can/should be done in a different way -- examining the code
for TreeView (and its superclasses), I couldn't find uses of
ScenePulseListener...

--John








Re: JFXPanel with WebView in JDK8

2013-11-06 Thread Petr Pchelko
Hello, Artem.

> This exception is expected, when an old JDK8 build is used.
Actually I suppose it’s a bug, here’s a JIRA for it: 
https://javafx-jira.kenai.com/browse/RT-34077
I’ll fix it in a couple of days probably.

With best regards. Petr.

On Nov 6, 2013, at 11:53 AM, Artem Ananiev  wrote:

> Hi, Lidierth,
> 
> what JDK8 version do you run your app? This exception is expected, when an 
> old JDK8 build is used.
> 
> Thanks,
> 
> Artem
> 
> On 11/5/2013 11:37 PM, Lidierth Malcolm wrote:
>> 
>> NOTE: THIS EXCEPTION OCCURS WITH JDK8, BUT NOT WITH JDK7
>> 
>> public class NewFXMain1 {
>> 
>> public static void main(String[] args) throws InterruptedException,
>> InvocationTargetException {
>> 
>> EventQueue.invokeAndWait(new Runnable() {
>> 
>> // Create the Swing components on the EDT
>> @Override
>> public void run() {
>> JFrame f = new JFrame();
>> f.getContentPane().setPreferredSize(new Dimension(500,
>> 500));
>> f.pack();
>> f.setVisible(true);
>> final JFXPanel jfx = new JFXPanel();
>> f.getContentPane().add(jfx);
>> 
>> // FX Thread
>> Platform.runLater(new Runnable() {
>> @Override
>> public void run() {
>> WebView browser = new WebView();
>> WebEngine webEngine = browser.getEngine();
>> // This is a reference to a web page on the
>> Waterloo web site
>> webEngine.load("http://waterloo.sourceforge.net/devwebpage/MathJax/mathjax.html";);
>> 
>> Scene s = new Scene(browser);
>> jfx.setScene(s);
>> }
>> });
>> 
>> }
>> });
>> }
>> }
>> 
>> 
>> This gives (Note: using JDK8 and Running from NetBeans 7.4):
>> 
>> Executing
>> C:\Users\malcolm\Documents\waterloo\Sources\Java\kcl-waterloo-jfx\dist\run1852659813\kcl-waterloo-jfx.jar
>> using platform C:\Program Files\Java\jdk1.8.0/bin/java
>> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
>> at
>> javafx.embed.swing.JFXPanel.getInputMethodRequests(JFXPanel.java:744)
>> at
>> sun.awt.im.InputMethodAdapter.haveActiveClient(InputMethodAdapter.java:61)
>> at sun.awt.windows.WInputMethod.activate(WInputMethod.java:285)
>> at sun.awt.im.InputContext.activateInputMethod(InputContext.java:396)
>> at sun.awt.im.InputContext.focusGained(InputContext.java:338)
>> at sun.awt.im.InputContext.dispatchEvent(InputContext.java:245)
>> at
>> sun.awt.im.InputMethodContext.dispatchEvent(InputMethodContext.java:196)
>> at java.awt.Component.dispatchEventImpl(Component.java:4817)
>> at java.awt.Container.dispatchEventImpl(Container.java:2293)
>> at java.awt.Component.dispatchEvent(Component.java:4707)
>> at
>> java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1954)
>> 
>> at
>> java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:986)
>> 
>> at
>> java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:610)
>> 
>> at java.awt.Component.dispatchEventImpl(Component.java:4756)
>> at java.awt.Container.dispatchEventImpl(Container.java:2293)
>> at java.awt.Component.dispatchEvent(Component.java:4707)
>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:746)
>> at java.awt.EventQueue.access$400(EventQueue.java:97)
>> at java.awt.EventQueue$3.run(EventQueue.java:697)
>> at java.awt.EventQueue$3.run(EventQueue.java:691)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at
>> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
>> 
>> at
>> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86)
>> 
>> at java.awt.EventQueue$4.run(EventQueue.java:719)
>> at java.awt.EventQueue$4.run(EventQueue.java:717)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at
>> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
>> 
>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:716)
>> at
>> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:220)
>> 
>> at
>> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:135)
>> 
>> at
>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:123)
>> 
>> at
>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:119)
>> at
>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:111)
>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:97)
>> 



review request RT-34072: TextArea overlaps symbols

2013-11-06 Thread Felipe Heidrich
Hi Steve,


could you please review:
https://javafx-jira.kenai.com/browse/RT-34072
http://cr.openjdk.java.net/~fheidric/RT34072/webrev/

Thanks
Felipe



review request RT-34090: NGRegion border painting seems odd

2013-11-06 Thread Felipe Heidrich
Hi Jim,


Please review
https://javafx-jira.kenai.com/browse/RT-34090
http://cr.openjdk.java.net/~fheidric/RT34090/webrev/

Thanks
Felipe



hg: openjfx/8/graphics/rt: [Eclipse only] use jfxrt.jar from artifacts instead of caches to avoid the need of using ant update-cache

2013-11-06 Thread hang . vo
Changeset: 089c27f969c2
Author:Felipe Heidrich 
Date:  2013-11-06 15:57 -0800
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/089c27f969c2

[Eclipse only] use jfxrt.jar from artifacts instead of caches to avoid the need 
of using ant update-cache

! .classpath



review request RT-34093: complext text are garbled when using some fonts to render the text.

2013-11-06 Thread Felipe Heidrich
Hi Steve,

Please review
http://cr.openjdk.java.net/~fheidric/RT34093/webrev/
https://javafx-jira.kenai.com/browse/RT-34093

Thank you
Felipe



Scene Builder performance regression between 1.1 and 2.0

2013-11-06 Thread Felix Bembrick
Scene Builder 2.0 has very serious performance issues (on my machines at
least).

When running 1.1 & 2.0 side-by-side, 1.1 is very responsive and behaves
very well.  On the contrary, 2.0 is extremely sluggish with a few seconds
between clicking on a control and the selection handles appearing and
trying to resize the properties pane is so slow that it is not usable.

I see this version of Scene Builder was built with JDK8 b112.

Is anyone else experiencing this?  Have I just hit on some subtle
performance issue with JavaFX 8 and the GPU drivers on this machine (which
is Windows 7 64-bit BTW).?

Felix