Monocle as a replacement

[Tres Finocchiaro]

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
>
>
>