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

LCD text blending isn't accounting for over-lapping glyphs.




      LCD text uses read back of the destination, then blending of each glyph on to the destination.
      For performance, the implementation copies the whole bounds of the node rather than on
      a per glyph basis.
      However its possible for glyphs to over-lap, in which case the blending of the 2nd of these
      to be rendered to be against the *updated* destination, including the first glyph, otherwise
      it will simply obliterate whatever part of the 1st glyph rendered into the overlapping rectangle.
      The results are obviously bad. The JDK has handled this by detecting such over-lapping cases
      in the rendering loop and doing a re-read as needed.
      The results are at best more fringing, and at worse obvious holes in glyphs.
      The test case for RT-19024 using Futura Light shows this clearly between the "t" and "e" of "text".
      If this is needed frequently, then the FX approach of copying all the node becomes far from optimal
      as you are reading back a lot per-glyph.
      What's more since FX defaults to fractional metrics (sub-pixel positioning), then glyphs are more
      likely to be placed close to each other.
      Also is possible that non-adjacent glyphs in the sequence might overlap, so really you need
      to check for overlap of a glyph with the accumulated bounds of the previous rendering.

      The only other possible solution that occurs is that the rendering be to the same read-back buffer
      so updates are implicit. This depends on being able to be sure of the order of processing by the
      hardware pipeline/driver. This might mean flushes where overlaps are detected which means
      we'd still need to check for over-laps even if we can avoid read backs.


          Issue Links



              Unassigned Unassigned
              prr Philip Race
              0 Vote for this issue
              3 Start watching this issue