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.finocchi...@gmail.com On Wed, Feb 19, 2020 at 2:46 AM Danny Gonzalez < danny.gonza...@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.finocchi...@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.finocchi...@gmail.com > > >
