I added a note about removing Dprism.order=sw. On Wed, Mar 25, 2020 at 7:27 PM Tres Finocchiaro <tres.finocchi...@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.finocchi...@gmail.com > > > On Fri, Feb 21, 2020 at 5:13 PM Tres Finocchiaro < > tres.finocchi...@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.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 > >> > >> > >> >
