Fixed Issue 344: Serious TextRenderer problems involving large fonts & unicode characters

The glyph-based rendering algorithm for the TextRenderer was
performing rendering in two steps: glyph preparation and upload, and
rendering. This structure doesn't work in the context of the
RectanglePacker, which can reorganize the backing store during any
upload.

Restructured the glyph cache in the TextRenderer in terms of flyweight
Glyph objects which know how to upload and render themselves. During
any upload, the outstanding glyphs not yet rendered to the screen may
thereby be flushed. Improved the code path which falls back to the
string-by-string algorithm for complex Unicode characters so that
incoming strings can be segmented into multiple parts which are
rendered either using the glyph cache or the string-by-string
algorithm.

Also tinkered with the bounds of glyphs and strings on the backing
store to try to more definitively eliminate bleed-over between
adjacent characters on the backing store, and to ensure that all of
the pixels of glyphs are drawn. Some heuristics are unfortunately
involved but the new code appears to work well with both very large
and very small fonts.

Added a few more test cases for the TextRenderer based on the bug
report. Tested with the previous test cases as well.


git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@1533 232f8b59-042b-4e1e-8c03-345bb8c30851

1 files changed, 10 insertions, 0 deletions

diff --git a/test/Issue344Test2.java b/test/Issue344Test2.java
new file mode 100755
index 000000000..b0900438c
--- /dev/null
+++ b/test/Issue344Test2.java
@@ -0,0 +1,10 @@
+public class Issue344Test2 extends Issue344Base {
+    protected String getText() {
+        // test 2 - unicode hangs program with a large font & long string
+        return "\u201Cabcdefghijklmnopqrstuvwxyz\u201D";
+    }
+
+    public static void main(String[] args) {
+        new Issue344Test2().run(args);
+    }
+}