RE: Can Javafx cursor be disabled?
Hi, I had the same problem using i.MX6 with a touchscreen and Monocle on framebuffer (with JavaFX 1.8u151-b12). Unfortunately I could not find a workaround because, as you said, the gray cursor placeholder is displayed before any application code is executed. So there is no way to disable it using Java code. Since I compile the JavaFX part myself, I added the following patch to hide the cursor on startup. This seems to work for me: diff -r fa07d9fbd309 modules/graphics/src/main/java/com/sun/glass/ui/monocle/MX6Cursor.java --- a/modules/graphics/src/main/java/com/sun/glass/ui/monocle/MX6Cursor.java Tue Sep 13 12:52:05 2016 -0400 +++ b/modules/graphics/src/main/java/com/sun/glass/ui/monocle/MX6Cursor.java Mon Sep 19 18:25:20 2016 +0200 @@ -154,6 +154,8 @@ NativeScreen screen = NativePlatformFactory.getNativePlatform().getScreen(); screenWidth = screen.getWidth(); screenHeight = screen.getHeight(); + +setVisibility(false); } @Override Regards, Michael > Hi, thanks for. > > Yes we are currently running without X and using Monocle. > > Maybe I'll put up a feature request as with embedded devices often the > cursor is not a relevant modality. > > >> >> -- >> >> Message: 3 >> Date: Sat, 1 Jun 2019 22:23:41 + >> From: Thiago Milczarek Sayao >> To: "openjfx-dev at openjdk.java.net" >> Subject: RE: Can Javafx cursor be disabled? >> Message-ID: >> > CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM> >> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Just realized you might be using Monocle. >> >> So it might be handling the cursor. Don't know how to hide it.. >> >> De: openjfx-dev em nome de Thiago >> Milczarek Sayao >> Enviado: s?bado, 1 de junho de 2019 19:18 >> Para: openjfx-dev at openjdk.java.net >> Assunto: RE: Can Javafx cursor be disabled? >> >> I don't think javafx supports framebuffer. >> >> It might be working on gtk2, but will not work on gtk3 since the framebuffer >> backend was removed from gdk. >> >> So I suggest you move to X11. >> >> De: openjfx-dev em nome de Dell >> Green >> Enviado: s?bado, 1 de junho de 2019 16:28 >> Para: openjfx-dev at openjdk.java.net >> Assunto: RE: Can Javafx cursor be disabled? >> >> Thanks for that, good to know. I should of mentioned that we are not using >> X, but using framebuffer instead >> >> Message: 2 >> Date: Fri, 31 May 2019 14:45:11 + >> From: Thiago Milczarek Sayao >> To: "openjfx-dev at openjdk.java.net" >> Subject: RE: Can Javafx cursor be disabled? >> Message-ID: >> > CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM> >> >> Content-Type: text/plain; charset="us-ascii" >> >> If you are using X.org, the cursor is controlled by X, so I would look for a >> X configuration to disable cursor. >> >> https://unix.stackexchange.com/questions/346903/can-i-remove-the-mouse-pointer-entirely-from-x >> >> >> De: openjfx-dev em nome de Dell >> Green >> Enviado: sexta-feira, 31 de maio de 2019 11:29 >> Para: openjfx-dev at openjdk.java.net >> Assunto: Can Javafx cursor be disabled? >> >> We have a touch/rotary device that doesn't use any mouse/cursor input. >> >> Is there a way to tell javafx to not initialize a cursor (MX6Cursor.java in >> my case) on startup as we are seeing /dev/fb1 being unblanked and a grey >> cursor artifact drawn onto the /dev/fb1, before any user specific javafx >> code is created. >> >> I have looked through the source code and there doesn't seem to be a >> configurable property to control this. >> >> I can remove /dev/fb1 and javafx prints an error/stack-trace but appears to >> work as normal, however I'm not sure what ongoing impact this has on javafx. >> >> any thoughts? >> >> >> >> End of openjfx-dev Digest, Vol 91, Issue 1 >> ** >> >> >> >> >> End of openjfx-dev Digest, Vol 91, Issue 2 >> ** >>
Re: CSS id selector with embedded dot
On 5/10/17 2:02 PM, David Grieve wrote: > Having an id with a dot is not valid CSS syntax. > > From the spec: " An ID selector contains a "number sign" (U+0023, #) > immediately followed by the ID value, which must be an CSS identifiers." > > An identifier is defined here: > https://www.w3.org/TR/CSS21/syndata.html#value-def-identifier. The tldr; > is that an identifier cannot contain a dot. But in the link you referenced it says: "Identifiers can also contain escaped characters and any ISO 10646 character as a numeric code (see next item). For instance, the identifier "B?" may be written as "B\\?" or "B\26 W\3F"." Wouldn't that include an escaped dot as a valid character for a CSS identifier?
AW: [PATCH] Decrease Toolkit.firePulse allocation rate
On 1/14/16 8:09 PM, Jim Graham wrote:
> How often are listeners added and removed? It might make more sense to
> make them copy-on-write instead...?
That is a good point. As far as I can see, every window adds a stage listener
when it is shown and removes it if it is closed. Every scene adds/removes a
scene listener. So the listener maps are changed rarely. The post scene pulse
listener seems to be used for the snapshot functionality. Although I can only
see that such a listener is added, but it seems it will never be removed again.
I will try to revise my patch and open an RFE as suggested by Kevin as soon as
I handed in my OCA.
Regards,
Michael
>On 1/14/16 4:52 AM, Doswald Michael wrote:
>> While profiling a JavaFX application that runs on embedded hardware, I have
>> found that the Toolkit.firePulse method creates more garbage than necessary.
>> In an application that simply animates an object without doing much else, I
>> see that the firePulse method allocates a fair amount of objects (compared
>> to the overall number of allocated objects). I have written a small patch
>> that decreases the allocation rate in said method. Since I'm not sure if
>> such tweaks are desired in the JavaFX codebase, I didn't open a JIRA issue.
>> I'm happy to do so if they are.
>>
>> The following small application animates a single circle on screen. The
>> allocation rate of the 'JavaFX Application Thread' is as follows (measured
>> with jvisualvm):
>> openjfx 8u HEAD:~ 65 KB/s after start, ~ 49 KB/s after JIT
>> compilation kicked in
>> with patch:~ 25 KB/s, doesn't seem to change when JIT
>> kicks in
>>
>> public class AllocateApp extends Application {
>> public static void main(String... args) {
>>Application.launch(args);
>> }
>>
>> @Override
>> public void start(Stage primaryStage) throws Exception {
>> Circle circle = new Circle(10, 25, 10);
>>
>> Timeline timeline = new Timeline(new KeyFrame(Duration.seconds(2),
>> new KeyValue(circle.centerXProperty(), 490)));
>> timeline.setCycleCount(Timeline.INDEFINITE);
>> timeline.setAutoReverse(true);
>> timeline.play();
>>
>> primaryStage.setScene(new Scene(new Pane(circle), 500, 50));
>> primaryStage.show();
>> }
>> }
>>
>>
>> The patch below only creates a single List object instead of three
>> WeakHashMaps to make a local copy of the TKPulseListeners. It also uses the
>> number of listeners in the maps to estimate the size of the list. The patch
>> uses WeakReference objects in the list, which I doubt is necessary, but it
>> emulates the previous behaviour more accurately. I believe it would be
>> possible to change that to a strong reference for the following reasons:
>> a) The list is local and the strong references would only be there for the
>> time the firePulse method is run
>> b) The code would become more readable (less generics parameters, null-guard
>> not necessary in loop)
>> c) Getting rid of the WeakReference objects would decrease garbage
>> generation even more (down to ~ 21 KB/s)
>>
>>
>> Regards
>> Michael
>>
>> diff -r f1c3eb85af4d
>> modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java
>> --- a/modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.javaFri
>> Jan 08 08:11:51 2016 -0800
>> +++ b/modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.javaWed
>> Jan 13 10:43:27 2016 +0100
>> @@ -51,7 +51,6 @@
>> import javafx.scene.shape.StrokeType;
>> import javafx.stage.FileChooser.ExtensionFilter;
>> import javafx.stage.Modality;
>> -import javafx.stage.Stage;
>> import javafx.stage.StageStyle;
>> import javafx.stage.Window;
>> import java.io.File;
>> @@ -94,6 +93,8 @@
>> import com.sun.scenario.effect.Color4f;
>> import com.sun.scenario.effect.FilterContext;
>> import com.sun.scenario.effect.Filterable;
>> +import java.lang.ref.WeakReference;
>> +import javafx.util.Pair;
>>
>>
>> public abstract class Toolkit {
>> @@ -362,32 +363,36 @@
>> // and those changes propogated to scene before it gets its pulse
>> to update
>>
>> // Copy of listener map
>> -final Map<TKPulseListener,AccessControlContext> stagePulseList =
>> -new WeakHashMap<TKPulseListener,AccessControlContext>();
>> -final Map<TKPulseListener,AccessControlContext> scenePulseList =
>
[PATCH] Decrease Toolkit.firePulse allocation rate
While profiling a JavaFX application that runs on embedded hardware, I have
found that the Toolkit.firePulse method creates more garbage than necessary. In
an application that simply animates an object without doing much else, I see
that the firePulse method allocates a fair amount of objects (compared to the
overall number of allocated objects). I have written a small patch that
decreases the allocation rate in said method. Since I'm not sure if such tweaks
are desired in the JavaFX codebase, I didn't open a JIRA issue. I'm happy to do
so if they are.
The following small application animates a single circle on screen. The
allocation rate of the 'JavaFX Application Thread' is as follows (measured with
jvisualvm):
openjfx 8u HEAD:~ 65 KB/s after start, ~ 49 KB/s after JIT compilation
kicked in
with patch:~ 25 KB/s, doesn't seem to change when JIT kicks
in
public class AllocateApp extends Application {
public static void main(String... args) {
Application.launch(args);
}
@Override
public void start(Stage primaryStage) throws Exception {
Circle circle = new Circle(10, 25, 10);
Timeline timeline = new Timeline(new KeyFrame(Duration.seconds(2), new
KeyValue(circle.centerXProperty(), 490)));
timeline.setCycleCount(Timeline.INDEFINITE);
timeline.setAutoReverse(true);
timeline.play();
primaryStage.setScene(new Scene(new Pane(circle), 500, 50));
primaryStage.show();
}
}
The patch below only creates a single List object instead of three WeakHashMaps
to make a local copy of the TKPulseListeners. It also uses the number of
listeners in the maps to estimate the size of the list. The patch uses
WeakReference objects in the list, which I doubt is necessary, but it emulates
the previous behaviour more accurately. I believe it would be possible to
change that to a strong reference for the following reasons:
a) The list is local and the strong references would only be there for the time
the firePulse method is run
b) The code would become more readable (less generics parameters, null-guard
not necessary in loop)
c) Getting rid of the WeakReference objects would decrease garbage generation
even more (down to ~ 21 KB/s)
Regards
Michael
diff -r f1c3eb85af4d
modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java
--- a/modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java Fri Jan
08 08:11:51 2016 -0800
+++ b/modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java Wed Jan
13 10:43:27 2016 +0100
@@ -51,7 +51,6 @@
import javafx.scene.shape.StrokeType;
import javafx.stage.FileChooser.ExtensionFilter;
import javafx.stage.Modality;
-import javafx.stage.Stage;
import javafx.stage.StageStyle;
import javafx.stage.Window;
import java.io.File;
@@ -94,6 +93,8 @@
import com.sun.scenario.effect.Color4f;
import com.sun.scenario.effect.FilterContext;
import com.sun.scenario.effect.Filterable;
+import java.lang.ref.WeakReference;
+import javafx.util.Pair;
public abstract class Toolkit {
@@ -362,32 +363,36 @@
// and those changes propogated to scene before it gets its pulse to
update
// Copy of listener map
- final Map stagePulseList =
- new WeakHashMap();
- final Map scenePulseList =
- new WeakHashMap();
- final Map postScenePulseList =
- new WeakHashMap();
+ final List>
listenersList;
synchronized (this) {
- stagePulseList.putAll(stagePulseListeners);
- scenePulseList.putAll(scenePulseListeners);
- postScenePulseList.putAll(postScenePulseListeners);
+ listenersList = new
ArrayList<>(stagePulseListeners.size()+scenePulseListeners.size()+postScenePulseListeners.size());
+ copyListeners(stagePulseListeners, listenersList);
+ copyListeners(scenePulseListeners, listenersList);
+ copyListeners(postScenePulseListeners, listenersList);
}
- for (Map.Entry entry :
stagePulseList.entrySet()) {
- runPulse(entry.getKey(), entry.getValue());
- }
- for (Map.Entry entry :
scenePulseList.entrySet()) {
- runPulse(entry.getKey(), entry.getValue());
- }
- for (Map.Entry entry :
postScenePulseList.entrySet()) {
- runPulse(entry.getKey(), entry.getValue());
+
+ for (int idx = 0, max = listenersList.size(); idx < max; idx++) {
+ Pair
listenerEntry = listenersList.get(idx);
+ TKPulseListener
