[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Monocle as a replacement
From:       Tres Finocchiaro <tres.finocchiaro () gmail ! com>
Date:       2020-03-25 17:27:18
Message-ID: CANQs7dCSCLw66uN-wRoLERw2YL9UPr4BdQYfZj30VDq=bG_+Ew () mail ! gmail ! com
[Download RAW message or body]

With the help from a paid fx support channel, we're making headway with
this.  The main help was disabling the recommended software option.  At
time of writing this, I recommend this warning/detail is added to the wiki:
https://wiki.openjdk.java.net/display/OpenJFX/Monocle

Quoting:


> *If you are running the desktop build of JavaFX or OpenJFX then your only
> monocle option is Headless. Desktop JavaFX does not support the
> javafx.platform system property, but you can select Monocle
> with:-Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw*


In or case, removing "*-Dprism.order=sw"* was critical to prevent crashes
on MacOS and Windows.  We've yet to test on Linux.

Last, since Monocle introduces a virtual desktop size (and we're using this
desktop for screen captures), we'll be tweaking the "*-Dheadless.geometry=*"
parameter depending on available heap size.  These details are best tracked
downstream for those interested https://github.com/qzind/tray/pull/586.

Unless there are immediate questions, this will be the last update I
provide to the mailing list, all further updates will be specific to the
downstream implementation.

As an aside, we may decide to sponsor the fixing of the underlying crashes
as well (for example, d2d may not be available on Windows 2016 Core?) but
at the time of writing this, we're adopting workarounds to make it viable
on a standard Desktop.

- Tres.Finocchiaro@gmail.com


On Fri, Feb 21, 2020 at 5:13 PM Tres Finocchiaro <tres.finocchiaro@gmail.com>
wrote:

> Danny,
>
> Thanks this information is very valuable.
>
> By using the provided patch, I too am able to re-use the Monocle framework
> without suffering this bug.
>
> For those visiting this thread (e.g. through archive) at a later time,
> it's being tracked downstream here:
> https://github.com/qzind/tray/issues/576
>
> So applying it I was able to discover I was running into two separate
> issues...
>
>    - The first was the unpredictable buffer behavior you've shared, which
>    seems to be resolved that problem.  I used the recommended code, just in a
>    copy of the JavaFX 11 class instead.  Thanks!
>
>    - The second is a nuance of reusing the WebView and Stage using
>    Monocle, the stage/webview height calculation starts to grow out of control
>    (watching the DOM height -- we calculate the natural height and then use
>    that for snapshot).  In my case it was growing 300, 900, 2900, 8600
>    eventually crashing somewhere in buffer allocation.  Hard-coding the sizing
>    didn't suffer the same fate because it bypasses our attempts to calculate
>    the height using JavaScript.  Oddly, creating a fresh WebView each time
>    didn't correct the issue either.  I believe the underlying issue stems
>    somewhere from the stage height never resetting back, but attempts to do so
>    manually cause other issues, so I'll see if there's a viable workaround by
>    doing more renders using Monocle.
>
> We already have an open item with Gluon regarding WebView stage sizing, so
> this may be a race condition rearing its ugly head through a different
> symptom.  We'll continue to work on it separately.
>
> Danny, thanks again for the link to the patch.  We'll continue our testing.
>
> - Tres.Finocchiaro@gmail.com
>
>
> On Wed, Feb 19, 2020 at 2:46 AM Danny Gonzalez <
> danny.gonzalez@screamingfrog.co.uk> wrote:
>
>> Hi Tres,
>>
>> We also are suffering from this crash when running our TestFX unit tests,
>> particularly on Java 11.
>> It is due to a concurrency issue between the JavaFX thread and the
>> QuantumRenderer thread and there is an OpenJDK bug here:
>> https://bugs.openjdk.java.net/browse/JDK-8201567
>>
>> Quoting from this bug report:
>> "The QuantumRenderer calls the getPixels() method while trying to find a
>> buffer that's not in use, yet in doing so it can inadvertently modify a
>> buffer that's in use."
>>
>> There is also a related TestFX Bug:
>> https://github.com/TestFX/Monocle/issues/56
>>
>> There is a fix for this issue In the first comment of the JDK-8201567, in
>> a link to GitLab: https://gitlab.com/openjfxepd/jfxpatch/commit/
>> <https://gitlab.com/openjfxepd/jfxpatch/commit/f7c341775e5258e790a049f3fdce4a956ef665c7>
>>
>> We have used this patch in our local OpenJFX build.
>>
>> This has never been made into a pull request however but I believe it
>> should.
>>
>> Danny
>>
>> On 17 Feb 2020, at 19:12, Tres Finocchiaro <tres.finocchiaro@gmail.com>
>> wrote:
>>
>> Hi,
>>
>> I'm the developer of a printing plugin which leverages JavaFX for a few
>> HTML functions.
>>
>> One of our functions would greatly benefit from being "headless (or more
>> accurately, "silent") mode that Monocle offers and I'm evaluating the use
>> of Monocle on (non-headless) Desktops for this.  I'm currently testing a
>> monocle build by the TestFX team for MacOS.
>>
>> Although first test was positive, when invoking multiple times, I'm
>> getting
>> some internal errors similar to this:
>> https://stackoverflow.com/questions/49388497 and the framework grows
>> slower
>> and slower as it nears its final capture. (I'm using WebView.capture(...))
>>
>> Is this the right place for such as discussion? Where's the best place to
>> ask about issues with Monocle?
>>
>>
>> - Tres.Finocchiaro@gmail.com
>>
>>
>>
[prev in list] [next in list] [prev in thread] [next in thread]