Bug 106419 - does not produce Xft fonts on 1-bit pixmaps
Summary: does not produce Xft fonts on 1-bit pixmaps
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/glamor (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-06 12:41 UTC by Dmitry Karasik
Modified: 2018-12-13 18:25 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
test program (2.44 KB, text/plain)
2018-05-06 12:41 UTC, Dmitry Karasik
no flags Details
xorg.0.log (20.92 KB, text/plain)
2018-05-06 12:42 UTC, Dmitry Karasik
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Karasik 2018-05-06 12:41:53 UTC
Created attachment 139390 [details]
test program

OS Version: Ubuntu 16.04-xenial #146-Ubuntu 4.4.0-122-generic
Xorg Version: 1.18.3

Fontconfig fonts rendering via Xft/Xrender on the client and
through render/glamor on the server do not produce result when
the destination drawable is a 1-bit pixmap.

Please find the demonstration C program attached, that on my
laptop produces these results:

| depth=1
|        *
|         
|         
|         
| depth=24
|    **  *
| ******  
| ****    
| ***     


Where a 8x4 bitmap is produced in two versions, 1-bit and 24-bit, both are cleared
with color 0, then a single white pixel and a letter "r" is written on it. The 24-bit
produces (low-res, antialiased, but just for the sake of experiment) both glyph and 
pixel, and 1-bit produces pixel only.

I managed to produce good results after applying this fix:

--- /home/dk/src/xorg-server-1.18.3/glamor/glamor_utils.h	2016-04-04 20:33:37.000000000 +0200
+++ ./glamor_utils.h	2018-05-06 14:33:43.281740484 +0200
@@ -707,7 +707,8 @@
 
 /* For 1bpp pixmap, we don't store it as texture. */
 #define glamor_check_pixmap_fbo_depth(_depth_) (			\
-						_depth_ == 8		\
+						_depth_ == 1		\
+						|| _depth_ == 8		\
 						|| _depth_ == 15	\
 						|| _depth_ == 16	\
 						|| _depth_ == 24	\


where the output of the program is this:

| depth=1
|        *
|  ***    
|  *      
|  *      
| depth=24
|    **  *
| ******  
| ****    
| ***     

However the comment shows that 1-bit pixmaps are treated specially with regards
to the FBO allocation, and I'm fairly sure that if this change is not the best
fix, then the correct 1-bit rendering should be done elsewhere.

After digging in the source it seems that change came somewhere before
355334fcd99e4dce62e2be1e27290c9a74ea944f in 2012, which means that there might
be more unknowns in the setup that I have on my Ubuntu, if this bug was not
discovered in 6 years.

Unfortunately I couldn't build the latest xserver from github because it
requires many new libraries that I cannot install on the laptop without
breaking the existing installation. However if you need me to test patches, you
may backport them to 1.18.3 , as I can only experiment on this version. If
successfull, patches can also be sent to ubuntu/debian package maintainers.

Sincerely,
	Dmitry Karasik
Comment 1 Dmitry Karasik 2018-05-06 12:42:23 UTC
Created attachment 139391 [details]
xorg.0.log
Comment 2 Dmitry Karasik 2018-05-06 12:43:45 UTC
# build:
        gcc -I/usr/include/freetype2 test.c -o test -lX11 -lfontconfig -lXft
Comment 3 Dmitry Karasik 2018-05-06 16:29:45 UTC
UPDATE: Just tried on a fresh Ubuntu 18.04 that features Xorg v1.19.6. The issue is the same and the fix is the same.
Comment 4 GitLab Migration User 2018-12-13 18:25:06 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/87.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.