|
Quick Lists
|
|
Bug ID:
|
6439274
|
|
Votes
|
0
|
|
Synopsis
|
OGL: overlapping LCD glyphs not rendered properly
|
|
Category
|
java:classes_2d
|
|
Reported Against
|
|
|
Release Fixed
|
mustang(b92)
|
|
State
|
10-Fix Delivered,
bug
|
|
Priority:
|
2-High
|
|
Related Bugs
|
|
|
Submit Date
|
15-JUN-2006
|
|
Description
|
A small bug was introduced with the recent changes for 6274813 (accelerate LCD glyphs
for OGL pipeline) that causes overlapping LCD glyphs to look wacky. To reproduce,
start SwingSet2 with (requires shader-level hardware):
-Dsun.java2d.opengl=True \
-Dsun.java2d.opengl.lcdshader=true \
-Dawt.useSystemAAFontSettings=lcd
The problem is easiest to see if you enable bold fonts. Look closely at certain words
like "Save" where the fringes of the 'a' and 'v' overlap, and notice that the 'v' seems
to obscure part of the 'a' when it should really be blended with the 'a'.
Posted Date : 2006-06-15 17:12:47.0
|
|
Work Around
|
N/A
|
|
Evaluation
|
This code was working at one point, so I must have broken it just before the putback
of 6274813. I noticed the visual problems recently but while debugging some unrelated
code I noticed that glGetError() was returning non-zero error codes after rendering
overlapping LCD glyphs. It turns out that there is a silly bug in
OGLTR_UpdateCachedDestination() when handling the overlapping case where we pass
a negative xoffset to glCopyTexSubImage2D(), which results in a GL_INVALID_VALUE
error to be generated and the operation fails. This explains why the readback fails
and the overlapping glyph is not blended properly with the previous glyph.
The problem is that we were calling:
j2d_glCopyTexSubImage2D(GL_TEXTURE_2D, 0,
cachedDestBounds.x1 - dx1,
cachedDestBounds.y2 - dy2, ...
The x/y values are relative to an upper-left origin, so dx1 will always be >=
cachedDestBounds.x1, and dy2 will always be <= cachedDestBounds.y2. So the y
calculation is okay (it will always be non-negative), but the x calculation is
broken such that it will always be non-positive. The fix is easy, we just need
to reverse the x calculation:
dx1 - cachedDestBounds.x1,
so that the xoffset is always non-negative.
Posted Date : 2006-06-15 17:12:47.0
|
|
Comments
|
Submitted On 23-JUL-2006
hlavac
Something seems to be still wrong, if I try the suggested SwingSet2 demo on b92 with the above system properties, it looks like the lower half of each glyph is corrupt (like it would be placed on top of black background when merging with the background).
My config is: Win XP 64bit, ATI Radeon 9800 Pro with latest drivers (Catalyst 6.6)
Submitted On 24-JUL-2006
chrispcampbell
Re: the problem with ATI Catalyst 6.6 drivers... This was one of the ATI driver bugs I mentioned in my blog (http://weblogs.java.net/blog/campbell/archive/2006/07/five_more_easy.html) that was fixed in their 8.27 Linux driver release. I am told by ATI that this will be fixed on the Windows side in their forthcoming Catalyst 6.7 release on Windows. Please try that when it becomes available and let us know if you're still seeing the problem.
Submitted On 31-JUL-2006
hlavac
Confirmed fixed with Catalyst 6.7
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |