Monocle as a replacement
nlisker at gmail.com
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>
> 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:
> > *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
> 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
> 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>
> > Danny,
> > Thanks this information is very valuable.
> > By using the provided patch, I too am able to re-use the Monocle
> > 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
> > (watching the DOM height -- we calculate the natural height and then
> > that for snapshot). In my case it was growing 300, 900, 2900, 8600
> > eventually crashing somewhere in buffer allocation. Hard-coding the
> > didn't suffer the same fate because it bypasses our attempts to
> > 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,
> > 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
> > - 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
> >> 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,
> >> a link to GitLab: https://gitlab.com/openjfxepd/jfxpatch/commit/
> >> <
> >> 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
> >> 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
> >> Is this the right place for such as discussion? Where's the best place
> >> ask about issues with Monocle?
> >> - Tres.Finocchiaro at gmail.com
More information about the openjfx-dev