bug#8426: Glyph and cursor problem with emacs

bug#8426: Glyph and cursor problem with emacs

[Matthew Carey]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

GNU Emacs 23.2.1 (x86_64-suse-linux-gnu, GTK+ Version 2.22.1)
 of 2011-02-22 on build34

SuSE Linux 11.4
KDE 4

Now I think this is a side effect of me installing too many fonts on this box
but I cannot see how to get out of it.

The selection of characters by the cursor is no longer rectangular but seeks to
match the glyph forms. When I edit I get ghosts of previous characters sitting
on the screen until I do a page up page down to refresh the screen.

The latter is what makes emacs impossible to use as I cannot distinguish between
the ghost characters and the real ones and the cursor location is not obvious.

My other box with the same OS and architecture does not exhibit the problem.

I attach an image to make the point clear.

1 No matter how many fonts I install emacs should be able to cope.
2 No other applications seem to be affected this way on the box.

I have tried removing clearing my .emacs file and changing .fonts.config.

If I use the same emacs installation forwarding X output to another machine it
works fine.

[-- Attachment #2: emacs_prob.jpg --]
[-- Type: image/jpeg, Size: 42437 bytes --]

bug#8426: Glyph and cursor problem with emacs

[Eli Zaretskii]

> Date: Tue, 05 Apr 2011 11:06:30 +0100
> From: Matthew Carey <matthew@ssl.co.uk>
> Cc: 
> 
> I attach an image to make the point clear.

Is that image after selecting the whole buffer, or is yellow the
default background on that frame?

Also, what font is being used here?  You can see that by going to some
of the characters and typing "C-u C-x =": Emacs will pop up a buffer
which shows, among other things, what font is being used to display
that character.

> 1 No matter how many fonts I install emacs should be able to cope.

Not if you install broken fonts, which, e.g., lie to Emacs about the
character dimensions.  (I'm not saying this is what happened, but just
don't expect Emacs to "cope" with bad fonts.)

bug#8426: Glyph and cursor problem with emacs

[Matthew Carey]

Thanks for coming back to me so promptly

The yellow is the selection and it should not hug the glyphs, but that is a less
horrible symptom than the ghost characters.

This is the output of C-u C-x =

        character: i (105, #o151, #x69)
preferred charset: ascii (ASCII (ISO646 IRV))
       code point: 0x69
           syntax: w 	which means: word
         category: .:Base, a:ASCII, l:Latin, r:Roman
      buffer code: #x69
        file code: #x69 (encoded by coding system undecided-unix)
          display: by this font (glyph code)
    xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1
(#x4C)

Character code properties: customize what to show
  name: LATIN SMALL LETTER I
  general-category: Ll (Letter, Lowercase)

There are text properties here:
  fontified            t


And no I would not expect Emacs to cope with broken fonts, unfortunately which
ever font a change to I get the same problem.

On 05/04/11 17:57, Eli Zaretskii wrote:
>> Date: Tue, 05 Apr 2011 11:06:30 +0100
>> From: Matthew Carey <matthew@ssl.co.uk>
>> Cc: 
>>
>> I attach an image to make the point clear.
> 
> Is that image after selecting the whole buffer, or is yellow the
> default background on that frame?
> 
> Also, what font is being used here?  You can see that by going to some
> of the characters and typing "C-u C-x =": Emacs will pop up a buffer
> which shows, among other things, what font is being used to display
> that character.
> 
>> 1 No matter how many fonts I install emacs should be able to cope.
> 
> Not if you install broken fonts, which, e.g., lie to Emacs about the
> character dimensions.  (I'm not saying this is what happened, but just
> don't expect Emacs to "cope" with bad fonts.)

bug#8426: Glyph and cursor problem with emacs

[Eli Zaretskii]

> Date: Tue, 05 Apr 2011 18:08:50 +0100
> From: Matthew Carey <matthew@ssl.co.uk>
> CC: 8426@debbugs.gnu.org
> 
> This is the output of C-u C-x =
> 
>         character: i (105, #o151, #x69)
> preferred charset: ascii (ASCII (ISO646 IRV))
>        code point: 0x69
>            syntax: w 	which means: word
>          category: .:Base, a:ASCII, l:Latin, r:Roman
>       buffer code: #x69
>         file code: #x69 (encoded by coding system undecided-unix)
>           display: by this font (glyph code)
>     xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1
> (#x4C)

Since you say that the same Emacs works fine when display is forwarded
to another machine, I suspect some problem on the X server level.  I
hope some expert on X (I'm not) will chime in, and find the above
information useful.

bug#8426: Glyph and cursor problem with emacs

[David De La Harpe Golden]

On 05/04/11 11:06, Matthew Carey wrote:

> My other box with the same OS and architecture does not exhibit the problem.

The exact same architecture?  Particularly, same gfx card and same 
version of said driver for said card, with same xorg.conf config 
options?  It's just the perennially annoying closed x11 drivers for 
ati/amd and nvidia hardware often have bizarre 2D drawing glitches, and 
they can be dependent on the precise version, configuration options 
(like which AccelMethod is in use) and whether compositing is enabled 
[1][2] (in contrast, the open drivers are typically slow for 3D but 
really good for 2D)

> 2 No other applications seem to be affected this way on the box.

That _could_ be just luck / the subset of apps used by the driver 
authors for testing coinciding with yours.  Emacs handles its own 
drawing to the main window with direct xlib calls, and may do things 
legally but still differently to some other apps.

> If I use the same emacs installation forwarding X output to another machine it
> works fine.

Well, as Eli points out, that does strongly suggest it's an X server 
level problem, not an emacs problem.  If it were, say, some call to 
XFillRectangle being misplaced in the emacs binary you'd expect it to 
occur on all X servers you tried.

The chances of DejaVu Sans Mono metrics being messed up seem slim, and 
also xft/xrender based font rendering, unlike the old core x11 
server-side font rendering, uses client-side tesselation to trapezoids 
and you say the same emacs works on another x11 server, so that's not 
the problem. While it's been actively developed (descended from 
Bitstream Vera) and therefore there are different versions of it 
floating about, it's an extremely widely used font, and the one I use 
with emacs with no such problems.

[1] http://ati.cchtml.com/
[2] 
https://wiki.archlinux.org/index.php/ATI_Catalyst#Catalyst_10.6.2F10.7.2F10.8.2F10.9_:_black.2Fgrey.2Fwhite_boxes.2Fartifacts_in_firefox.2Fthunderbird

bug#8426: Glyph and cursor problem with emacs

[Matthew Carey]

I have switched off compositing and the problem appears to go away.

The machine is not identical to the one that does not have the problem in that
though both are 64bit the problem box is a Thinkpad T61 (7959-CT0) which has:

Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller

So the question is: Is this a bug in the graphics driver or SuSE's packaging of
the driver compositing software.

On 05/04/11 18:20, Eli Zaretskii wrote:
>> Date: Tue, 05 Apr 2011 18:08:50 +0100
>> From: Matthew Carey <matthew@ssl.co.uk>
>> CC: 8426@debbugs.gnu.org
>>
>> This is the output of C-u C-x =
>>
>>         character: i (105, #o151, #x69)
>> preferred charset: ascii (ASCII (ISO646 IRV))
>>        code point: 0x69
>>            syntax: w 	which means: word
>>          category: .:Base, a:ASCII, l:Latin, r:Roman
>>       buffer code: #x69
>>         file code: #x69 (encoded by coding system undecided-unix)
>>           display: by this font (glyph code)
>>     xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1
>> (#x4C)
> 
> Since you say that the same Emacs works fine when display is forwarded
> to another machine, I suspect some problem on the X server level.  I
> hope some expert on X (I'm not) will chime in, and find the above
> information useful.

bug#8426: Glyph and cursor problem with emacs

[David De La Harpe Golden]

On 06/04/11 11:16, Matthew Carey wrote:
> I have switched off compositing and the problem appears to go away.
>
> The machine is not identical to the one that does not have the problem in that
> though both are 64bit the problem box is a Thinkpad T61 (7959-CT0) which has:
>
> Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller
>
> So the question is: Is this a bug in the graphics driver or SuSE's packaging of
> the driver compositing software.
>

Well, a compositing manager is not card-specific... (can end up running 
some proportion of different code on different cards, though e.g. 
depending on shader capability level).   Looking through the intel 
driver bugzilla [1], there are various "odd display artifact" type bugs. 
If you wouldn't mind reporting the bug to them [2], they might be able 
to diagnose.

[1] 
https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Driver%2Fintel&product=xorg

[2] http://intellinuxgraphics.org/how_to_report_bug.html

bug#8426: Glyph and cursor problem with emacs

[Stefan Kangas]

David De La Harpe Golden <david@harpegolden.net> writes:

> On 06/04/11 11:16, Matthew Carey wrote:
>> I have switched off compositing and the problem appears to go away.
>>
>> The machine is not identical to the one that does not have the problem in that
>> though both are 64bit the problem box is a Thinkpad T61 (7959-CT0) which has:
>>
>> Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller
>>
>> So the question is: Is this a bug in the graphics driver or SuSE's packaging of
>> the driver compositing software.
>>
>
> Well, a compositing manager is not card-specific... (can end up running some
> proportion of different code on different cards, though e.g. depending on shader
> capability level).   Looking through the intel driver bugzilla [1], there are
> various "odd display artifact" type bugs. If you wouldn't mind reporting the bug
> to them [2], they might be able to diagnose.
>
> [1]
> https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Driver%2Fintel&product=xorg
>
> [2] http://intellinuxgraphics.org/how_to_report_bug.html

From the above, I'm concluding that this is not a bug in Emacs, and I'm
therefore closing this 8 year old bug.

If this is the wrong conclusion, and this is still an issue, please
reopen the bug report.

Best regards,
Stefan Kangas