TableViews Shift+Click multi-selection issues

[Matthew Elliot]

Hi all,

I hope this is an easy question but I haven't been able to find an answer
in the internet.

I have a TreeTable with multi-selection enabled and I am listing to the
selectedItems() property.

When I shift+click with the mouse to select more than 1 row I always first
get notified there are 0 elements due to a clearSelection call inside the
implementation and then notified of the selected elements. (2 calls)

It would seem TreeTable should support this operation atomically (code is
there) but that the way the mouse click bubbles through the table
implementation it does so without triggering the isAtomic() option and
therefore multiple notifications are triggered against selectedItems().

For me this is problematic as the clear has a meaning in the application,
e.g. unselect and I want to happen in some cases but definitely not in this
case. Click unselect vs Shift + Click to multi-select.

Conversely control clicking is fine as it will simply add to the selection.

Is this a bug in the implementation of selection or a misunderstanding on
my end?

In any case, is there an obvious way to work around this whereby in the
shift select case I can make this operation appear atomic even if the
control will not?

Thanks in advance,
Matt

Re: Matrox Graphics Cards Problems

[Matthew Elliot]

Hey Anirvan,

Thanks for the info - guess it’s not such a promising route either then. 

As these Jira for Matrox cards in JavaFX were from 2013 is it possible that 
later Matrox cards / drivers would now work if this global disablement was not 
present. I.e is forceGpu enough to test such scenarios?
Or would I need to create another bug report for investigation at Oracle?

To the wider group, has anyone else outside Oracle contributed code dealing 
with supporting graphics cards?

Would something like implementing a workaround for whatever deficiency is 
present (pixel shaders?! from comments in Bug reports) even be possible / 
practical?

Theoretically this could become an interesting topic for my company if a few 
percent of our users have these types of cards (which is possible) and it could 
be useful to the wider community. 

Kind regards,
Matt

Sent from my phone.

> On 18/05/2018, at 7:09 PM, Anirvan Sarkar <powers.anir...@gmail.com> wrote:
> 
> Hi Matthew,
> 
> OpenGL pipeline on Windows is not a supported configuration and so it is not 
> present in JavaFX for Windows[1][2].
> You would have to build JavaFX yourself to include this pipeline and "use it 
> at your own risk". It may or may not work.
> Also it looks like the card should support OpenGL 2.1 or later[3].
> 
> [1]: 
> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/071b040b8736/build.gradle#l478
> [2]: http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-July/014936.html
> [3]: 
> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/071b040b8736/modules/javafx.graphics/src/main/native-prism-es2/windows/WinGLFactory.c#l252
> 
> 
>> On 18 May 2018 at 04:32, Matthew Elliot <matthew.james.ell...@gmail.com> 
>> wrote:
>> Hey, thanks for the second link, exactly what I needed just not the best 
>> news. 
>> 
>> I see all Matrox cards are disabled which is a bit tricky for us when many 
>> of our customers are have 4+ monitors and some have chosen those cards. 
>> 
>> I then managed to find this - 
>> https://bugs.openjdk.java.net/browse/JDK-8103350
>> I assume this means there will never be support of these cards or is there a 
>> work around? I.e. I see they support OpenGL so could I install OpenGL on a 
>> windows machine and try that pipeline?
>> Is this exclusion of all Matrox cards still valid?
>> 
>> Thanks in advance,
>> Matt
>> 
>> Sent from my phone.
>> 
>>> On 17/05/2018, at 5:15 PM, Anirvan Sarkar <powers.anir...@gmail.com> wrote:
>>> 
>>> Hi Matthew,
>>> 
>>> Please see the below file for blaclisted hardware on D3D. 
>>> 
>>> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/9e0e0e65e642/modules/javafx.graphics/src/main/native-prism-d3d/D3DBadHardware.h
>>> 
>>> Regards,
>>> Anirvan
>>> 
>>> 
>>>> On Thu, 17 May 2018 at 11:04 PM, Matthew Elliot 
>>>> <matthew.james.ell...@gmail.com> wrote:
>>>> Hi all,
>>>> 
>>>> we have some customers in the wild who use Matrox 9148LP (9100 series)
>>>> graphics cards because they drive more than 2 monitors and JavaFX always
>>>> reports an error initializing HW pipeline and forcing gpu results in system
>>>> instability.
>>>> 
>>>> I checked the bug reports but couldn't see anything about JavaFX and Matrox
>>>> cards.
>>>> 
>>>> Questions
>>>> Is anyone aware of an existing issue?
>>>> Is there a way to get more details on why JavaFx fails to enable the D3D
>>>> pipeline?
>>>> Is there a list of known problematic graphics cards or a black list of
>>>> graphics cards where JavaFX falls back?
>>>> 
>>>> Thanks in advance,
>>>> Matt
>>> -- 
>>> Sent from Gmail Mobile
> 
> 
> 
> -- 
> Anirvan

Re: Matrox Graphics Cards Problems

[Matthew Elliot]

Hey, thanks for the second link, exactly what I needed just not the best news. 

I see all Matrox cards are disabled which is a bit tricky for us when many of 
our customers are have 4+ monitors and some have chosen those cards. 

I then managed to find this - https://bugs.openjdk.java.net/browse/JDK-8103350
I assume this means there will never be support of these cards or is there a 
work around? I.e. I see they support OpenGL so could I install OpenGL on a 
windows machine and try that pipeline?
Is this exclusion of all Matrox cards still valid?

Thanks in advance,
Matt

Sent from my phone.

> On 17/05/2018, at 5:15 PM, Anirvan Sarkar <powers.anir...@gmail.com> wrote:
> 
> Hi Matthew,
> 
> Please see the below file for blaclisted hardware on D3D. 
> 
> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/9e0e0e65e642/modules/javafx.graphics/src/main/native-prism-d3d/D3DBadHardware.h
> 
> Regards,
> Anirvan
> 
> 
>> On Thu, 17 May 2018 at 11:04 PM, Matthew Elliot 
>> <matthew.james.ell...@gmail.com> wrote:
>> Hi all,
>> 
>> we have some customers in the wild who use Matrox 9148LP (9100 series)
>> graphics cards because they drive more than 2 monitors and JavaFX always
>> reports an error initializing HW pipeline and forcing gpu results in system
>> instability.
>> 
>> I checked the bug reports but couldn't see anything about JavaFX and Matrox
>> cards.
>> 
>> Questions
>> Is anyone aware of an existing issue?
>> Is there a way to get more details on why JavaFx fails to enable the D3D
>> pipeline?
>> Is there a list of known problematic graphics cards or a black list of
>> graphics cards where JavaFX falls back?
>> 
>> Thanks in advance,
>> Matt
> -- 
> Sent from Gmail Mobile

Matrox Graphics Cards Problems

[Matthew Elliot]

Hi all,

we have some customers in the wild who use Matrox 9148LP (9100 series)
graphics cards because they drive more than 2 monitors and JavaFX always
reports an error initializing HW pipeline and forcing gpu results in system
instability.

I checked the bug reports but couldn't see anything about JavaFX and Matrox
cards.

Questions
Is anyone aware of an existing issue?
Is there a way to get more details on why JavaFx fails to enable the D3D
pipeline?
Is there a list of known problematic graphics cards or a black list of
graphics cards where JavaFX falls back?

Thanks in advance,
Matt

Re: Paint Phase Debugging / Performance

[Matthew Elliot]

Hey Nir,

In MissionControl the HotMethods section is very interest sometimes; not sure 
if that is where you’re already looking. It might point at the particular part 
of rendering pipeline that is executing too much.

I assume you also captured the JavaFX events and visualised the 
FXApplicationThread and QuantumRenderer threads to see that QuantumRenderer is 
constantly busy. 

I also don’t know how many animations you have but we also introduced a single 
central animation which modified properties triggering other components to 
redraw. This meant we only had 1 animation instead of dozens or hundreds. Not 
sure if this makes such a big difference to painting. 

Maybe also worth trying is in the IDE (I.e. IntelliJ) to Instrument the code 
with the debugger by evaluate and logging timestamps in the code. If you look 
at breakpoint properties you can put inside ‘Evaluate and log’ block 
System.currentTimeMillis(). Not sure how much it’ll drag performance back but 
maybe on prism frames per second = 1 and many breakpoints in the painting 
pipeline you can at least find where it spends all the time. 

Beyond that I’d be out of ideas. 
Matt

Sent from my phone.

> On 9/05/2018, at 1:15 AM, Nir Lisker <nlis...@gmail.com> wrote:
> 
> Hi Matthew,
> 
> This is a typical pulse, which indeed cases the effect of low FPS, and that's 
> what I'm trying to solve.
> 
> * Cache hints are ignored for 3D (but I tried anyway).
> * -Dprism.showdirty and printrendergraph also don't work for 3D scenes 
> (though I can get an approximation with a 2D scene).
> * There are no effects.
> 
> I'm working with Mission Control already, most of the instances in the GC 
> class histogram are related to animation classes: 
> InterpolationInterval$TangentDoubleInterpolationInterval and 
> NumberTangentInterpolator.
> 
> Looks like all all the discussed difficulties with diagnostics are enhanced 
> when it comes to 3D. Will have to dig deep on this one.
> 
> Thanks,
> Nir
> 
>> On Mon, May 7, 2018 at 9:07 PM, Matthew Elliot 
>> <matthew.james.ell...@gmail.com> wrote:
>> Hey Nir,
>> 
>> I’m not sure if I can offer much support as I haven’t been into the 3D world 
>> but just to clarify, is it one pulse after another with long wait, paint 
>> phases? From what I’ve seen personally if you have painting of 100+ 
>> milliseconds on every pulse you will be in big trouble / laggy as. 
>> 
>> On a one-off pulse like building a scene the first time I would say it is 
>> fine but regular paints that are longer are going to cause issues from my 
>> experience.
>> 
>> Did you try profiling with mission controller to look at what garbage is 
>> being created / what hot methods there? Maybe it points you in a better 
>> direction / at least rule out your own code. 
>> 
>> With animations I guess you set cache hints already?
>> 
>> Make sure you don’t have any effects on the animation as well, a Gaussian 
>> blur blend/drop shadow on an animation killed it for me. 
>> You can also try -Dprism.disableEffects= true to rule it out. 
>> You can also enable the prism option to show what is being painted on each 
>> pulse as an overlay. -Dprism.showdirty and there is another I forget to show 
>> how many times it was painted. (Not that your whole scene is painted when 
>> you expect a small part of it)
>> 
>> Or some trial and error with the prism flags here to try narrow it down - 
>> Just open PrismSettings.java in your IDE or web browser. 
>> 
>> Code explains them better than most posts I’ve seen.
>> 
>> Good luck. 
>> Matt
>> 
>> Sent from my phone.
>> 
>>> On 7/05/2018, at 2:36 PM, Nir Lisker <nlis...@gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I'm having a performance issue myself. I'm using animations on 3D models 
>>> (in a 3D subscene) and when there are "too many" models the QuantumRenderer 
>>> thread is running 100% of the time and utilizing 20-25% of the CPU, though 
>>> the OS reports that overall all cores are at ~40%. The application is using 
>>> the d3d pipeline.
>>> 
>>> A typical pulse is
>>> 
>>> PULSE: 4078 [112ms:225ms]
>>> T15 (11 +0ms): CSS Pass
>>> T15 (11 +0ms): Layout Pass
>>> T15 (12 +0ms): Update bounds
>>> T15 (12 +95ms): Waiting for previous rendering
>>> T15 (108 +0ms): Copy state to render graph
>>> T12 (109 +115ms): Painting
>>> T12 (224 +0ms): Presenting
>>> Counters:
>>> Nodes rendered: 651
>>> Nodes visited during render: 651
>>

Re: Paint Phase Debugging / Performance

[Matthew Elliot]

nableAdapter.call(java.base@10-internal/Executors.java:514)
> at 
> java.util.concurrent.FutureTask.runAndReset(java.base@10-internal/FutureTask.java:305)
> at 
> com.sun.javafx.tk.RenderJob.run(javafx.graphics@10-internal/RenderJob.java:58)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@10-internal/ThreadPoolExecutor.java:1135)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@10-internal/ThreadPoolExecutor.java:635)
> at 
> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(javafx.graphics@10-internal/QuantumRenderer.java:125)
> at java.lang.Thread.run(java.base@10-internal/Thread.java:844)
> 
> Does anyone have an idea on how to continue?
> 
> Thanks,
> Nir
> 
> 
>> On Fri, May 4, 2018 at 10:30 AM, Matthew Elliot 
>> <matthew.james.ell...@gmail.com> wrote:
>> Hi Pedro,
>> 
>> The first link I have read through many times, it is very useful for ideas
>> but doesn't really flesh out or go into much detail on each topic. It also
>> comments a few times on the problems we've encountered, 'what costs what'
>> is difficult to understand / measure.
>> 
>> The second link I hadn't found my way to and is definitely interesting to
>> understand more about how things are working internally - thanks.
>> 
>> Regards,
>> Matt
>> 
>> 
>> On 3 May 2018 at 19:17, Pedro Duque Vieira <pedro.duquevie...@gmail.com>
>> wrote:
>> 
>> > Hi Matthew,
>> >
>> > On the topic of documents with indications for improving performance.
>> >
>> > Don't know if you already found it, but there is a draft here (to which
>> > I've made a small contribution):
>> > https://wiki.openjdk.java.net/display/OpenJFX/Performance+Tips+and+Tricks
>> >
>> > A bit old though...
>> >
>> > And here:
>> >
>> > https://wiki.openjdk.java.net/display/OpenJFX/Performance+Ideas
>> >
>> >
>> > --
>> > Pedro Duque Vieira
>> >
> 

Re: Paint Phase Debugging / Performance

[Matthew Elliot]

Hi Pedro,

The first link I have read through many times, it is very useful for ideas
but doesn't really flesh out or go into much detail on each topic. It also
comments a few times on the problems we've encountered, 'what costs what'
is difficult to understand / measure.

The second link I hadn't found my way to and is definitely interesting to
understand more about how things are working internally - thanks.

Regards,
Matt


On 3 May 2018 at 19:17, Pedro Duque Vieira 
wrote:

> Hi Matthew,
>
> On the topic of documents with indications for improving performance.
>
> Don't know if you already found it, but there is a draft here (to which
> I've made a small contribution):
> https://wiki.openjdk.java.net/display/OpenJFX/Performance+Tips+and+Tricks
>
> A bit old though...
>
> And here:
>
> https://wiki.openjdk.java.net/display/OpenJFX/Performance+Ideas
>
>
> --
> Pedro Duque Vieira
>

Re: Paint Phase Debugging / Performance

[Matthew Elliot]

from what
I've googled. I mean, I only need to cache it if it will be redrawn right,
but generally I'm not redrawing it unless I change it. This seems a bit
counterintuitive? (okay maybe a window move or something but that is seldom)
>>> Hotspot is also great fun! ;) especially if you ever completely fill up
the code cache - which I don't recommend!

On that side are Gluon at documenting (maybe on an internal wiki) or
somewhere publicly the strange cases that you hit? I guess you've seen most
of them by now!
My favourite recently was a * { } css selected that sent our memory
throughput crazy as CSSPseudoState was allocated / collected at insane
rates!

Thanks,
Matt


On 1 May 2018 at 20:48, Johan Vos <johan@gluonhq.com> wrote:

> Hi Matthew,
>
> I agree this is a very important question.
>
> I don't like it when people say that "JavaFX is slow" because if
> everything is done right, JavaFX can be extremely fast.
> But I also realise that it is very easy to make things very slow in
> JavaFX, and in case "performance" is slow, it is important to pinpoint the
> problem as easy as possible. And that is often not trivial, so the easier
> it becomes to detect problems, the more developers will like JavaFX.
>
> I typically start with setting prism.verbose and javafx.pulseLogger to
> true, as you first need to know in which phase the problem is (e.g. layout
> or render phase). If you see the problem is in the render phase, you have
> to look at completely different things.
> Note that in most cases I've seen with bad performance, the problem was
> not in the rendering, but simply due to too much happening on the JavaFX
> application thread, preventing it to start doing the rendering.
> Those things are typically easily detected by generating thread dumps or
> using simple profilers to find out what the JavaFX thread is typically
> doing. If you see bad performance but in 90% of the thread dump there is no
> trace of rendering, you know where to look.
>
> When things are slow in the paint phase, the information about how many
> Nodes are visited and rendered, and how many are cached is very useful. I
> have a local debug version where I keep track of how many times a Node is
> rendered from cache versus how often the cache is invalid and needs to be
> recomputed (which is extremely expensive). It this was somehow automated,
> it could improve performance. It is similar to what hotspot C1/C2 is doing
> for code: it is expensive to compile all code at runtime, but when it turns
> out methods are often used, they are compiled. Similar, if the rendering
> pipeline detects that a node would remain cache-valid for most of the time,
> it might automatically set that node.setCache(true). But that's not a
> trivial thing to implement.
>
> The options in PrismSettings.java (e.g. prism.trace,
> prism.printrendergraph, prism.showdirty) and in QuantumToolit
> (quantum.debug) can be helpful as well.
>
> When there are no clear indications (e.g. not too many nodes, no invalid
> caches), I go for profiling, working bottom-up. I have the JavaFX source
> code always at hand when doing this, in order to see what exactly is
> happening.
> There are some patterns, e.g. on Android I know that lots of time spent in
> System.arraycopy is an indication about lots of slow CSS processing (Bitset
> operations, if you follow the profiling information bottom-up)
>
> It would be great to have tools that auto-detect this. Detecting slow
> render phases is already done, but linking to the root cause is of course
> much harder.
>
> I don't think that interrupting the paint phase is a good thing. If that
> takes 200-300 ms, it is very likely it will take 200-300ms in the next
> cycle.
>
> It might be an option though to dynamically throttle the pulse frequency
> (which can now only be changed at startup with javafx.animation.pulse) in
> case slow rendering is detected.
>
> - Johan
>
>
> On Tue, May 1, 2018 at 8:17 PM Matthew Elliot <matthew.james.elliot@gmail.
> com> wrote:
>
>> Hi all,
>>
>> The last few days I was troubleshooting a new performance issue that
>> showed
>> up in our PROD application where customers had fallen back to the SW
>> rendering pipeline. It severely affected the application where CPU
>> frequency was under 3 GHz with hover lags of a few seconds in the worst
>> cases. With thousands of potential HW/SW combinations in the wild it took
>> quite a while to even identify it really was an issue in our application
>> and not the usual noise of some silly set up. All this got me thinking...
>>
>> ... what was visible was long paint passes, and long waiting on previous
>> render but narrowing this down to exactl

Re: CSSParser Color.parse() for unexpected CSS properties

[Matthew Elliot]

Hi Kevin,

Priyanka from Oracle beat me to it and this small example hit the nail on
the head immediately. The below will throw and swallow and
IllegalArgumentException in CSSParser in the following method.

private ParsedValueImpl<Color,Color> colorValueOfString(String str) {



import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;


public class CssParserTest extends Application  {


@Override
public void start(Stage primaryStage) throws Exception {
primaryStage.setTitle("HBox Experiment 1");

Button button1 = new Button("Button Number 1");
Button button2 = new Button("Button Number 2");

VBox vbox = new VBox(button1, button2);
vbox.setStyle("-fx-alignment: top-center;");

Scene scene = new Scene(vbox, 200, 100);

primaryStage.setScene(scene);
primaryStage.show();
}

public static void main(String[] args) {
Application.launch(args);
}
}

There are at least 3 properties I have seen doing this and depending on the
complexity of the CSS, in our case quite extensive it leads to a lot of
throw/catch/ignore. :)

M.
​

On 4 April 2018 at 18:06, Kevin Rushforth <kevin.rushfo...@oracle.com>
wrote:

> Hi Matt,
>
> Thank you for filing this bug.
>
> Can you provide a standalone test case that reproduces this (a .java and a
> .css file), so we can attach it to the bug? Our WebBugs triage engineer
> will ask for this, and it will save time if you can provide it now.
> Otherwise the bug report looks fine.
>
> -- Kevin
>
>
>
> Matthew Elliot wrote:
>
>> Hey David, thanks.
>> I have filed a bug via the Oracle website.
>>
>> internal review ID : 9053225
>>
>> Hopefully this was correct as it was also my first time.
>> Matt
>>
>>
>> On 4 April 2018 at 17:21, David Grieve <david.gri...@oracle.com> wrote:
>>
>>
>>
>>> On 4/4/18 10:44 AM, Matthew Elliot wrote:
>>>
>>> Hi David, thanks for the quick response, the parser does seem to have
>>> knowledge of the property and values as in the method ...
>>>
>>> ParsedValueImpl valueFor(String property, Term root, CSSLexer lexer)
>>> throws ParseException {}
>>>
>>> it looks for particular properties for parsing... e.g.
>>>
>>> } else if ("-fx-background-color".equals(prop)) {
>>> return parsePaintLayers(root);
>>> } else if ("-fx-background-image".equals(prop)) {
>>> return parseURILayers(root);
>>> } else if ("-fx-background-insets".equals(prop)) {
>>>  return parseInsetsLayers(root);
>>>
>>> ... but fx-alignment and fx-shape for example aren't listed here and fall
>>> into this strange catch all place I noted in my previous email.
>>>
>>> My follow up questions would be:
>>>
>>> 1. Why does it hit this for standard css properties as defined for JavaFX
>>> components(fx-alignment, fx-shape, etc) I.e. https://docs.oracle.com/
>>> javafx/2/api/javafx/scene/doc-files/cssref.html (hbox, vbox have
>>> -fx-alignment)
>>> 2. Even if it is wanted to be extensible, isn't by default attempting to
>>> parse a color where the property is not known and therefore triggering
>>> exception throw / catch on the thread critical to UI perf a less than
>>> optimal solution? Could it be changed to handle this more gracefully than
>>> catch / ignore exceptions?
>>>
>>> Is it worth raising a ticket for such a topic, would it ever be
>>> considered
>>> for improvement.
>>>
>>> I think it is worth raising a ticket.
>>>
>>>
>>> Thanks again,
>>> Matt
>>>
>>>
>>> On 4 April 2018 at 16:20, David Grieve <david.gri...@oracle.com> wrote:
>>>
>>>
>>>
>>>> The parser doesn't have any concept of what the property is or value it
>>>> might have. This allows the addition of new properties (such as an user
>>>> might add for their own CSS styles) without having to modify the parser
>>>> to
>>>> handle them.
>>>>
>>>>
>>>>
>>>> On 4/4/18 10:03 AM, Matthew Elliot wrote:
>>>>
>>>>
>>>>
>>>>> Hi all, (first post).
>>>>>
>>>>> I was profiling our PROD JavaFX application recently I discovered
>>>>> something
>>>>> rather peculiar in the CSSParser. (jdk1.8.0_151)
>>

Re: CSSParser Color.parse() for unexpected CSS properties

[Matthew Elliot]

Hey David, thanks.
I have filed a bug via the Oracle website.

internal review ID : 9053225

Hopefully this was correct as it was also my first time.
Matt


On 4 April 2018 at 17:21, David Grieve <david.gri...@oracle.com> wrote:

> On 4/4/18 10:44 AM, Matthew Elliot wrote:
>
> Hi David, thanks for the quick response, the parser does seem to have
> knowledge of the property and values as in the method ...
>
> ParsedValueImpl valueFor(String property, Term root, CSSLexer lexer) throws 
> ParseException {}
>
> it looks for particular properties for parsing... e.g.
>
> } else if ("-fx-background-color".equals(prop)) {
> return parsePaintLayers(root);
> } else if ("-fx-background-image".equals(prop)) {
> return parseURILayers(root);
> } else if ("-fx-background-insets".equals(prop)) {
>  return parseInsetsLayers(root);
>
> ... but fx-alignment and fx-shape for example aren't listed here and fall
> into this strange catch all place I noted in my previous email.
>
> My follow up questions would be:
>
> 1. Why does it hit this for standard css properties as defined for JavaFX
> components(fx-alignment, fx-shape, etc) I.e. https://docs.oracle.com/
> javafx/2/api/javafx/scene/doc-files/cssref.html (hbox, vbox have
> -fx-alignment)
> 2. Even if it is wanted to be extensible, isn't by default attempting to
> parse a color where the property is not known and therefore triggering
> exception throw / catch on the thread critical to UI perf a less than
> optimal solution? Could it be changed to handle this more gracefully than
> catch / ignore exceptions?
>
> Is it worth raising a ticket for such a topic, would it ever be considered
> for improvement.
>
> I think it is worth raising a ticket.
>
>
> Thanks again,
> Matt
>
>
> On 4 April 2018 at 16:20, David Grieve <david.gri...@oracle.com> wrote:
>
>> The parser doesn't have any concept of what the property is or value it
>> might have. This allows the addition of new properties (such as an user
>> might add for their own CSS styles) without having to modify the parser to
>> handle them.
>>
>>
>>
>> On 4/4/18 10:03 AM, Matthew Elliot wrote:
>>
>>> Hi all, (first post).
>>>
>>> I was profiling our PROD JavaFX application recently I discovered
>>> something
>>> rather peculiar in the CSSParser. (jdk1.8.0_151)
>>>
>>> I noticed several hundred IllegalArgumentExceptions on the
>>> JavaApplicationThread where for various unrelated css properties the
>>> CSSParser is trying to parse a color. While the exception is subsequently
>>> caught and swallowed silently doing this hundred of times on this thread
>>> is
>>> rather ugly and caused *minor* delays in the application thread.
>>>
>>> This happened for alignment, shape, and a few other properties where
>>> no-lookup case was found and it ended on approx. line 900 of the
>>> CSSParser
>>> in
>>>
>>> colorValueOfString()
>>>
>>> with a value like 'center'; clearly no color.
>>>
>>> // if the property value is another property, then it needs to be looked
>>> up.
>>> boolean needsLookup = isIdent && properties.containsKey(text);
>>> if (needsLookup || ((value = colorValueOfString(str)) == null )) {
>>>  // If the value is a lookup, make sure to use the lower-case text
>>> so it matches the property
>>>  // in the Declaration. If the value is not a lookup, then use str
>>> since the value might
>>>  // be a string which could have some case sensitive meaning
>>>  //
>>>  // TODO: isIdent is needed here because of RT-38345. This
>>> effectively undoes RT-38201
>>>  value = new ParsedValueImpl<String,String>(needsLookup ? text :
>>> str, null, isIdent || needsLookup);
>>> }
>>>
>>> I had a look in the bug tracker https://bugs.openjdk.java.net/ but
>>> didn't
>>> find much in this regard so thought I would post in case it has come up
>>> before.
>>>
>>> I saw some of the css properties are from our application and some from
>>> e(fx)clipse which I can raise to Tom Schindl separately if it is a
>>> stylesheet issue, however it would appear that for example -fx-alignment
>>> in
>>> a layout VBOX/HBOX component should be valid according to JavaFX docs.
>>>
>>> More generally, is it expected that a property such as -fx-alignment
>>> should
>>> fall into this else {} catch all case, and why does JavaFX try to parse a
>>> Color by default?
>>>
>>> -fx-alignment: center;
>>>
>>> Any input much appreciated.
>>>
>>> Regards,
>>> Matt
>>>
>>
>>
>
>

Re: CSSParser Color.parse() for unexpected CSS properties

[Matthew Elliot]

Hi David, thanks for the quick response, the parser does seem to have
knowledge of the property and values as in the method ...

ParsedValueImpl valueFor(String property, Term root, CSSLexer lexer)
throws ParseException {}

it looks for particular properties for parsing... e.g.

} else if ("-fx-background-color".equals(prop)) {
return parsePaintLayers(root);
} else if ("-fx-background-image".equals(prop)) {
return parseURILayers(root);
} else if ("-fx-background-insets".equals(prop)) {
 return parseInsetsLayers(root);

... but fx-alignment and fx-shape for example aren't listed here and fall
into this strange catch all place I noted in my previous email.

My follow up questions would be:

1. Why does it hit this for standard css properties as defined for JavaFX
components(fx-alignment, fx-shape, etc) I.e.
https://docs.oracle.com/javafx/2/api/javafx/scene/doc-files/cssref.html
(hbox, vbox have -fx-alignment)
2. Even if it is wanted to be extensible, isn't by default attempting to
parse a color where the property is not known and therefore triggering
exception throw / catch on the thread critical to UI perf a less than
optimal solution? Could it be changed to handle this more gracefully than
catch / ignore exceptions?

Is it worth raising a ticket for such a topic, would it ever be considered
for improvement.

Thanks again,
Matt


On 4 April 2018 at 16:20, David Grieve <david.gri...@oracle.com> wrote:

> The parser doesn't have any concept of what the property is or value it
> might have. This allows the addition of new properties (such as an user
> might add for their own CSS styles) without having to modify the parser to
> handle them.
>
>
>
> On 4/4/18 10:03 AM, Matthew Elliot wrote:
>
>> Hi all, (first post).
>>
>> I was profiling our PROD JavaFX application recently I discovered
>> something
>> rather peculiar in the CSSParser. (jdk1.8.0_151)
>>
>> I noticed several hundred IllegalArgumentExceptions on the
>> JavaApplicationThread where for various unrelated css properties the
>> CSSParser is trying to parse a color. While the exception is subsequently
>> caught and swallowed silently doing this hundred of times on this thread
>> is
>> rather ugly and caused *minor* delays in the application thread.
>>
>> This happened for alignment, shape, and a few other properties where
>> no-lookup case was found and it ended on approx. line 900 of the CSSParser
>> in
>>
>> colorValueOfString()
>>
>> with a value like 'center'; clearly no color.
>>
>> // if the property value is another property, then it needs to be looked
>> up.
>> boolean needsLookup = isIdent && properties.containsKey(text);
>> if (needsLookup || ((value = colorValueOfString(str)) == null )) {
>>  // If the value is a lookup, make sure to use the lower-case text
>> so it matches the property
>>  // in the Declaration. If the value is not a lookup, then use str
>> since the value might
>>  // be a string which could have some case sensitive meaning
>>  //
>>  // TODO: isIdent is needed here because of RT-38345. This
>> effectively undoes RT-38201
>>  value = new ParsedValueImpl<String,String>(needsLookup ? text :
>> str, null, isIdent || needsLookup);
>> }
>>
>> I had a look in the bug tracker https://bugs.openjdk.java.net/ but didn't
>> find much in this regard so thought I would post in case it has come up
>> before.
>>
>> I saw some of the css properties are from our application and some from
>> e(fx)clipse which I can raise to Tom Schindl separately if it is a
>> stylesheet issue, however it would appear that for example -fx-alignment
>> in
>> a layout VBOX/HBOX component should be valid according to JavaFX docs.
>>
>> More generally, is it expected that a property such as -fx-alignment
>> should
>> fall into this else {} catch all case, and why does JavaFX try to parse a
>> Color by default?
>>
>> -fx-alignment: center;
>>
>> Any input much appreciated.
>>
>> Regards,
>> Matt
>>
>
>

CSSParser Color.parse() for unexpected CSS properties

[Matthew Elliot]

Hi all, (first post).

I was profiling our PROD JavaFX application recently I discovered something
rather peculiar in the CSSParser. (jdk1.8.0_151)

I noticed several hundred IllegalArgumentExceptions on the
JavaApplicationThread where for various unrelated css properties the
CSSParser is trying to parse a color. While the exception is subsequently
caught and swallowed silently doing this hundred of times on this thread is
rather ugly and caused *minor* delays in the application thread.

This happened for alignment, shape, and a few other properties where
no-lookup case was found and it ended on approx. line 900 of the CSSParser
in

colorValueOfString()

with a value like 'center'; clearly no color.

// if the property value is another property, then it needs to be looked up.
boolean needsLookup = isIdent && properties.containsKey(text);
if (needsLookup || ((value = colorValueOfString(str)) == null )) {
// If the value is a lookup, make sure to use the lower-case text
so it matches the property
// in the Declaration. If the value is not a lookup, then use str
since the value might
// be a string which could have some case sensitive meaning
//
// TODO: isIdent is needed here because of RT-38345. This
effectively undoes RT-38201
value = new ParsedValueImpl(needsLookup ? text :
str, null, isIdent || needsLookup);
}

I had a look in the bug tracker https://bugs.openjdk.java.net/ but didn't
find much in this regard so thought I would post in case it has come up
before.

I saw some of the css properties are from our application and some from
e(fx)clipse which I can raise to Tom Schindl separately if it is a
stylesheet issue, however it would appear that for example -fx-alignment in
a layout VBOX/HBOX component should be valid according to JavaFX docs.

More generally, is it expected that a property such as -fx-alignment should
fall into this else {} catch all case, and why does JavaFX try to parse a
Color by default?

-fx-alignment: center;

Any input much appreciated.

Regards,
Matt

Re: Planning for JavaFX.next

[Matthew Elliot]

+1 for CSS perf (diagnostic tooling for slow selectors like @Daniel Gloeckner 
referenced earlier would also be a bonus)
+ for scene graph rendering perf
+ table perf
+ table features and fixes (column freezing, row span, selection model fixes 
and memory leak fixes)
+ integration of controlsfx into JFX.

Matt. 

Sent from my phone.

> On 8/12/2016, at 7:07 AM, Chris Newland  wrote:
> 
> Hi Jonathan,
> 
> +1 to that list for me.
> 
> In my experience JavaFX performs well for the "low-level" (Canvas +
> GraphicsContext) stuff with one exception - the PixelWriter APIs appear do
> a lot of array duplication and copying under the hood which I believe can
> be optimised. I'll investigate further and try to come up with a patch.
> 
> Nice to have (but lower priority than everything on the list) would be a
> public API for grabbing frames from a MediaPlayer which used to be
> possible in 8 with player.impl_getLatestFrame().
> 
> Echoing Tom and Felix, my #1 priority would be fixing scenegraph
> performance as tables with large row counts and charts (e.g. XYChart) with
> large numbers of data points (e.g. 50K) in their Series can easily lead to
> multi-second render times and huge heap usage.
> 
> Thanks for opening this discussion,
> 
> Chris
> 
>> On Wed, December 7, 2016 23:45, Jonathan Giles wrote:
>> Hi folks,
>> 
>> 
>> Development on JDK 9 is slowly starting to ramp down, and we are
>> starting to turn our attention to the goals for JavaFX in JDK 10 and
>> beyond. We are starting to compile our list of what we think is important,
>> but we really want to hear from the community about what their highest
>> priorities are to them. As always, it's important to keep in mind what
>> JavaFX is (e.g. it isn't aiming to be a high-performance
>> game engine), but even still there are bound to be a number of places where
>> people might want to weigh in, for example:
>> 
>> * New layout containers (e.g. Flexbox)
>> * Public APIs for UI control behaviors
>> * Marlin renderer enabled by default
>> * Support for CSS animations
>> * CSS performance improvements
>> * TableView improvements (cell spanning, row / column freezing, etc)
>> * TableView performance
>> * Focus traversal API
>> * WebGL support in WebView
>> * Improved image I/O support
>> * A JavaFX equivalent of the AWT Desktop APIs
>> * Multi-res image API
>> * NIO-backed writable images
>> 
>> 
>> If there are other areas of interest that aren't listed here, please
>> start discussing them and we can work together to determine priorities. If
>> all you want to do is add a +1 for one of more of the items above, even
>> that will be very useful.
>> 
>> Thanks,
>> -- Jonathan
>> 
>> 
>