Monocle as a replacement

Wed Apr 8 16:16:14 UTC 2020

I added a note about removing Dprism.order=sw.

On Wed, Mar 25, 2020 at 7:27 PM Tres Finocchiaro <tres.finocchiaro at gmail.com>
wrote:

> 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 at gmail.com
>
>
> On Fri, Feb 21, 2020 at 5:13 PM Tres Finocchiaro <
> tres.finocchiaro at 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 at gmail.com
> >
> >
> > On Wed, Feb 19, 2020 at 2:46 AM Danny Gonzalez <
> > danny.gonzalez at 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 at 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 at gmail.com
> >>
> >>
> >>
>