http://bugs.winehq.org/show_bug.cgi?id=23097
Summary: Subpixel rendering ignores registry setting Product: Wine Version: 1.2-rc2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv AssignedTo: wine-bugs@winehq.org ReportedBy: da_fox@mad.scientist.com
Created an attachment (id=28690) --> (http://bugs.winehq.org/attachment.cgi?id=28690) Example of ignored subpixel setting
Wine ignores the subpixel setting set in the registry. As can be seen in the attached image, I have disabled subpixel rendering by setting FontSmoothing to 0x00000000 instead of 0x00000002. Yet wine still renders the fonts with subpixel rendering.
This may be related to bug #17148, as I do have (and want) subpixel rendering for the rest of the desktop. However it should be possible to disable subpixel rendering in wine, while still allowing the rest of the desktop to be antialised.
http://bugs.winehq.org/show_bug.cgi?id=23097
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2010-06-09 06:17:33 --- That's on purpose. You can set Xft resources using the "Wine" class if you want Wine-specific behavior.
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #2 from Alexandre Julliard julliard@winehq.org 2010-06-09 06:22:24 --- (In reply to comment #1)
That's on purpose. You can set Xft resources using the "Wine" class if you want Wine-specific behavior.
Actually that doesn't work, there needs to be some other desktop mechanism for this. We can't use the registry settings because that would break it for everybody.
http://bugs.winehq.org/show_bug.cgi?id=23097
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #3 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-09 06:44:10 --- Closing invalid.
http://bugs.winehq.org/show_bug.cgi?id=23097
da_fox@mad.scientist.com da_fox@mad.scientist.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|INVALID |
--- Comment #4 from da_fox@mad.scientist.com da_fox@mad.scientist.com 2010-06-09 09:03:13 --- (In reply to comment #2)
(In reply to comment #1)
That's on purpose. You can set Xft resources using the "Wine" class if you want Wine-specific behavior.
Actually that doesn't work, there needs to be some other desktop mechanism for this. We can't use the registry settings because that would break it for everybody.
I'm sorry but I don't know what you're trying to say? Is there some other setting to disable subpixel rendering? Is there for example an option in winecfg to disable subpixel rendering?
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2010-06-09 09:10:11 --- (In reply to comment #4)
I'm sorry but I don't know what you're trying to say? Is there some other setting to disable subpixel rendering? Is there for example an option in winecfg to disable subpixel rendering?
No, there's no way to do that, the desktop configuration takes precedence. It's not clear to me why you don't want it in Wine if you have it for all other apps, any specific reason?
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #6 from da_fox@mad.scientist.com da_fox@mad.scientist.com 2010-06-09 09:27:21 --- (In reply to comment #5)
(In reply to comment #4)
I'm sorry but I don't know what you're trying to say? Is there some other setting to disable subpixel rendering? Is there for example an option in winecfg to disable subpixel rendering?
No, there's no way to do that, the desktop configuration takes precedence. It's not clear to me why you don't want it in Wine if you have it for all other apps, any specific reason?
Yes, as you can see currently wine's subpixel rendering differs significantly from the rest of the desktop (to me it looks very blurry), so I'd rather disable subpixel rendering altogether than use it as-is. If it were the same as the rest of my desktop that would be okay too.
http://bugs.winehq.org/show_bug.cgi?id=23097
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k@gmail.com
--- Comment #7 from Roderick Colenbrander thunderbird2k@gmail.com 2010-06-09 12:22:56 ---
No, there's no way to do that, the desktop configuration takes precedence. It's not clear to me why you don't want it in Wine if you have it for all other apps, any specific reason?
Yes, as you can see currently wine's subpixel rendering differs significantly from the rest of the desktop (to me it looks very blurry), so I'd rather disable subpixel rendering altogether than use it as-is. If it were the same as the rest of my desktop that would be okay too.
Perhaps the fonts your copy of Wine is using don't look that great with subpixel rendering. Just for testing what happens if you select the same font in Wine as your desktop is using? Does it look the same then?
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #8 from da_fox@mad.scientist.com da_fox@mad.scientist.com 2010-06-09 15:13:17 --- (In reply to comment #7)
No, there's no way to do that, the desktop configuration takes precedence. It's not clear to me why you don't want it in Wine if you have it for all other apps, any specific reason?
Yes, as you can see currently wine's subpixel rendering differs significantly from the rest of the desktop (to me it looks very blurry), so I'd rather disable subpixel rendering altogether than use it as-is. If it were the same as the rest of my desktop that would be okay too.
Perhaps the fonts your copy of Wine is using don't look that great with subpixel rendering. Just for testing what happens if you select the same font in Wine as your desktop is using? Does it look the same then?
I'm sorry but I'm having some trouble changing the font wine uses. How exactly is this done? There appears to be no setting for it in winecfg. There used to be a way to set the default font in the [font] section of wine.inf, but this has been deprecated in favor of setting the font via regedit. However the exact keys to use appear to be kept secret. I've already spent quite some time on google, but I can't find a way to change the default wine font. If you could please tell me how to change the font I can test for you. However it seems as though that would be a separate bug (wine not rendering the font in the manner specified in the system config). It would still be nice to be able to disable fontsmoothing just for wine alone, so applications look the same in wine as they do on a windows desktop with no font smoothing.
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #9 from Vitaliy Margolen vitaliy@kievinfo.com 2010-06-09 19:11:34 --- (In reply to comment #8)
There appears to be no setting for it in winecfg.
Look closer (Desktop integration tab).
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #10 from da_fox@mad.scientist.com da_fox@mad.scientist.com 2010-06-10 05:54:32 --- (In reply to comment #9)
(In reply to comment #8)
There appears to be no setting for it in winecfg.
Look closer (Desktop integration tab).
I think you mean to select every item and then choose a font. But this does not allow you to change the default font. It only allows one to change the font for the "Active Title Text", "Menu Text", "Message Box Text" and "ToolTip Text", but NOT for the "Window Text" (see screenshot, the 'Font...' button is disabled). I have picked the "Comic Sans MS" font with size 10px for all entries that could be changed (e.g. those listed above). As can be seen only the menu text has changed. The menu text in regedit looks fatter and less sharp than the menu text of the text-editor in the background. I have magnified the word "View", so you can see that in particular the letter 'i' is rendered very differently, spread horizontally across 3 pixels instead of being just 1 pixel wide.
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #11 from da_fox@mad.scientist.com da_fox@mad.scientist.com 2010-06-10 05:55:29 --- Created an attachment (id=28715) --> (http://bugs.winehq.org/attachment.cgi?id=28715) Changing "all" fonts in wine to Comic Sans MS
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #12 from da_fox@mad.scientist.com da_fox@mad.scientist.com 2010-06-14 02:46:44 --- (In reply to comment #11)
Created an attachment (id=28715)
--> (http://bugs.winehq.org/attachment.cgi?id=28715) [details]
Changing "all" fonts in wine to Comic Sans MS
For a better example of the difference in font rendering between wine and the rest of the system please see bug #23114, where I've added an attachment showing the same font used a text-editor and wine's notepad.exe.
However, in any case I still would like to have the ability to disable font anti-aliasing/subpixel rendering in wine, while still allowing the rest of the desktop to use different settings.
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #13 from da_fox@mad.scientist.com da_fox@mad.scientist.com 2010-06-16 06:10:10 --- (In reply to comment #7)
No, there's no way to do that, the desktop configuration takes precedence. It's not clear to me why you don't want it in Wine if you have it for all other apps, any specific reason?
Yes, as you can see currently wine's subpixel rendering differs significantly from the rest of the desktop (to me it looks very blurry), so I'd rather disable subpixel rendering altogether than use it as-is. If it were the same as the rest of my desktop that would be okay too.
Perhaps the fonts your copy of Wine is using don't look that great with subpixel rendering. Just for testing what happens if you select the same font in Wine as your desktop is using? Does it look the same then?
So what are your feelings on this? Does it look like 'intended behaviour'? Would you consider this an 'improvement' (take a look especially at the screenshot in bug #23114) ? Would you say that wine's fonts 'don't look that great' or are you more inclined to describe this as 'wine's fonts look absolute horrible, something should be done about this!'?
http://bugs.winehq.org/show_bug.cgi?id=23097
Alexey Loukianov mooroon2@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mooroon2@mail.ru
--- Comment #14 from Alexey Loukianov mooroon2@mail.ru 2010-06-22 02:36:43 --- I repost here small part of the comment #4 for the bug #23114:
... as now wine seems to be declaring that it will "Use the system desktop setting for subpixel font smoothing" (bug #17148 marked as CLOSED FIXED) it would be great to know two things: 1. What is the place this "system desktop setting" are taken from? 2. Are there any ways to set Wine to use other fonts AA settings than one detected to be set for the "system desktop"?
If the answer for the question 2 is "no ways" then it is definitely a regression in Wine functionality as before it was possible to have one settings for Wine apps and another for other system.
P.S. Side question is the current purpose of the "FontSmoothing"/"FontSmoothingType" registry keys as it seems to me that the fix to the bug #17148 made them obsolete.
http://bugs.winehq.org/show_bug.cgi?id=23097
da_fox@mad.scientist.com da_fox@mad.scientist.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #15 from da_fox@mad.scientist.com da_fox@mad.scientist.com 2010-06-22 06:14:21 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=23097
Sergiy Zuban s.zuban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |s.zuban@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #16 from Alexey Loukianov mooroon2@mail.ru 2010-06-23 00:33:44 --- I had spent some time recompiling wine-1.2-rc4 with and without fontconfig support. Here are the results:
1. If wine was compiled without fontconfig then the AA will be active if the Xft Xresources are set. If there are no Xft Xresources set then it would be the registry values who control the fonts AA.
2. If wine was compiled with fontconfig then the registry settings seem to be completely ignored. In case there are Xft Xresources defined then they would take precedence, in other cases fontconfig determines would be the fonts AA active or not. There's an odd behavior with it as if fontconfig returned that antialias=false and rgba=rgb then wine still would do ClearType-like font AA for this font. It is inconsistent behavior with the rest of the system as setting antialias=false would turn off any of subpixel AA methods as well. This might be treated as a reason to reopen bug #17148 but I don't this that the issue is major enough to care.
As for this bug I think that it would be reasonable to close it WONTFIX INCORRECT and to document the details of "registry settings"<=>"fontconfig"<=>"Xft Xresources"<=>"Wine" relations in docs/wiki.
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #17 from Sergiy Zuban s.zuban@gmail.com 2010-06-23 02:58:56 --- (In reply to comment #16)
In case there are Xft Xresources defined then they would take precedence, in other cases fontconfig determines would be the fonts AA active or not.
could someone explain why Xft Xresources takes precedence over fontconfig? IMHO it's not correct behavior, because in my case (Ubuntu 10.04) Xft Xresources always defined by GNOME and there is no way to reset Xft Xresources. As the result fontconfig settings ignored. In other apps/desktop fontconfig takes precedence, so it's possible to disable AA for small fonts (i use settings from https://wiki.ubuntu.com/Fonts), but it doesn't work for Wine apps. There is a bug 23006 related for this issue.
trace:xrender:GetCacheEntry fontconfig returned rgba 1 antialias 0 for font L"Terminal" file "/usr/share/fonts/truetype/msttcorefonts/Courier_New.ttf" trace:xrender:GetCacheEntry Xft resource returned rgba 'rgb' antialias 1
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #18 from Alexandre Julliard julliard@winehq.org 2010-06-23 03:32:45 --- Xft resources take precedence because in general you want the config to be specific to a display. If you log into a remote box and display an app on your desktop you want the app to use the same settings as the rest of the desktop, not the fontconfig settings of the remote box.
Note that fontconfig doesn't always take precedence for native apps either, it's more complicated than that, and it differs between apps and desktop environments. It's a big mess, there isn't one correct solution that Wine could simply follow.
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #19 from Alexey Loukianov mooroon2@mail.ru 2010-06-23 03:43:28 --- (In reply to comment #17)
could someone explain why Xft Xresources takes precedence over fontconfig? IMHO it's not correct behavior, because in my case (Ubuntu 10.04) Xft Xresources always defined by GNOME and there is no way to reset Xft Xresources.
You may read a long comment by me here: http://bugs.winehq.org/show_bug.cgi?id=23114#c4
As for reseting Xresources, try this in terminal (not as root but as currently logged in user): # xrdb -query | grep -vE 'Xft.(anti|hint|rgba)' | xrdb
It should clean up Xft-related Xresources from active instance of Xorg and make Wine use the fontconfig instead.
On my desktop it seems that the behavior for apps other than Wine is as following: 1. Qt3 apps (KDE3) ignore Xft and always use fontconfig. 2. GTK+ apps - here are two cases: 2a) gnome-settings-daemon is not runing: GTK+ apps will not use fonts AA if it is forbidden by Xft OR by fontconfig. 2b) gnome-settings-daemon is active: GTK+ apps will ignore fontconfig/Xft and use the settings from gconf (one that are set in gnome control center). 3. XUL apps (like Firefox) use cairo and here are three cases: 3a) cairo isn't specially patched with "cairo-respect-fontconfig.patch": it would behave just like ordinary GTK+ apps. 3b) cairo was patched with "cairo-respect-fontconfig.patch", no active gnome-settings-daemon: it would behave like Qt3 apps. 3c) cairo was patched with "cairo-respect-fontconfig.patch", there is active gnome-settings-daemon: it would behave like GTK+ apps.
That's it how it is working now on my desktop. As you can see Wine just declares it's own rules of behavior, nothing more.
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #20 from Sergiy Zuban s.zuban@gmail.com 2010-06-23 06:18:55 --- thank you for instructions how to reset Xresources - this helped me to get desired result.
(In reply to comment #16)
There's an odd behavior with it as if fontconfig returned that antialias=false and rgba=rgb then wine still would do ClearType-like font AA for this font. It is inconsistent behavior with the rest of the system as setting antialias=false would turn off any of subpixel AA methods as well. This might be treated as a reason to reopen bug #17148 but I don't this that the issue is major enough to care.
I also confirm this strange behavior. Definitely it's a bug. I had to remove this from /etc/fonts/local.conf:
<!-- Set sub-pixel order if not detected.
"X knows the sub pixel order already, and if this is enabled as well, Freetype produces some very strange results. However, if you do still have problems, consider (...) 'rgb' (the standard for LCD monitors), 'bgr' (unusual), 'vrgb' (vertical rgb, if you have a monitor that has been rotated by 90 degrees[1]), 'vgbr' (as vrgb, but very rare)." <http://www.linuxquestions.org/linux/answers/Hardware/%5C LCD_TFT_Monitor_Configuration_in_X_Org>
Find out your LCD's sub-pixel order: http://grc.com/image/cleartype2c.gif --> <match target="font"> <test qual="all" name="rgba" compare="eq"> <const>unknown</const> </test> <edit name="rgba" mode="assign"> <const>rgb</const> </edit> </match>
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #21 from da_fox@mad.scientist.com da_fox@mad.scientist.com 2010-06-29 06:46:50 --- still not fixed in 1.2_rc5
As for reseting Xresources, try this in terminal (not as root but as currently logged in user): # xrdb -query | grep -vE 'Xft.(anti|hint|rgba)' | xrdb
It should clean up Xft-related Xresources from active instance of Xorg and make Wine use the fontconfig instead.
I tried that, and wine still ignores my fontconfig settings.
I also confirm this strange behavior. Definitely it's a bug. I had to remove this from /etc/fonts/local.conf:
Even after removing similar lines from my local.conf I still don't get proper font rendering.
also setting the following Xft settings using xrdb (put it in a file and run 'xrdb <file>' does not help: --- Xft.lcdfilter: lcdlegacy Xft.antialias: 1 Xft.hinting: 1 Xft.rgba: rgb Xft.hintstyle: hintfull --- OR --- Xft.lcdfilter: none Xft.antialias: 0 Xft.hinting: 0 Xft.rgba: rgb Xft.hintstyle: hintnone --- Either way fonts are still rendered the same way, making them look somewhat similar to font-config's 'hintslight'
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #22 from Alexey Loukianov mooroon2@mail.ru 2010-06-29 16:08:20 --- (In reply to comment #21)
I tried that, and wine still ignores my fontconfig settings.
What do you mean by "ignores"?
Xft.lcdfilter: lcdlegacy Xft.antialias: 1 Xft.hinting: 1 Xft.rgba: rgb Xft.hintstyle: hintfull --- OR --- Xft.lcdfilter: none Xft.antialias: 0 Xft.hinting: 0 Xft.rgba: rgb Xft.hintstyle: hintnone
Either way fonts are still rendered the same way, making them look somewhat similar to font-config's 'hintslight'
It had been already reported here that Wine uses Xft.rgba or fontconfig's rgba setting as the primary trigger whether it should use "Cleartype"-style AA on fonts or not. Fonts rendering in Wine being done directly using FreeType lib, and it also seems to me that for now hinting is being hardcoded to some pre-defined value and can't be changed using either fontconfig or Xft Xresources. The only thing in question for this bug is controling AA for fonts using registry, so your report is offtopic and should go to the bug 23114.
http://bugs.winehq.org/show_bug.cgi?id=23097
Eugene Savelov savelov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |savelov@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=23097
--- Comment #23 from butraxz@gmail.com 2013-06-27 12:42:48 CDT --- This ticket has not been updated for over 900 days.
Is this still an issue in wine version 1.6-rc3 or higher or is this to be closed as abandoned ?
https://bugs.winehq.org/show_bug.cgi?id=23097
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |ABANDONED
--- Comment #24 from Austin English austinenglish@gmail.com --- (In reply to butraxz from comment #23)
This ticket has not been updated for over 900 days.
Is this still an issue in wine version 1.6-rc3 or higher or is this to be closed as abandoned ?
Abandoned.
https://bugs.winehq.org/show_bug.cgi?id=23097
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #25 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org