9 Replies Latest reply: May 9, 2012 11:16 AM by StreamFlow RSS

    Very Slow Graphics Display Speed

    StreamFlow

      I have a lot of high resolution graphics in my FM documents.  The graphics are typically Tiff or PDF files that I bring into anchored graphics frames.  As I scroll through the document making changes, the graphics can take forever to display.  Sometimes taking one to two minutes to display a single graphic, often a lot longer.  It can take 10 to 15 minutes just to scroll through a 20 page document with 10 graphics.  When I am in 2-page display zoom level, the program sometimes gets caught in a loop, constantly redrawing the the first then the second graphic, then back to the first again.  I often have to kill the program with Task Manager. 

       

      I have a dual processor workstation, with the fastest processors available, 32 Gig of RAM, a 4-disk SSD running in RAID 0, and 2 Nvidia 590 GTX GPU's runnning in SLI.  All my other graphics programs display the same graphic files almost instantly, including AI, Photoshop, and Acrobat. I know that I can turn all the graphics off through the View menu, but that takes a lot away from checking on the look and feel of the document when we are proofing or making changes to it.  We recently migrated over from Ventura Publisher, and that program can display the same graphics in 5 to 10 seconds each.  Ventura had no problem with the any of the graphics that we threw at it.  Framemaker is supposed to be a better program, so am I doing something wrong?

       

      PS, this slow display occurs in FM 9 and well as FM 10.

        • 1. Re: Very Slow Graphics Display Speed
          Arnis Gubins ACP/MVPs

          You can quickly toggle graphics on or off using the "esc v v" shortcut to allow you to scroll through the document quickly.

           

          How are the graphics imported - by reference or by copy? Which version of FM? Are the files located on a local drive or a elsewhere on a network drive?

           

          With PDF files, FM internally converts these to EPS format and displays a lower-res preview image so these should display relatively quickly (it would be even faster if you saved the graphics as EPS from Acrobat). What flavour of TIFF are you using (i.e. compressed, RGB or CMYK, etc.)?

          • 2. Re: Very Slow Graphics Display Speed
            StreamFlow Community Member

            I am using FM 10, updated to the latest version.  I am inserting the graphics by reference, and the graphics are on the local drive.

            • 3. Re: Very Slow Graphics Display Speed
              StreamFlow Community Member

              The Tiff files are in RGB and are typically uncompressed.

              • 4. Re: Very Slow Graphics Display Speed
                Arnis Gubins ACP/MVPs

                How big are the TIFFs? Your workstation sounds like it shouldn't be having any resource issues with the graphics files. Which operating system and 32- or 64-bit?

                • 5. Re: Very Slow Graphics Display Speed
                  StreamFlow Community Member

                  The Tiff files that I have are typically in the 100-300 MB size.  I am using Win 7 64bit.  A file that I am having problems with right now is a single page document (a report cover page).  I am bringing in a 5 MB PDF and it is taking over 10 minutes to display.  It seems like it is trying to constantly redraw the graphic.  I tried saving the pdf as an eps with a preview (without a preview I just get a gray box), and it came in almost instantly at a low resolution as expected, which is fine for editing and previewing the document, but when I printed the page, the printed page had the low resolution graphic printed out, which looks terrible.

                   

                  When I bring in PDF's I dont think FM is trying to make a low resolution version for display.  The displayed version in FM is always as high a resolution as displayed in Acrobat or photoshop.

                  • 6. Re: Very Slow Graphics Display Speed
                    Bob Niland (Error 7103) Community Member

                    > The Tiff files are in RGB and are typically uncompressed.

                     

                    What dimensions & dpi ?

                     

                    Frame was optimized at the outset for EPS. With EPS, what the author sees is the embedded preview or thumbnail image, and it's adequately fast (but coarse).

                     

                    In my limited experience with PDF import (unstable on FM7), if the PDF contains a preview, Frame uses it.

                     

                    Anything else has to be rescaled for display, with perhaps more complex rendering even before that.

                     

                    Any rotation, or anamorphic scaling of the image aggravates matters. Rotated images are particularly slow to render.

                     

                    Other than B&W bitmap images, we routinely save-as or convert all other formats to EPS for import. We have a trivial batch process set up in Illustrator to handle large numbers of such files at a time.

                    ________

                    I recall 300 dpi 8x10 TIFFs taking 30 minutes to display on FM3.1 on a 386 PC.

                    • 7. Re: Very Slow Graphics Display Speed
                      Bob Niland (Error 7103) Community Member

                      > ... (without a preview I just get a gray box), ...

                       

                      Correct. You'd expect modern software to fake one, sigh. Saving with preview and/or thumbnail is an option in Illustrator when saving as EPS.

                       

                      > ... and it came in almost instantly at a low resolution as expected, which is fine for editing and previewing the document, but when I printed the page, the printed page had the low resolution graphic printed out, which looks terrible.

                       

                      You were printing to a non-PostScript printer (probably an HP or clone in PCL mode), and that is the expected result. If the printer has dual PDLs, print to it using its Ps driver.

                       

                      Frame apparently doesn't actually "print" EPS's, it just passes them through in the Ps. it would have to render the actual PostScript in the EPS to print to anything other PDL, so it doesn't.

                      • 8. Re: Very Slow Graphics Display Speed
                        Arnis Gubins ACP/MVPs

                        You're printing to a non-postscript device, if all you get is the low-res preview image. Create PDF output (and print from that).

                         

                        FM internally converts a PDF to EPS format (and the default preview image is fairly high-res with no control over this) for display and output. This has to be done for every PDF imported by reference every time it is accessed. Do it once in Acrobat and save yourself some time and resources. You can also convert the TIFFs to EPS for speedier display.

                        • 9. Re: Very Slow Graphics Display Speed
                          StreamFlow Community Member

                          Hi, thanks for your help, You are right, I am printing to an Epson, our HP with PS3 emulation is down.  I tried printing the document to a PDF and then printing the PDF on the Epson (which is what we do for final production anyway) and it came out just fine.  A lot of our graphics are roteted and/or scaled in FM to fit the frame so that is probably not helping.  Its strange though that the same graphic that displays in 3 seconds in Photoshop should take 3 minutes in FM.  The FM group must be using a different display engine than the PS group. 

                           

                          We were using eps as the common graphics format in Ventura becuse it couldnt import PDF's, so that is probably why it was displaying quickly.  When we saw that FM could import and display PDF's directly, we decided to save the step.  It would be nice if FM could create the eps automatically on initial import.  Thanks for your help, I think tht solves the problem.