Xft - (incorrect ?) subpixel filtering.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Several moments:
1. Filtering algorithm in xftglyphs.c lines 508..520 (approx.) don't produces 
correct results.
(Definition of "correct" in this case is very subjective, though :-), but 
overall readability improvement could serve as a fair measurement.). Best 
seen on thin (one pixel wide)glyphs with vertical elements. F.e. 'i' or 'l'. 
While nonvertical elements of these glyphs are subpixel AA'ed, verticals do 
not. This behavior produces easily noticeable 'artifacts', visually marked as 
gray or slightly colored dots on or near purely black glyph.
I've implemented (very simple and inefficient, both in performance and 'color 
fringe' removal) 3-level filter, provided below. While incomplete and very 
limited in usage, it often gives "better" results (again, questionable, but 
at least it smoothes glyphs more evenly).
              	for (x = 0; x < width * hmul; x += hmul)                                                                     
                {                                                                                                            
#if 0                                                                                                                        
                    red = green = blue = 0;                                                                                  
                    o = 0;                                                                                                   
                    for (s = 0; s < 3; s++)                                                                                  
                    {                                                                                                        
                        red += filters[rf][s]*in[x+o];                                                                       
                        green += filters[gf][s]*in[x+o];                                                                     
                        blue += filters[bf][s]*in[x+o];                                                                      
                        o += os;                                                                                             
                    }                                                                                                        
                    red = red / 65536;                                                                                       
                    green = green / 65536;                                                                                   
                    blue = blue / 65536;                                                                                     
                    red += in[x+o];                                                                                          
                    green += in[x+o];                                                                                        
                    blue += in[x+o];                                                                                         
                    *out++ = (green << 24) | (red << 16) | (green << 8) | 
blue;                                              
#endif                                                                                                                       
                    hi1[0] = in[x ? x - 1 : x];                                                                              
                    hi1[1] = in[x];                                                                                          
                    hi1[2] = in[x+1];                                                                                        
                    hi1[3] = in[x+2];                                                                                        
                    hi1[4] = in[x+3 >= width*hmul ? x + 2 : x + 3];                                                          
                    red = ((hi1[0] * 65536)/5) + ((hi1[1] * 65536 * 3)/5) + 
((hi1[2] * 65536)/5);                            
                    green = ((hi1[1] * 65536)/5) + ((hi1[2] * 65536 * 3)/5) + 
((hi1[3] * 65536)/5);                          
                    blue = ((hi1[2] * 65536)/5) + ((hi1[3] * 65536 * 3)/5) + 
((hi1[4] * 65536)/5);                           
                    *out++ = ((red / 65536) << 16) | ((green / 65536) << 8) | 
(blue/65536);                                  
                }
 Limitations and drawbacks of this approach are obvious. First and foremost is 
unacessibility of pixel values outside of glyph's bitmap. Again, this is 
mostly visible on sans-serif fonts (serifs are 'widening' the bitmap, so 
vertical stems could be properly filtered on both sides) and thin vertical 
glyphs (Tahoma 8-10 pt. 'i','l' or 'H'). This is incurable with current 
implementation, when we're filtering each glyph separately. I think this 
needs to be done on the whole string. This will help also to ensure more 
smooth and visually pleasing transition from one glyph to another when 
they're near (0 or one pixel between them).


-- 
With all the best, yarick at relex dot ru.




[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux