Incorrect subpixel rendering on Windows

[GoogleCodeExporter]

I am using latest code snapshot (pulled from the trunk yesterday) and freetype 
2.4.9 (recompiled with FT_CONFIG_OPTION_SUBPIXEL_RENDERING option)

After spending few hours trying to get subpixel rendering to work in my code, I 
compiled freetype-gl  demo-subpixel sample, thinking I am doing something wrong.

Unfortunately, even demo-subpixel suffers from the same problem (please see 
attached image)

Some info about the configuration:

- Building and running on x64 Windows Server 2008 R2 (Win 7)

- Using NVidia 580 GTX with NVidia's drivers, all OpenGL settings are 
configured to defaults ("Application decide")

- Using freetype 2.4.9, recompiled with the FT_CONFIG_OPTION_SUBPIXEL_RENDERING 
option (and using patented algorithms, no legacy LCD filter - but that alone 
does not make any difference)

I tried changing LCD filters (light/default/legacy...) and this did not help at 
all :(   I triple-checked that I am using right freetype library.

One hint - if I remove the gamma correction operation in the fragment shader:

vec3 color = pow( vec3(r,g,b), vec3(1.0/vgamma));

The artifacts disappear.

Any idea what could be wrong?

Original issue reported on code.google.com by dimko...@gmail.com on 24 Jun 2012 at 10:38

Attachments:

• ftgl_nvidia580_win.png

[GoogleCodeExporter]

@add - if I remove the above line, the artifacts do disappear but the rendering 
is, of course, still wrong (see attached image).

Could it be something not working quite right with the vertex attributes?

Original comment by dimko...@gmail.com on 24 Jun 2012 at 10:42

Attachments:

• ftgl_nvidia580_nogamma.png

[GoogleCodeExporter]

Ok, some progress - if I directly "hardcode" vgamma in the text.vert and keep 
the gamma operation in the fragment shader, the display seems to be correct 
(see attached image)

So, it is definitely something related to the vertex attribute (gamma)

Original comment by dimko...@gmail.com on 24 Jun 2012 at 1:05

Attachments:

• ftgl_nvidia580_gamma_hardcoded.png

[GoogleCodeExporter]

Ok, found the problem finally:

In the text.vert,  attribute ashift should be defined before agamma.  Currently 
it is defined after it, and so the shader is mistakenly using ashift instead of 
agamma and vice versa. 

Original comment by dimko...@gmail.com on 24 Jun 2012 at 1:15

[GoogleCodeExporter]

Thanks, that was a quick bug report.

What bothers me is that you're right in saying ashift/agamme shoudl be swapped 
but it does not make a difference on my machine. Weird. I'll try to understand 
what's going on before applying your patch.

Original comment by Nicolas.Rougier@gmail.com on 25 Jun 2012 at 1:06

• Changed state: Started

[GoogleCodeExporter]

I suppose some OpenGL implementations are just smarter than others.

Tonight I will try running the same code on Intel HD 3000, and report if it 
behaves differently with regards to this issue.

Original comment by dimko...@gmail.com on 25 Jun 2012 at 1:16

[GoogleCodeExporter]

I think I'm wrong setting my own indices for generic attributes in the vertex 
buffer code.
I was lucky it worked until now and I will have to find some other solution.

Original comment by Nicolas.Rougier@gmail.com on 25 Jun 2012 at 2:53

[GoogleCodeExporter]

JFYI - I just tried the shaders on Intel HD 3000 (Sandy Bridge) - and it works 
regardless of the attribute order in the shader code, unlike NVidia.

Original comment by dimko...@gmail.com on 25 Jun 2012 at 7:30

[GoogleCodeExporter]

Actually my "workaround" does not work on ATI HD 6650M.  

So, I guess reworking the vertex attribute code is the only proper way to fix 
this.

Original comment by dimko...@gmail.com on 2 Jul 2012 at 8:53

[GoogleCodeExporter]

Ok, here is a quick and dirty fix,

Instead of having two generic attributes (shift, gamma) that might not get 
mapped correctly, I just "piggybacked" those value in the texture coordinate 
pointer.

I just extended the texture coordinate from 2 to 4 floats, and then use 
gl_MultiTexCoord.z and w values to store and retrieve shift/gamma per-vertex 
values.

Step 1:   self->buffer = vertex_buffer_new( "v3f:t4f:c4f" ); 

Step 2:   move shift/gamma floats up, below texture second coordinate in the 
glyph_vertex_t structure, so they are part of the tex. coord 4-vector

Step 3:   in the vertex shader:

    vshift = gl_MultiTexCoord0.z;
    vgamma = gl_MultiTexCoord0.w;

Of course, this is an ugly hack - but it will do at least for me until you 
implement generic vertex attribute handling with glBindAttribLocation()

Original comment by dimko...@gmail.com on 2 Jul 2012 at 9:55

[GoogleCodeExporter]

There is a gl-3.0 branch that should fix the problem.

Original comment by Nicolas.Rougier@gmail.com on 17 Sep 2012 at 7:18

• Changed state: Done