From andrea.vacondio at gmail.com Wed Apr 7 13:22:14 2021 From: andrea.vacondio at gmail.com (Andrea Vacondio) Date: Wed, 7 Apr 2021 15:22:14 +0200 Subject: PDF rendering using Canvas or PixelBuffer Message-ID: Hi, I hope this is the right channel, I'm creating a PDF tool where users can see thumbnails of the pages of a PDF file and do things on them (rotate, move, select, delete..). Pages are currently laid out in a Flow panel and I am evaluating different options to render them and so far I tried: 1 - PixelBuffer pretty much like it's used here https://github.com/mipastgt/JFXToolsAndDemos/blob/master/jfxtools-awtimage/src/main/java/de/mpmediasoft/jfxtools/awtimage/AWTImage.java 2 - Canvas using https://github.com/jfree/fxgraphics2d In both cases I used SAMBox https://github.com/torakiki/sambox a PDFBox fork, to render the pages (I can share more details if needed). I tried to profile both approaches and there is an order of magnitude in terms of memory consumption. Rendering a 300 pages file I get 700mb of heap used with the PixelBuffer approach and 60mb with the canvas. Moreover using the PixelBuffer implementation the application starts to do the robot dance and when I try to move the mouse around it moves in snaps with a considerable lag. With the Canvas impl everything is super responsive. I know others have experience with PDF rendering with JavaFX and maybe can share some thoughts on this. Currently the PixelBuffer impl is unusable for me and I'm trying to figure out if I'm doing something wrong or if these results are somehow expected.. or maybe there is a bug somewhere. Thanks Andrea From mp at jugs.org Wed Apr 7 16:23:38 2021 From: mp at jugs.org (Michael Paus) Date: Wed, 7 Apr 2021 18:23:38 +0200 Subject: PDF rendering using Canvas or PixelBuffer In-Reply-To: References: Message-ID: This is probably not the right place to discuss such issues. Stackoverflow might be better suited. But while we are at it there are a few issues you might want to look at. Initially I had similar problems like you but then I found that they were mostly caused by rendering too large images. Set the output size for the PDF renderer so that it has the same size as your Canvas, so that you do not render huge images which are lated just reduced to the desired output size by the ImageView. Am 07.04.21 um 15:22 schrieb Andrea Vacondio: > Hi, > I hope this is the right channel, I'm creating a PDF tool where users can > see thumbnails of the pages of a PDF file and do things on them (rotate, > move, select, delete..). Pages are currently laid out in a Flow panel and I > am evaluating different options to render them and so far I tried: > 1 - PixelBuffer pretty much like it's used here > https://github.com/mipastgt/JFXToolsAndDemos/blob/master/jfxtools-awtimage/src/main/java/de/mpmediasoft/jfxtools/awtimage/AWTImage.java > 2 - Canvas using https://github.com/jfree/fxgraphics2d > > In both cases I used SAMBox https://github.com/torakiki/sambox a PDFBox > fork, to render the pages (I can share more details if needed). > I tried to profile both approaches and there is an order of magnitude in > terms of memory consumption. Rendering a 300 pages file I get 700mb of heap > used with the PixelBuffer approach and 60mb with the canvas. Moreover using > the PixelBuffer implementation the application starts to do the robot dance > and when I try to move the mouse around it moves in snaps with a > considerable lag. With the Canvas impl everything is super responsive. > > I know others have experience with PDF rendering with JavaFX and maybe can > share some thoughts on this. Currently the PixelBuffer impl is unusable for > me and I'm trying to figure out if I'm doing something wrong or if these > results are somehow expected.. or maybe there is a bug somewhere. > Thanks > Andrea From andrea.vacondio at gmail.com Fri Apr 9 15:49:13 2021 From: andrea.vacondio at gmail.com (Andrea Vacondio) Date: Fri, 9 Apr 2021 17:49:13 +0200 Subject: PDF rendering using Canvas or PixelBuffer In-Reply-To: References: Message-ID: Thanks for the reply. I double checked and both implementations render the pages using the same parameters. Your hint got me thinking.. I have a zoom slider to drive thumbnails size and in the Canvas impl I scale the canvas node based on that while in the ImageView I was changing the size and using the fitTo methods so I thought maybe that causes the memory consumption differences. I changed the impl to scale the ImageView and match the Canvas impl but results are the same, 10x heap used with PixelBuffer. I'll review the code to make sure I'm not doing something different/wrong in my PixelBuffer impl but so far I get consistently 10x memory usage even with different PDF files. Il giorno mer 7 apr 2021 alle ore 18:24 Michael Paus ha scritto: > This is probably not the right place to discuss such issues. Stackoverflow > might be better suited. But while we are at it there are a few issues you > might want to look at. Initially I had similar problems like you but then > I found that they were mostly caused by rendering too large images. > Set the output size for the PDF renderer so that it has the same size > as your Canvas, so that you do not render huge images which are lated > just reduced to the desired output size by the ImageView. > > > Am 07.04.21 um 15:22 schrieb Andrea Vacondio: > > Hi, > > I hope this is the right channel, I'm creating a PDF tool where users can > > see thumbnails of the pages of a PDF file and do things on them (rotate, > > move, select, delete..). Pages are currently laid out in a Flow panel > and I > > am evaluating different options to render them and so far I tried: > > 1 - PixelBuffer pretty much like it's used here > > > https://github.com/mipastgt/JFXToolsAndDemos/blob/master/jfxtools-awtimage/src/main/java/de/mpmediasoft/jfxtools/awtimage/AWTImage.java > > 2 - Canvas using https://github.com/jfree/fxgraphics2d > > > > In both cases I used SAMBox https://github.com/torakiki/sambox a PDFBox > > fork, to render the pages (I can share more details if needed). > > I tried to profile both approaches and there is an order of magnitude in > > terms of memory consumption. Rendering a 300 pages file I get 700mb of > heap > > used with the PixelBuffer approach and 60mb with the canvas. Moreover > using > > the PixelBuffer implementation the application starts to do the robot > dance > > and when I try to move the mouse around it moves in snaps with a > > considerable lag. With the Canvas impl everything is super responsive. > > > > I know others have experience with PDF rendering with JavaFX and maybe > can > > share some thoughts on this. Currently the PixelBuffer impl is unusable > for > > me and I'm trying to figure out if I'm doing something wrong or if these > > results are somehow expected.. or maybe there is a bug somewhere. > > Thanks > > Andrea > > > From swpalmer at gmail.com Wed Apr 14 03:45:10 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 13 Apr 2021 23:45:10 -0400 Subject: Is the macOS option -Xdock:name only for AWT/Swing apps? Message-ID: <61E9C865-3E8C-4A88-B51D-A2CCA2F70EFB@gmail.com> Quick question is to macOS -specific option for the standard ?java? launcher: -Xdock:name= override default application name displayed in dock supposed to work for Java FX applications? Because it doesn?t. At least I?ve never seen it work. I know that the name in the dock doesn?t actually get changed.. I?ve looked at this bug report https://bugs.openjdk.java.net/browse/JDK-8173753 But the last comment on the bug explicitly states that the ?-Xdock:name is still able to change title in menubar.? will change, and it doesn?t. If it can?t, then the entire option makes no sense and shouldn?t be listed as an option. I know the ?right? thing to do is to get a proper experience is to use jpackage to get a ?real? application, but it?s been bugging me that the -Xdock:name option is there and doesn?t do anything. Regards, Scott