Re: [Integrated] RFR: 8176499: Dependence on java.util.Timer freezes screen when OS time resets backwards
On Wed, 19 Feb 2020 19:14:08 GMT, Dell Green
wrote:
> https://bugs.openjdk.java.net/browse/JDK-8176499
>
> This pull request fixes a long standing issue in the MonocleTimer class
> whereby it has a dependency on the
> java.uti.Timer class which is dependent on system time and can cause UI
> freezes for seconds/minutes/hours/days/years
> dependent upon how far back in time the system clock is set by either a user
> manually or NTP. This looks like it is
> because the Timer class will wait for (executionTime - currentTime) before
> proceeding if a task hasn't fired yet.
> https://hg.openjdk.java.net/jdk10/master/file/be620a591379/src/java.base/share/classes/java/util/Timer.java#l553
> For a
> long running embedded device with a UI like IOT devices this is pretty
> disastrous. We recently re-discovered this issue
> whilst testing such a device before going into production.
> The MonocleTimer class is used by MonocleApplication and QuantumToolkit class
> to create its pulseTimer for emebdded
> systems and sets it up to fire periodically inline with the requested pulse
> frequency which by default is 60Hz
> resulting in a pulse interval of 16ms. It is well documented that for
> implementations that wish to measure elapsed
> time ScheduledThreadPoolExecutor should be used as a replacement for
> java.util.Timer class.
> Java Concurrency In Practice:
> https://pdfs.semanticscholar.org/3650/4bc31d3b2c5c00e5bfee28ffc5d403cc8edd.pdf
> (page 77)
>
> "The Timer facility manages the execution of deferred ("run this task in 100
> ms") and periodic ("run this task every
> 10ms") tasks. However, Timer has some drawbacks, and
> ScheduledThreadPoolExecutor should be thought of as its
> replacement." With the original implementation, if I set the date.time back
> 8 years for example the UI freezes up
> indefinitely (I cant wait 8 years). Repeating the same test with the proposed
> implementation has no affect on the UI
> and it runs as normal. The proposed solution has been tested on an Arm iMX6
> board.
>
> Whist testing in isolation the MonocleTimer class with no work to do on each
> pulse, it looks like the change from Timer
> class to ScheduledThreadPoolExecutor also has brought with it a greater
> accuracy of when the pulses are fired.
> The following results were observed when running MonocleTimer at 60Hz for 1
> minute. It appears that we get a higher
> frequency of pulses hitting the 16ms mark with the replacement solution
>
> x86-64 linux desktop:
>
> Timer class
> NumSamples: 3599
> Mean: 16.230063906640734
> StdDev: 0.45021901536403147
> Median: 16
> Mode: 16, freq: 2714, perc: 75.40983606557377%
>
>
> Scheduler class
> NumSamples: 3599
> Mean: 16.0
> StdDev: 0.0
> Median: 16
> Mode: 16, freq: 3599, perc: 100.0%
>
>
>
> Arm linux iMX6:
>
> Timer class
> NumSamples: 3599
> Mean: 16.182272853570435
> StdDev: 0.4224950723394174
> Median: 16
> Mode: 16, freq: 2837, perc: 78.82745207001946%
>
>
> Scheduler class
> NumSamples: 3599
> Mean: 15.995554320644624
> StdDev: 0.3666906549602725
> Median: 16
> Mode: 16, freq: 3468, perc: 96.3601000277855%
This pull request has now been integrated.
Changeset: 1cae6a87
Author:Dell Green
Committer: Johan Vos
URL: https://git.openjdk.java.net/jfx/commit/1cae6a87
Stats: 17 lines in 1 file changed: 8 ins; 3 del; 6 mod
8176499: Dependence on java.util.Timer freezes screen when OS time resets
backwards
Reviewed-by: jvos
-
PR: https://git.openjdk.java.net/jfx/pull/117
Re: RFR: 8176499: Dependence on java.util.Timer freezes screen when OS time resets backwards
On Fri, 1 May 2020 16:20:41 GMT, Kevin Rushforth wrote: >> /integrate >> /summary Fixes a long standing issue in the MonocleTimer class as its >> dependent on the java.uti.Timer class which is >> dependent on system time which can cause UI freezes depending upon how far >> back in time the system clock is set by >> either a user or NTP. > > @dellgreen `/summary` is a distinct command from `/integrate` -- you can't > enter multiple commands in a single comment. > `/integrate` should always be the last thing you do, since that indicates you > are completely done with the PR and want > to integrate it in its current state. The `/summary` is going to be ignored, > which is likely fine, but this is > something to note for next time. @kevinrushforth ok, thank you for the feedback - PR: https://git.openjdk.java.net/jfx/pull/117
Re: RFR: 8176499: Dependence on java.util.Timer freezes screen when OS time resets backwards
On Thu, 20 Feb 2020 10:37:34 GMT, littlefreaky wrote: >>> I don't see any stray commits, so it looks like your branch is based off of >>> master correctly. >>> >>> One thing I would ask you to change is that the title of this PR should >>> exactly match the title of the JBS bug. So can you change it to: >>> >>> ``` >>> 8176499: Dependence on java.util.Timer freezes screen when OS time resets >>> backwards >>> ``` >> >> apologies, all done > > I have a question about the scheduling of the task: > The old code used Timer.schedule(TimerTask,long,long) which schedules the > task for repeated fixed-delay execution. > The new code uses ScheduledThreadPoolExecutor.scheduleAtFixedRate(Runnable, > long, long, TimeUnit) which schedules the task for repeated fixed-rate > execution. > > Now I think that scheduling at fixed rate would be the correct way as we want > to reach 60 pulses per second. But my question is: Can this lead to problems > if the work done per pulse takes longer than 16ms? The scheduleAtFixedRate > does queue subsequent executions if the previous task takes too long. > Couldn't this lead to an task queue overflow if the system is overloaded? Do > we need to add protection for that scenario? I may be wrong, but looking at the source code for both java.util.Timer.java and ScheduledThreadPoolExecutor.java, they both appear to grow their respective queues if needs be. So i don't think the proposed solution is any worse in that respect. - PR: https://git.openjdk.java.net/jfx/pull/117
Re: RFR: 8176499: Dependence on java.util.Timer freezes screen when OS time resets backwards
On Wed, 19 Feb 2020 19:39:30 GMT, Kevin Rushforth wrote: >> I don't see any stray commits, so it looks like your branch is based off of >> master correctly. >> >> One thing I would ask you to change is that the title of this PR should >> exactly match the title of the JBS bug. So can you change it to: >> >> 8176499: Dependence on java.util.Timer freezes screen when OS time resets >> backwards > > Seems a simple enough fix. Probably @johanvos can review it. > I don't see any stray commits, so it looks like your branch is based off of > master correctly. > > One thing I would ask you to change is that the title of this PR should > exactly match the title of the JBS bug. So can you change it to: > > ``` > 8176499: Dependence on java.util.Timer freezes screen when OS time resets > backwards > ``` apologies, all done - PR: https://git.openjdk.java.net/jfx/pull/117
Re: RFR: 8176499: Remove MonocleTimer dependency on system time
On Wed, 19 Feb 2020 19:14:08 GMT, Dell Green
wrote:
> https://bugs.openjdk.java.net/browse/JDK-8176499
>
> This pull request fixes a long standing issue in the MonocleTimer class
> whereby it has a dependency on the java.uti.Timer class which is dependent on
> system time and can cause UI freezes for seconds/minutes/hours/days/years
> dependent upon how far back in time the system clock is set by either a user
> manually or NTP. This looks like it is because the Timer class will wait for
> (executionTime - currentTime) before proceeding if a task hasn't fired yet.
>
> https://hg.openjdk.java.net/jdk10/master/file/be620a591379/src/java.base/share/classes/java/util/Timer.java#l553
>
> For a long running embedded device with a UI like IOT devices this is pretty
> disastrous.
> We recently re-discovered this issue whilst testing such a device before
> going into production.
>
> The MonocleTimer class is used by MonocleApplication and QuantumToolkit class
> to create its pulseTimer for emebdded systems and sets it up to fire
> periodically inline with the requested pulse frequency which by default is
> 60Hz resulting in a pulse interval of 16ms.
>
> It is well documented that for implementations that wish to measure elapsed
> time ScheduledThreadPoolExecutor should be used as a replacement for
> java.util.Timer class.
>
> Java Concurrency In Practice:
> https://pdfs.semanticscholar.org/3650/4bc31d3b2c5c00e5bfee28ffc5d403cc8edd.pdf
> (page 77)
>
> "The Timer facility manages the execution of deferred ("run this task in 100
> ms") and periodic ("run this task every 10ms") tasks. However, Timer has some
> drawbacks, and ScheduledThreadPoolExecutor should be thought of as its
> replacement."
>
> With the original implementation, if I set the date.time back 8 years for
> example the UI freezes up indefinitely (I cant wait 8 years). Repeating the
> same test with the proposed implementation has no affect on the UI and it
> runs as normal.
>
> The proposed solution has been tested on an Arm iMX6 board.
>
> Whist testing in isolation the MonocleTimer class with no work to do on each
> pulse, it looks like the change from Timer class to
> ScheduledThreadPoolExecutor also has brought with it a greater accuracy of
> when the pulses are fired.
>
> The following results were observed when running MonocleTimer at 60Hz for 1
> minute. It appears that we get a higher frequency of pulses hitting the 16ms
> mark with the replacement solution
>
>
> x86-64 linux desktop:
>
> Timer class
> NumSamples: 3599
> Mean: 16.230063906640734
> StdDev: 0.45021901536403147
> Median: 16
> Mode: 16, freq: 2714, perc: 75.40983606557377%
>
>
> Scheduler class
> NumSamples: 3599
> Mean: 16.0
> StdDev: 0.0
> Median: 16
> Mode: 16, freq: 3599, perc: 100.0%
>
>
>
> Arm linux iMX6:
>
> Timer class
> NumSamples: 3599
> Mean: 16.182272853570435
> StdDev: 0.4224950723394174
> Median: 16
> Mode: 16, freq: 2837, perc: 78.82745207001946%
>
>
> Scheduler class
> NumSamples: 3599
> Mean: 15.995554320644624
> StdDev: 0.3666906549602725
> Median: 16
> Mode: 16, freq: 3468, perc: 96.3601000277855%
@kevinrushforth apologies for previous, my local repos seem to be messed up
when i changed remotes from old javafx github repo to new one, as that rogue
commit didnt exist my side for some reason. looks like its fixed now
-
PR: https://git.openjdk.java.net/jfx/pull/117
RFR: 8176499: Remove MonocleTimer dependency on system time
https://bugs.openjdk.java.net/browse/JDK-8176499
This pull request fixes a long standing issue in the MonocleTimer class whereby
it has a dependency on the java.uti.Timer class which is dependent on system
time and can cause UI freezes for seconds/minutes/hours/days/years dependent
upon how far back in time the system clock is set by either a user manually or
NTP. This looks like it is because the Timer class will wait for (executionTime
- currentTime) before proceeding if a task hasn't fired yet.
https://hg.openjdk.java.net/jdk10/master/file/be620a591379/src/java.base/share/classes/java/util/Timer.java#l553
For a long running embedded device with a UI like IOT devices this is pretty
disastrous.
We recently re-discovered this issue whilst testing such a device before going
into production.
The MonocleTimer class is used by MonocleApplication and QuantumToolkit class
to create its pulseTimer for emebdded systems and sets it up to fire
periodically inline with the requested pulse frequency which by default is 60Hz
resulting in a pulse interval of 16ms.
It is well documented that for implementations that wish to measure elapsed
time ScheduledThreadPoolExecutor should be used as a replacement for
java.util.Timer class.
Java Concurrency In Practice:
https://pdfs.semanticscholar.org/3650/4bc31d3b2c5c00e5bfee28ffc5d403cc8edd.pdf
(page 77)
"The Timer facility manages the execution of deferred ("run this task in 100
ms") and periodic ("run this task every 10ms") tasks. However, Timer has some
drawbacks, and ScheduledThreadPoolExecutor should be thought of as its
replacement."
With the original implementation, if I set the date.time back 8 years for
example the UI freezes up indefinitely (I cant wait 8 years). Repeating the
same test with the proposed implementation has no affect on the UI and it runs
as normal.
The proposed solution has been tested on an Arm iMX6 board.
Whist testing in isolation the MonocleTimer class with no work to do on each
pulse, it looks like the change from Timer class to ScheduledThreadPoolExecutor
also has brought with it a greater accuracy of when the pulses are fired.
The following results were observed when running MonocleTimer at 60Hz for 1
minute. It appears that we get a higher frequency of pulses hitting the 16ms
mark with the replacement solution
x86-64 linux desktop:
Timer class
NumSamples: 3599
Mean: 16.230063906640734
StdDev: 0.45021901536403147
Median: 16
Mode: 16, freq: 2714, perc: 75.40983606557377%
Scheduler class
NumSamples: 3599
Mean: 16.0
StdDev: 0.0
Median: 16
Mode: 16, freq: 3599, perc: 100.0%
Arm linux iMX6:
Timer class
NumSamples: 3599
Mean: 16.182272853570435
StdDev: 0.4224950723394174
Median: 16
Mode: 16, freq: 2837, perc: 78.82745207001946%
Scheduler class
NumSamples: 3599
Mean: 15.995554320644624
StdDev: 0.3666906549602725
Median: 16
Mode: 16, freq: 3468, perc: 96.3601000277855%
-
Commits:
- 3c22d205: 8176499: Remove MonocleTimer dependency on system time
Changes: https://git.openjdk.java.net/jfx/pull/117/files
Webrev: https://webrevs.openjdk.java.net/jfx/117/webrev.00
Issue: https://bugs.openjdk.java.net/browse/JDK-8176499
Stats: 17 lines in 1 file changed: 3 ins; 8 del; 6 mod
Patch: https://git.openjdk.java.net/jfx/pull/117.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/117/head:pull/117
PR: https://git.openjdk.java.net/jfx/pull/117
Re: RFR: 8087980: Add property to disable Monocle cursor
On Sun, 17 Nov 2019 10:04:36 GMT, Dell Green
wrote:
> On Sat, 16 Nov 2019 17:51:56 GMT, John Neffenger
> wrote:
>
>> On Sat, 16 Nov 2019 06:09:35 GMT, Dell Green
>> wrote:
>>
>>> On Sat, 16 Nov 2019 00:32:31 GMT, John Neffenger
>>> wrote:
>>>
>>>> On Wed, 13 Nov 2019 22:04:36 GMT, Dell Green
>>>> wrote:
>>>>
>>>>> On Wed, 13 Nov 2019 21:34:06 GMT, John Neffenger
>>>>> wrote:
>>>>>
>>>>>> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green
>>>>>> <12861109+dellgr...@users.noreply.github.com> wrote:
>>>>>>
>>>>>>> Often on embedded systems a cursor is not a valid input modality. On
>>>>>>> some of these systems, when the javafx toolkit initialises the native
>>>>>>> hardware cursor, it produces artefacts which can be seen on screen (in
>>>>>>> the framebuffer for example). This change adds a system property
>>>>>>> "monocle.cursor.enabled" that can disable the creation of a native
>>>>>>> cursor in each of the Monocle NativePlatform implementations in favour
>>>>>>> of a NullCursor which is a no-op implementation of the NativeCursor
>>>>>>> abstract class that all native cursors have to implement.
>>>>>>>
>>>>>>> NullCursor class already existed and was being returned for some
>>>>>>> implementations like AndroidPlatform and HeadlessPlatform. This change
>>>>>>> builds upon that and conditionally returns NullCursor for all platforms.
>>>>>>>
>>>>>>> A system property "monocle.debugcursor" has also been added to turn on
>>>>>>> logging of which NativeCursor has been selected when the toolkit
>>>>>>> initialises.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Commits:
>>>>>>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor
>>>>>>>
>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/5/files
>>>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00
>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980
>>>>>>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod
>>>>>>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff
>>>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5
>>>>>>
>>>>>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java
>>>>>> line 50:
>>>>>>
>>>>>>> 49: AccessController.doPrivileged((PrivilegedAction)
>>>>>>> () -> {
>>>>>>> 50: final String str =
>>>>>>> 51: System.getProperty("monocle.debugcursor", "");
>>>>>>
>>>>>> Just a nit, but why `monocle.debugcursor` rather than
>>>>>> `monocle.cursor.debug` (my preference), or at least
>>>>>> `monocle.debugCursor`? Below is the full list, for comparison, including
>>>>>> the two added by this pull request.
>>>>>>
>>>>>> monocle.cursor.enabled
>>>>>> monocle.debugcursor
>>>>>> monocle.epd.bitsPerPixel
>>>>>> monocle.epd.enableInversion
>>>>>> monocle.epd.forceMonochrome
>>>>>> monocle.epd.noWait
>>>>>> monocle.epd.rotate
>>>>>> monocle.epd.useDitheringY1
>>>>>> monocle.epd.useDitheringY4
>>>>>> monocle.epd.waveformMode
>>>>>> monocle.epd.y8inverted
>>>>>> monocle.input..flipXY
>>>>>> monocle.input..maxX
>>>>>> monocle.input..maxY
>>>>>> monocle.input..minX
>>>>>> monocle.input..minY
>>>>>> monocle.input..touchFilters
>>>>>> monocle.input.touchFilters
>>>>>> monocle.input.touchRadius
>>>>>> monocle.input.traceEvents
>>>>>> monocle.input.traceEvents.verbose
>>>>>> monocle.maliSignedStruct
>>>>>> monocle.platform
>>>>>> monocle.platform.traceConfig
>>>>>>
Re: [Rev 01] RFR: 8087980: Add property to disable Monocle cursor
The pull request has been updated with additional changes. Added commits: - 1f6e282d: changed from system propert debug logging to javafx platform logger Changes: - all: https://git.openjdk.java.net/jfx/pull/5/files - new: https://git.openjdk.java.net/jfx/pull/5/files/cfbbc7dd..1f6e282d Webrevs: - full: https://webrevs.openjdk.java.net/jfx/5/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/5/webrev.00-01 Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 Stats: 14 lines in 1 file changed: 5 ins; 7 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 PR: https://git.openjdk.java.net/jfx/pull/5
Re: RFR: 8087980: Add property to disable Monocle cursor
On Wed, 13 Nov 2019 21:34:06 GMT, John Neffenger
wrote:
> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green
> <12861109+dellgr...@users.noreply.github.com> wrote:
>
>> Often on embedded systems a cursor is not a valid input modality. On some of
>> these systems, when the javafx toolkit initialises the native hardware
>> cursor, it produces artefacts which can be seen on screen (in the
>> framebuffer for example). This change adds a system property
>> "monocle.cursor.enabled" that can disable the creation of a native cursor in
>> each of the Monocle NativePlatform implementations in favour of a NullCursor
>> which is a no-op implementation of the NativeCursor abstract class that all
>> native cursors have to implement.
>>
>> NullCursor class already existed and was being returned for some
>> implementations like AndroidPlatform and HeadlessPlatform. This change
>> builds upon that and conditionally returns NullCursor for all platforms.
>>
>> A system property "monocle.debugcursor" has also been added to turn on
>> logging of which NativeCursor has been selected when the toolkit initialises.
>>
>>
>>
>> Commits:
>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor
>>
>> Changes: https://git.openjdk.java.net/jfx/pull/5/files
>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980
>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod
>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff
>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java
> line 50:
>
>> 49: AccessController.doPrivileged((PrivilegedAction) () -> {
>> 50: final String str =
>> 51: System.getProperty("monocle.debugcursor", "");
>
> Just a nit, but why `monocle.debugcursor` rather than `monocle.cursor.debug`
> (my preference), or at least `monocle.debugCursor`? Below is the full list,
> for comparison, including the two added by this pull request.
>
> monocle.cursor.enabled
> monocle.debugcursor
> monocle.epd.bitsPerPixel
> monocle.epd.enableInversion
> monocle.epd.forceMonochrome
> monocle.epd.noWait
> monocle.epd.rotate
> monocle.epd.useDitheringY1
> monocle.epd.useDitheringY4
> monocle.epd.waveformMode
> monocle.epd.y8inverted
> monocle.input..flipXY
> monocle.input..maxX
> monocle.input..maxY
> monocle.input..minX
> monocle.input..minY
> monocle.input..touchFilters
> monocle.input.touchFilters
> monocle.input.touchRadius
> monocle.input.traceEvents
> monocle.input.traceEvents.verbose
> monocle.maliSignedStruct
> monocle.platform
> monocle.platform.traceConfig
> monocle.screen.fb
> monocle.stackSize
>
> I'm nervous about our hidden API of system properties, and I'm as guilty as
> anyone with the nine properties I added for Monocle EPD. I think it might be
> okay as long as the code gets the property values only during class
> initialization. That should restrict their use to startup scripts and keep
> them out of application code trying to modify them *on-the-fly* at run time.
if i recall i originally started with the format you recommend as it made more
sense, and when looking for other debug logging across the javafx stack I
picked up on somewhat of a loose existing convention so changed to match it. I
guess it can be whatever everyone agrees upon. :)
PR: https://git.openjdk.java.net/jfx/pull/5
Re: RFR: 8087980: Add property to disable Monocle cursor
On Wed, 13 Nov 2019 19:57:04 GMT, Kevin Rushforth wrote: > On Tue, 29 Oct 2019 11:31:18 GMT, Kevin Rushforth wrote: > >> On Tue, 29 Oct 2019 10:10:32 GMT, Dell Green >> wrote: >> >>> On Tue, 29 Oct 2019 09:53:28 GMT, Johan Vos wrote: >>> >>>> On Tue, 8 Oct 2019 12:03:46 GMT, Kevin Rushforth wrote: >>>> >>>>> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green >>>>> <12861109+dellgr...@users.noreply.github.com> wrote: >>>>> >>>>>> Often on embedded systems a cursor is not a valid input modality. On >>>>>> some of these systems, when the javafx toolkit initialises the native >>>>>> hardware cursor, it produces artefacts which can be seen on screen (in >>>>>> the framebuffer for example). This change adds a system property >>>>>> "monocle.cursor.enabled" that can disable the creation of a native >>>>>> cursor in each of the Monocle NativePlatform implementations in favour >>>>>> of a NullCursor which is a no-op implementation of the NativeCursor >>>>>> abstract class that all native cursors have to implement. >>>>>> >>>>>> NullCursor class already existed and was being returned for some >>>>>> implementations like AndroidPlatform and HeadlessPlatform. This change >>>>>> builds upon that and conditionally returns NullCursor for all platforms. >>>>>> >>>>>> A system property "monocle.debugcursor" has also been added to turn on >>>>>> logging of which NativeCursor has been selected when the toolkit >>>>>> initialises. >>>>>> >>>>>> >>>>>> >>>>>> Commits: >>>>>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >>>>>> >>>>>> Changes: https://git.openjdk.java.net/jfx/pull/5/files >>>>>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >>>>>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >>>>>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >>>>>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 >>>>> >>>>> This has not yet been reviewed. It will need at least one reviewer with a >>>>> Reviewer role in the project. >>>>> >>>>> >>>>> >>>>> Disapproved by kcr (Lead). >>>> >>>> Is this PR open for review now? Or will a new PR be created? >>> >>> this is ready for review form my perspective. :) >> >> The Skara tooling bug in question has been fixed, so yes this is ready for >> review. > > I have no particular issue one way or the other on this. I will defer the > review to @johanvos As a follow up, if its desirable for javafx to be used in IOT/embedded devices, we should fix this issue, otherwise it doesn't look as slick on startup when i put it next to competing devices. :) PR: https://git.openjdk.java.net/jfx/pull/5
Re: RFR: 8087980: Add property to disable Monocle cursor
On Tue, 29 Oct 2019 09:53:28 GMT, Johan Vos wrote: > On Tue, 8 Oct 2019 12:03:46 GMT, Kevin Rushforth wrote: > >> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green >> <12861109+dellgr...@users.noreply.github.com> wrote: >> >>> Often on embedded systems a cursor is not a valid input modality. On some >>> of these systems, when the javafx toolkit initialises the native hardware >>> cursor, it produces artefacts which can be seen on screen (in the >>> framebuffer for example). This change adds a system property >>> "monocle.cursor.enabled" that can disable the creation of a native cursor >>> in each of the Monocle NativePlatform implementations in favour of a >>> NullCursor which is a no-op implementation of the NativeCursor abstract >>> class that all native cursors have to implement. >>> >>> NullCursor class already existed and was being returned for some >>> implementations like AndroidPlatform and HeadlessPlatform. This change >>> builds upon that and conditionally returns NullCursor for all platforms. >>> >>> A system property "monocle.debugcursor" has also been added to turn on >>> logging of which NativeCursor has been selected when the toolkit >>> initialises. >>> >>> >>> >>> Commits: >>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/5/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 >> >> This has not yet been reviewed. It will need at least one reviewer with a >> Reviewer role in the project. >> >> >> >> Disapproved by kcr (Lead). > > Is this PR open for review now? Or will a new PR be created? this is ready for review form my perspective. :) PR: https://git.openjdk.java.net/jfx/pull/5
Subject: RFR: 8087980: Add property to disable Monocle cursor
Please review the fix for Add property to disable Monocle cursor: https://bugs.openjdk.java.net/browse/JDK-8087980 https://github.com/openjdk/jfx/pull/5
RFR: 8231870: Updated armv6hf crosslibs script with new domains
Please review the fix for Updated armv6hf crosslibs script with new domains: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 https://github.com/openjdk/jfx/pull/8
RFR: JDK-8087980, JDK-8088412: Add property to disable Monocle cursor
Please review the fix for Add property to disable Monocle cursor: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8087980 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8088412 https://github.com/javafxports/openjdk-jfx/issues/489 https://github.com/javafxports/openjdk-jfx/pull/493
RE: Can Javafx cursor be disabled?
Hi Michael, Thanks for the awesome suggestion. I am compiling my own jdk and javafx, so i can patch it for my needs as you suggest. On further investigations I also see that the AndroidPlatform and the HeadlessPlatform just return a NullCursor on their createCursor methods which is a no-op implementation of cursor interface, so this also looks like an option. Further option would be at the application implementation level so that cursor disabling feature can be used across all platforms I have put up an issue request and will submit a pull request if my investigations are successful. https://github.com/javafxports/openjdk-jfx/issues/489 many thanks -- Message: 2 Date: Mon, 3 Jun 2019 07:25:42 + From: Doswald Michael <mailto:michael.dosw...@schiller.ch> To: "openjfx-dev@openjdk.java.net"<mailto:openjfx-dev@openjdk.java.net> <mailto:openjfx-dev@openjdk.java.net> Subject: RE: Can Javafx cursor be disabled? Message-ID: <mailto:a071e13eef344130a54be6ef685a9...@schiller.ch> Content-Type: text/plain; charset="iso-8859-1" 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: 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: 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 ** End of openjfx-dev Digest, Vol 91, Issue 3 **
Re: Can Javafx cursor be disabled?
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@openjdk.java.net" > Subject: RE: Can Javafx cursor be disabled? > Message-ID: > > > > 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@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@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@openjdk.java.net" > Subject: RE: Can Javafx cursor be disabled? > Message-ID: > > > > 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@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 > ** >
JavaFx12 Armhf 50% cpu usage
Hi Guys, I don't know if anyone has any ideas where to start with troubleshooting this one, but currently we have an embedded product running oracle java 8 with javafx. We are currently in the process of testing openjdk12+javaFx12. Everything has been running fine, however we have just noticed that when idle the cpu usage on the target device is 50% when running the hello world Javafx application from Netbeans. In our previous device with javaFX8 when idle the cpu usage is 0%. There is a lot more investigation to be done our end yet to try and narrow the issue and profile it to pinpoint the issue, but I was wondering if anyone else was seeing this on armhf, or have any ideas would could be the issue? I can see in the java bugs database that in the past there have been the odd similar issue with high constant cpu usage which got resolved in the past, however the helloworld app only has a hello world Button with eventhandler on the stage so not much going on there, which make we think the problem lies lower down in the rendering. I am getting hardware acceleration according to the prism.verbose output so cpu shouldn't be being used for rendering any thoughts greatly appreciated :)
RFR: 8167068 Error undefined pixcoord
Please review the fix for The Bug Synopsis: https://github.com/javafxports/openjdk-jfx/pull/312 https://github.com/javafxports/openjdk-jfx/issues/273 https://bugs.openjdk.java.net/browse/JDK-8167068
Cross Compilling linux Arm OpenJdk9 javaFx
Currently use Arm java8 from Oracle and compile Openjfx for Arm and overlay
libraries for current product line. Looking to test Java9 on Arm and upgrade
product line in next generation release.
Cross Compiling openJdk9 for Arm works fine
Trying to compile openJfx from http://hg.openjdk.java.net/openjfx/jfx-dev/rt
Running gradle -PCOMPILE_TARGETS=armv6hf produces swing errors even though
COMPILE_SWING is false in build.gradle.
home/dell/Documents/IwOpenJdk9/src/openjfx/rt/modules/javafx.swing/src/main/java/module-info.java:36:
error: file should be on source path, or on patch path for module
module javafx.swing {
/home/dell/Documents/IwOpenJdk9/src/openjfx/rt/modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/SwingNodeHelper.java:26:
error: file should be on source path, or on patch path for module
package com.sun.javafx.embed.swing;
Problem seems to be with build.gradle line 2154 which has swing tasks being
disabled if COMPILE_SWING is false. However this code is commented out.
/* should not be built, but needed in JMX
tasks.all {
if (!COMPILE_SWING) it.enabled = false
}
*/
if I uncomment it these errors go away and the build completes.
The resulting armv6hf-modular-sdk folder created by the build is added to jdk
configure script with '-with-import-modules=' option as per build instructions.
Building the jdk now fails with java.base module FindException, are these 2
problems related?
Note: Recompile with -Xlint:unchecked for details.
Error: Module javafx.base not found
java.lang.module.FindException: Module javafx.base not found
at java.base/java.lang.module.Resolver.findFail(Resolver.java:889)
at java.base/java.lang.module.Resolver.resolve(Resolver.java:128)
at java.base/java.lang.module.Configuration.resolve(Configuration.java:357)
at java.base/java.lang.module.Configuration.resolve(Configuration.java:187)
at
jdk.jlink/jdk.tools.jlink.internal.Jlink$JlinkConfiguration.resolve(Jlink.java:242)
at
jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:439)
at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:386)
at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:263)
at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54)
at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:33)
make3<http://10.10.10.40:8080/redmine/issues/47321#fn3>: ***
[/home/dell/Documents/IwOpenJdk9/src/jdk9dev/build/linux-arm-normal-client-release/images/jre/bin/java]
Error 1
Images.gmk:144: recipe for target
'/home/dell/Documents/IwOpenJdk9/src/jdk9dev/build/linux-arm-normal-client-release/images/jre/bin/java'
failed
Dell Green
Software Manager
t: (+44) 203 668 9870
ideaworks.co.uk<http://www.ideaworks.co.uk/>
[cid:LogoEmailFootter_0829c9d5-b4ed-4548-99f2-5c300468734d.jpg]
206 Great Portland Street
London W1W 5QJ
[cid:bestcompanies2018_abc1b1a4-ffcc-4151-8af8-10f73f8862f6.png]<http://www.ideaworks.co.uk/2018/01/03/ideaworks-awarded-best-company-2018/>
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you are not the intended recipient or the person responsible for delivering the
email to the intended recipient, be advised that you have received this email
in error and that any use, dissemination, forwarding, printing, or copying of
this email is strictly prohibited. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Ideaworks
Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W
5QJ. Company Registration No. 3943726
Re: Planning for JavaFX.next
Hi There, Apologies if the following seems trivial or thats has already been done but: For our business and customers, we really would like support for having a single jar file that contains jar dependencies and native libraries, without using third party tools, writing custom loaders etc. It should be possible to have a single jar artefact that re-enforces “write once run anywhere” with its dependencies containing within and available on the class path, a bit like a war file I appreciate the jvm cannot be contained within and thats fine I’ll use native packing for this. Up to now we have had to use third party solutions, like fatjar, onejar, jna etc, or decompress jars and include class files into main jar. Now I know people are going to shout ’native packaging’ etc, but most of our products just contain java code, and it seems unnecessary complication in most our our deployments to set up our build servers to build on mac, linux and windows just to include a native artefact for each platform, when the actual runtime code doesn't care what platform it is on. We do use all these methods across a whole range of products but it would be nice to have the option of producing a self contained jar file to send to our field team regardless of what platform they are on. Supplying zips with jar and libs folder in it has proven to be problematic with on more than one occasion our field engineers, rightly or wrongly thinking the jar is the executable and taking that from the zip and leaving the everything else behind. Once again apologies if the is functionality is now already available or coming in java9 that I am not aware of. Dell Green R Software Manager t: (+44)203 668 9870 206 Great Portland Street London W1W 5QJ Ideaworks (London) Ltd is a company registered in England and Wales, Company Registration no: 3943726. Registered office: 206 Great Portland Street, London, W1W 5QJ. This email and its contents are confidential. If you have received this message in error, please notify us and delete it. Any views presented in this email are solely those of the author and do not necessarily represent those of the company.
Re: Is there a Anti-aliasing grayscale prism option?
Thanks for the reply Jim. Thats good to know. These a javafx.scene.shape.Circle nodes. I’ll try and figure out how to dump and convert the current frame buffer contents to a png as its on an embedded device using Java SE embedded 8 with EGL framebuffer configuration. I have our electronics people looking at the problem as well as I haven’t ruled out yet that its a screen or display driver problem. I wanted to rule out Java as the issue. Dell Green R Software Manager t: (+44)203 668 9870 On 1 Apr 2016, at 22:14, Jim Graham <james.gra...@oracle.com> wrote: > All Shape antialiasing should be grayscale. The only non-grayscale AA we > have is for text only, and that can be controlled using the fontSmoothingType > property on the Text node. Are these Text nodes or other nodes that show the > colored pixels? > > It might help to submit a small test case (as in, a couple of nodes) and a > screen-shot... > > ...jim > > On 4/1/2016 1:59 PM, Dell Green wrote: >> >> >> Hi Guys, >> >> I am designing a grayscale javafx application for an RGB666 LCD screen. >> When I display it on screen the antialiasing contains the odd pink and blue >> pixels in the anti-aliasing. >> I am seeing this on shape anti-aliasing. >> Is there a system property (prism?) I can pass in the will change the >> anti-aliasing algorithm to us a grayscale anti-aliasing? >> >> I have set all colors used in the applications to grayscale by calling >> Color.grayscale() >> >> Dell Green >> R Software Manager >> t: (+44)203 668 9870 >> >> >> >> >> 206 Great Portland Street >> London W1W 5QJ >> >> >> Ideaworks (London) Ltd is a company registered in England and Wales, Company >> Registration no: 3943726. Registered office: 206 Great Portland Street, >> London, W1W 5QJ. This email and its contents are confidential. If you have >> received this message in error, please notify us and delete it. Any views >> presented in this email are solely those of the author and do not >> necessarily represent those of the company. >> 206 Great Portland Street London W1W 5QJ Ideaworks (London) Ltd is a company registered in England and Wales, Company Registration no: 3943726. Registered office: 206 Great Portland Street, London, W1W 5QJ. This email and its contents are confidential. If you have received this message in error, please notify us and delete it. Any views presented in this email are solely those of the author and do not necessarily represent those of the company.
Is there a Anti-aliasing grayscale prism option?
Hi Guys, I am designing a grayscale javafx application for an RGB666 LCD screen. When I display it on screen the antialiasing contains the odd pink and blue pixels in the anti-aliasing. I am seeing this on shape anti-aliasing. Is there a system property (prism?) I can pass in the will change the anti-aliasing algorithm to us a grayscale anti-aliasing? I have set all colors used in the applications to grayscale by calling Color.grayscale() Dell Green R Software Manager t: (+44)203 668 9870 206 Great Portland Street London W1W 5QJ Ideaworks (London) Ltd is a company registered in England and Wales, Company Registration no: 3943726. Registered office: 206 Great Portland Street, London, W1W 5QJ. This email and its contents are confidential. If you have received this message in error, please notify us and delete it. Any views presented in this email are solely those of the author and do not necessarily represent those of the company.
Re: VNC alternative for JavaFX running directly on framebuffer.
I am pretty sure that when i built an operating system for mx6 using yocto project I had the option for it to spit out x11 versions of libegl.so libs instead of framebuffer, although I was only interested in framebuffer option. Dell Green R Software Manager t: (+44)203 668 9870 206 Great Portland Street London W1W 5QJ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of Ideaworks Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W 5QJ. Company Registration No. 3943726
Armv6hf cross compile build compiles host version of some native libraries
Hi Guys, On closer inspection of running an Armv6hf build we have discovered that we are getting out host versions of some libraries in our build. Please see below for contents of our rt/lib/arm folder: gradle -PCOMPILE_TARGETS=armv6hf sdk build/armv6hf-sdk/rt/lib/arm/libdecora_sse.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=8052ae5d7f230ee0629743f9ee421371e3522538, not stripped build/armv6hf-sdk/rt/lib/arm/libfxplugins.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=87241c5679bcd9b7d738aff08a539f889d6105bb, not stripped build/armv6hf-sdk/rt/lib/arm/libglass_monocle.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=f9305441860f255079646812acf50ef46774317e, not stripped build/armv6hf-sdk/rt/lib/arm/libglass_monocle_x11.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=d1735e47b13e56d58d4e9b7a7f6dee338d9f, not stripped build/armv6hf-sdk/rt/lib/arm/libglass.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=6b349cfc4b349f858dd24f5cfbef7eb446c089cc, not stripped build/armv6hf-sdk/rt/lib/arm/libgstreamer-lite.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=b83f109a6b80bd56120e4bf8f8b7f5d1eb7b1bc8, not stripped build/armv6hf-sdk/rt/lib/arm/libjavafx_font_freetype.so:ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=3decd38bb952c5fefde54a1ad1f01b39799a45e6, not stripped build/armv6hf-sdk/rt/lib/arm/libjavafx_font_pango.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=5652ddbd48bf62a10213474aadc8b5bbfae3e494, not stripped build/armv6hf-sdk/rt/lib/arm/libjavafx_font.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=c84058878ffaeebf60be04eb0d138ecf3fdf5cd1, not stripped build/armv6hf-sdk/rt/lib/arm/libjavafx_iio.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=fd4e40c059944941d52bf88b48121d0815531bd0, not stripped build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2530edd674a52bb07c487b5cd726babc266b2013, not stripped build/armv6hf-sdk/rt/lib/arm/libjfxwebkit.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=0cd8f455ee93e101a5d4442027a8248d675a0888, stripped build/armv6hf-sdk/rt/lib/arm/libprism_common.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=658886a9bead9068f4111679e8f5f350386d235b, not stripped build/armv6hf-sdk/rt/lib/arm/libprism_es2_eglfb.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=25264a33f919a3a925ef2d2f8ec5d4a10bfbdbf9, not stripped build/armv6hf-sdk/rt/lib/arm/libprism_es2_monocle.so:ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=6827d044682876f8ace57cfdc3417e026688701c, not stripped build/armv6hf-sdk/rt/lib/arm/libprism_sw.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=1159563bbed17f830c3c64cdf16d3790fa91a713, not stripped We decided that those particular libraries were not required for the project we were currently doing so decided to use gradle.properties to disable the compiling of these. It turns out changing the gradle.properties values have no impact on the production of native libraries with them always being produced irrespective of any changes made to gradle.properties file. Also tried supplying the properties at command line to gradle command and some problem. Further investigation shows that the following messages are being piped to stdout during build whether I change anything or not, with the end result still compiling native libraries for these as host versions. "Not compiling native Media for armv6hf per configuration request" "Not compiling native Webkit for armv6hf per configuration request" Am I doing something wrong? I have followed instructions as per the wiki apart from installing QT 5.2 as don’t require webkit for my projects. Dell Green R Software Manager t: (+44)203 668 9870 206 Great Portland Street London W1W 5QJ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to th
OpenJFX armv6hf libjavafx_font_freetype.so x11
Hi Guys, Is it correct that “libjavafx_font_freetype.so” be linked against X libraries? as our embedded guys who are running without X were surprised to see this as they are running without X using monocle and frame buffer platforms on raspberry pi and MX6? Do we meet to install X11 if running in frame buffer modes? libjavafx_font_freetype.so: libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6f68000) libgtk-x11-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0 (0xb6bc) libgdk-x11-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0 (0xb6b24000) libatk-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libatk-1.0.so.0 (0xb6b0) libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 (0xb69c) libpangoft2-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpangoft2-1.0.so.0 (0xb69a4000) libpangocairo-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpangocairo-1.0.so.0 (0xb699) libgdk_pixbuf-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgdk_pixbuf-2.0.so.0 (0xb696c000) libcairo.so.2 => /usr/lib/arm-linux-gnueabihf/libcairo.so.2 (0xb689) libpango-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpango-1.0.so.0 (0xb6844000) libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0xb67b8000) libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0xb678) libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb673) libgthread-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgthread-2.0.so.0 (0xb6724000) librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6714000) libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0xb662) libXtst.so.6 => /usr/lib/arm-linux-gnueabihf/libXtst.so.6 (0xb6614000) libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb654) libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb64cc000) libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb64a4000) libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6484000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6354000) /lib/ld-linux-armhf.so.3 (0xb6f94000) libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb624) libXcomposite.so.1 => /usr/lib/arm-linux-gnueabihf/libXcomposite.so.1 (0xb6234000) libXdamage.so.1 => /usr/lib/arm-linux-gnueabihf/libXdamage.so.1 (0xb6228000) libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 (0xb6218000) libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb620) libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1 (0xb61f) libXinerama.so.1 => /usr/lib/arm-linux-gnueabihf/libXinerama.so.1 (0xb61e4000) libXi.so.6 => /usr/lib/arm-linux-gnueabihf/libXi.so.6 (0xb61d) libXrandr.so.2 => /usr/lib/arm-linux-gnueabihf/libXrandr.so.2 (0xb61c) libXcursor.so.1 => /usr/lib/arm-linux-gnueabihf/libXcursor.so.1 (0xb61b) libgmodule-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0xb61a4000) libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6184000) libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0xb616) libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0xb614c000) libharfbuzz.so.0 => /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0 (0xb60f4000) libpng12.so.0 => /lib/arm-linux-gnueabihf/libpng12.so.0 (0xb60cc000) libpixman-1.so.0 => /usr/lib/arm-linux-gnueabihf/libpixman-1.so.0 (0xb604) libxcb-shm.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-shm.so.0 (0xb6034000) libxcb-render.so.0 => /usr/lib/arm-linux-gnueabihf/libxcb-render.so.0 (0xb6024000) libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb6004000) libthai.so.0 => /usr/lib/arm-linux-gnueabihf/libthai.so.0 (0xb5ff4000) libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0xb5fc8000) libffi.so.5 => /usr/lib/arm-linux-gnueabihf/libffi.so.5 (0xb5fb4000) libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb5f7) libgraphite2.so.2.0.0 => /usr/lib/libgraphite2.so.2.0.0 (0xb5f54000) libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb5f48000) libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0xb5f3c000) libdatrie.so.1 => /usr/lib/arm-linux-gnueabihf/libdatrie.so.1 (0xb5f2c000) Dell Green R Software Manager t: (+44)203 668 9870 206 Great Portland Street London W1W 5QJ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are
Re: OpenJFX armv6hf libjavafx_font_freetype.so x11
great, many thanks, is it a correct assumption that if running javafx on embedded platform using monocle and framebuffer platforms (i.e no x11) if we run pmap on our Java process then we shouldn't see any linking to X related libraries? On 8 Dec 2015 19:55, openjfx-dev-requ...@openjdk.java.net wrote: > > Send openjfx-dev mailing list submissions to > openjfx-dev@openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > or, via email, send a message with subject or body 'help' to > openjfx-dev-requ...@openjdk.java.net > > You can reach the person managing the list at > openjfx-dev-ow...@openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openjfx-dev digest..." > > > Today's Topics: > > 1. OpenJFX armv6hf libjavafx_font_freetype.so x11 (Dell Green) > 2. [9] Review request for JDK-8144789: Incorrect assertion fails > in the GlassCursor.m (Morris Meyer) > 3. Re: OpenJFX armv6hf libjavafx_font_freetype.so x11 (David Hill) > 4. Re: Why there is no WebWorker like mechanism for JavaFX > (Tom Schindl) > 5. Re: Future of JavaFX (Mike Hearn) > > > ------ > > Message: 1 > Date: Tue, 8 Dec 2015 14:25:07 + Dell Green R Software Manager t: (+44)203 668 9870 > From: Dell Green <dell.gr...@ideaworks.co.uk> > To: "openjfx-dev@openjdk.java.net" <openjfx-dev@openjdk.java.net> > Subject: OpenJFX armv6hf libjavafx_font_freetype.so x11 > Message-ID: <9d740561-a52c-42d7-bf3b-716a431aa...@ideaworks.co.uk> > Content-Type: text/plain; charset="utf-8" > > > > Hi Guys, > > Is it correct that ?libjavafx_font_freetype.so? be linked against X > libraries? as our embedded guys who are running without X were surprised to > see this as they are running without X using monocle and frame buffer > platforms on raspberry pi and MX6? Do we meet to install X11 if running in > frame buffer modes? > > > libjavafx_font_freetype.so: > libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6f68000) > libgtk-x11-2.0.so.0 => > /usr/lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0 (0xb6bc) > libgdk-x11-2.0.so.0 => > /usr/lib/arm-linux-gnueabihf/libgdk-x11-2.0.so.0 (0xb6b24000) > libatk-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libatk-1.0.so.0 > (0xb6b0) > libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 > (0xb69c) > libpangoft2-1.0.so.0 => > /usr/lib/arm-linux-gnueabihf/libpangoft2-1.0.so.0 (0xb69a4000) > libpangocairo-1.0.so.0 => > /usr/lib/arm-linux-gnueabihf/libpangocairo-1.0.so.0 (0xb699) > libgdk_pixbuf-2.0.so.0 => > /usr/lib/arm-linux-gnueabihf/libgdk_pixbuf-2.0.so.0 (0xb696c000) > libcairo.so.2 => /usr/lib/arm-linux-gnueabihf/libcairo.so.2 > (0xb689) > libpango-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libpango-1.0.so.0 > (0xb6844000) > libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 > (0xb67b8000) > libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 > (0xb678) > libgobject-2.0.so.0 => > /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0xb673) > libgthread-2.0.so.0 => > /usr/lib/arm-linux-gnueabihf/libgthread-2.0.so.0 (0xb6724000) > librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6714000) > libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 > (0xb662) > libXtst.so.6 => /usr/lib/arm-linux-gnueabihf/libXtst.so.6 (0xb6614000) > libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 > (0xb654) > libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb64cc000) > libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb64a4000) > libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 > (0xb6484000) > libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6354000) > /lib/ld-linux-armhf.so.3 (0xb6f94000) > libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb624) > libXcomposite.so.1 => /usr/lib/arm-linux-gnueabihf/libXcomposite.so.1 > (0xb6234000) > libXdamage.so.1 => /usr/lib/arm-linux-gnueabihf/libXdamage.so.1 > (0xb6228000) > libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 > (0xb6218000) > libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb620) > libXr
Re: OpenJFX armv6hf libjavafx_font_freetype.so x11
OK great many thanks. I can wait a few days until your happy with your changes and commit them. ☺ Dell Green R Software Manager t: (+44)203 668 9870 206 Great Portland Street London W1W 5QJ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of Ideaworks Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W 5QJ. Company Registration No. 3943726
