search

oizma / angleproject

Automatically exported from code.google.com/p/angleproject
Other
0 stars 0 forks source link

Possible bug in translation of texture coordinates #72

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
http://crbug.com/46790 details a problem with the accelerated compositor in 
Chrome on Windows which looks like it might be caused by the translation of 
texture coordinates (and, in particular, pixel centers) that ANGLE performs. 
Would appreciate it if someone from TransGaming could look at the associated 
bug report.

Original issue reported on code.google.com by kbr@chromium.org on 9 Nov 2010 at 12:46

GoogleCodeExporter commented 9 years ago 
Nicolas will take a look, but are we sure this is an ANGLE problem? The linked 
bug report seems to imply that something similar has been seen on the Mac 
version as well.

Original comment by dan...@transgaming.com on 9 Nov 2010 at 2:22

GoogleCodeExporter commented 9 years ago 
ANGLE doesn't do any translation of texture coordinates, because Direct3D and 
OpenGL use the exact same coordinate system for texture sampling. The texels 
are stored 'upside down' but that's irrelevant. And we compensate for the 
difference in pixel center location by shifting all vertices half a pixel, in 
screen space (see dx_HalfPixelSize).

That said, I was able to reproduce some artifacts, but not exactly like the 
original report. The transformable box goes from 'colored' ClearType text to 
'greyscale' ClearType text. However it appears just as sharp to me, and I guess 
this behavior is desired to avoid color/subpixel mismatches. I did see the 
responses box below the transformable box become noticably blurry though as 
soon as I moved any of the sliders. 

Taking a closer look at that, I noticed it also went from colored to grayscale 
ClearType, but with blurring in every direction. So it doesn't appear to be a 
texture coordinate translation issue. It might be a mipmapping issue though...

(I used Chromium 9.0.578.0-65537 and I have a GeForce GTX 460 and Windows 7 x64)

Original comment by nicolas....@gmail.com on 9 Nov 2010 at 6:51

GoogleCodeExporter commented 9 years ago 
I'm not sure this is a problem with ANGLE. There have been conflicting reports 
about which operating systems on which the issue is reproducible. If you can 
see the problem with both ANGLE and --use-desktop=gl then it likely isn't a 
problem with ANGLE and this issue can be closed.

Original comment by kbr@chromium.org on 9 Nov 2010 at 7:04

GoogleCodeExporter commented 9 years ago 
Er, that should be --use-gl=desktop .

Original comment by kbr@chromium.org on 9 Nov 2010 at 7:11

GoogleCodeExporter commented 9 years ago 
Per an update to http://crbug.com/46790 it sounds like this is happening on 
Linux, so ANGLE can't be at fault. Please feel free to close this.

Original comment by kbr@chromium.org on 9 Nov 2010 at 7:15

GoogleCodeExporter commented 9 years ago 
I forced mipmapping off in ANGLE, and the blurring went away. And when using 
--use-gl=desktop, the blurring was back.

So it's not an ANGLE issue, but rather some mipmapping issue in the compositor.

Note that a lot of hardware/drivers use aggressive mipmapping optimizations to 
avoid aliasing and optimize performance. So either mipmapping should be 
disabled while rendering this text, or the texture sampling intrinsics with a 
bias argument can be used to ensure that the hardware rounds the LOD to the 
nearest mipmap level instead of up to the next higher (smaller) level.

Original comment by nicolas....@gmail.com on 9 Nov 2010 at 7:19

GoogleCodeExporter commented 9 years ago 
Correct if I'm wrong, but I thought Vangelis reverted the mipmapping patch, so 
there is currently no mipmapping in the compositor.

Can I be added as CC on this bug please?

Original comment by wjmacl...@chromium.org on 9 Nov 2010 at 7:39

GoogleCodeExporter commented 9 years ago

Original comment by kbr@chromium.org on 9 Nov 2010 at 7:45

GoogleCodeExporter commented 9 years ago 
The compositor doesn't currently create mips for any of the textures so I doubt 
mipmapping has anything to do with it. I'm somewhat perplexed as to why forcing 
mipmapping off in ANGLE makes a difference.

It is true that when text is rendered on a composited layer, we turn off 
subpixel anti-aliasing and use grayscale antialiasing only, which is what 
Nicolas observed.  This is true for both skia platforms (windows and linux).  
Not sure how that works on the mac.

As for the pixel centers, I still think there is a slight difference between 
ANGLE and GL.  Once my most recent compositor overhaul CL gets checked in I can 
produce a simple example that demonstrates the issue.

In any case, I think we can safely close this bug.

Original comment by vangelis@chromium.org on 9 Nov 2010 at 10:30

GoogleCodeExporter commented 9 years ago 
It's indeed not caused by mipmapping. When I vertically scroll the page the 
blurring sometimes goes away. I must have coincidentally scrolled the page to a 
blur-free location when I previously tested with mipmapping forced off.

Original comment by nicolas....@gmail.com on 10 Nov 2010 at 2:11

GoogleCodeExporter commented 9 years ago

Original comment by nicolas....@gmail.com on 10 Nov 2010 at 2:11

GoogleCodeExporter commented 9 years ago 
We are still having big problems with this in Chrome. Pixel-precise blittings 
(e.g. bitmap fonts) get blurry on DX backend and not on GL backend. I am able 
to reproduce similar artifacts by using DX directly.

Original comment by Ducker...@gmail.com on 26 Nov 2012 at 10:52

GoogleCodeExporter commented 9 years ago 
Then please create a new issue with a reproducing test case.

Original comment by dan...@transgaming.com on 26 Nov 2012 at 1:28

GoogleCodeExporter commented 9 years ago 
Done: http://code.google.com/p/angleproject/issues/detail?id=386

Original comment by Ducker...@gmail.com on 26 Nov 2012 at 2:22