The problem was first observed when running "Check box" sample from Ensemble
application on Netbook HP Mini 210-2100 (Intel Atom CPU N455 @ 1.66GHz, RAM: 1Mb ).
Note, this Netbook has only software pipeline support, but this seems to be is not related (see below).

I have written simple CheckBoxDemoFXStress test which creates 1000 check boxes
which also demonstrates very slow responsiveness when clicking on particular check box.
I see at least 1 second delay.

The similar Java-based test (CheckBoxDemoStress.java) works pretty fast.

Similar test (CheckBoxDemoFXStress2) which creates 3 check boxes and 1000 labels
(which perhaps doesn't listen for events, but I am not sure this is relevant to root cause of the issue)
works fast.

Changing Labels to Buttons (CheckBoxDemoFXStress3) demonstrates the slowness again.


I also see the similar slowness when running CheckBoxDemoFXStress test on Dell E6410 Windows XP laptop
(M 520 @ 2400GHz, 3.4 Gb of RAM).
The interesting is that running with j2d pipeline (-Dprism.order=j2d) leads to
fast test run/event responsiveness.

JavaPerformanceAnalyzer profiles gotten for CheckBoxDemoFXStress and CheckBoxDemoFXStress2 on Dell laptop
show that the time spent in com.sun.javafx.sg.prism.NGRegion.renderContent() is more than 10 times
bigger for CheckBoxDemoFXStress comparing to CheckBoxDemoFXStress2.

It looks like that for some reason extra unnecessary repainting is done which results
in performance lost and slow event responsiveness.


All testing was done with latest fx2.0-b18.

Perhaps Netbook and Dell issues have different nature as the list of slow scenarios is:
- Netbook-j2d (no d3d support)
- Dell-d3d (have fast responsiveness with j2d)