Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8005095

Font utility running very slow on Mac with Java 6U37 and 7U10

    Details

    • Subcomponent:
      2d
    • Introduced In Version:
      7u9
    • CPU:
      other
    • OS:
      os_x

      Description

      Java version: 6U37, 7U9 and 7U10

      Last version it worked in: 6

      OS: Mac OS X 10.8.2

      Browser: Safari 6.0.2

      Hardware: MacBook Pro

      Applet Name and link:
      CharMap4.jar
      http://www.psc-consulting.ca/fenske/character-map-java.zip

      Bug description: A user reported the following - "I'm experiencing dramatic performance differences for a font utility between the Windows and Mac OS X platforms. While the application running on Windows 7 takes well below 1 second to list the characters for a given font, the same process will take 20" and more on a fairly recent MacBook Pro with CPU going up to 80%. This is obviously connected with the font class createGlyphVector method which is way less efficient on Mac OS X compared to Windows. I am wondering what your recommendation or workaround is. The current version works on Windows, but very, very inefficiently on my Mac and other Macs I tried. Never tested with previous versions. Speed comparison between Windows and my Mac (Verdana font; 835 fonts installed):

      47 vs. ca. 8000 msec!"

      Steps to reproduce: Run CharMap4.jar from http://www.psc-consulting.ca/fenske/character-map-java.zip
      Open CharMap4.java to see code

      This is what the author writes for speed measurements:

      Hi, Georg. I did some quick tests on my computer (Windows PC) with
      MAX_UNICODE set to 0xFFFF and using the "Verdana" font. The code as
      written takes 47 ms to enumerate the font. Using only canDisplay() takes
      31 ms. Using only createGlyphVector() and getGlyphCode() takes 188 ms.
      The timing code was:

           /* Enumerate all possible Unicode characters. */

           long startTime = System.currentTimeMillis();
           for (i = MIN_UNICODE; i <= MAX_UNICODE; i ++)
           {
             /* ... */
             if (charTemp[i] >= 0) // count each character as displayable ...
               charCount ++; // ... only if a non-spacing glyph found
           }
           System.err.println("elapsed = " + (System.currentTimeMillis() -
      startTime));

      This may help you find the slowest part. Try disabling or deleting the
      canDisplay() and continue statement, and get the timing. Then restore
      the canDisplay() code and disable/delete the following block:

      GlyphVector glyvector = panelFont.createGlyphVector(render, i); //
      get glyph list for this character
      int glycount = glyvector.getNumGlyphs(); // supposed number of glyphs
      for (k = 0; k < glycount; k ++) // for each glyph in the glyph vector
      {
       int glyph = glyvector.getGlyphCode(k); // get one glyph number
       if ((glyph >= 0) && (glyph < glyphCount) && (glyph != glymissing))
       { // ignore missing and spacing glyphs
         if (charTemp[i] < 0) // does this character already have a glyph?
           charTemp[i] = glyph; // no, save the first good glyph we find
         if (glyphChar[glyph] < 0) // does this glyph already have a char?
           glyphChar[glyph] = i; // no, save the first character we find
       }
      }



      Reproduced by Java.com team: Yes. Tested on Mac OSX 10.8.2, Java 6u37, 7U9 and 7u10 and Windows 7 Ultimate, SP1 and Java 7u9 and 7u10

      Downloaded the zip file from here: http://www.psc-consulting.ca/fenske/character-map-java.zip
      Click on CharMap4.jar
      Results:
      Mac OSX 34 seconds with Java 6u37 and 7u10
      Windows 7 1 second with Java 7u9 and 7u10

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              sharehma Shakeel Rehman (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: