xorg-server-devel @1.17.99.902_0 shows on Snow Leopard, Mac OS X 10.6.8, artefacts in X window decoration

[ballapete (Peter "Pete" Dyballa)]

I am not sure whether the reported artefacts in earlier versions of X.Org server have been fixed – this version shows them (again), see the attached screen-shot!

[ballapete (Peter "Pete" Dyballa)]

Artefacts in vertical and horizontal X window decoration

[jeremyhu (Jeremy Huddleston Sequoia)]

Dupe of #49465. As reported there, it was fixed in r 143917.

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

Dupe of #49465. As reported there, it was fixed in r143917.

So why can't I see the fix? Is my graphics card still defective (Apple exchanged it almost two years ago, and a year later transferred the money back)?

[jeremyhu (Jeremy Huddleston Sequoia)]

You don't see the fix because you are running a version without the fix. Update.

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

You don't see the fix because you are running a version without the fix. Update.

Which package is the fixed one?

xorg-server                    @1.17.4         x11/xorg-server
xorg-server-devel              @1.18.0         x11/xorg-server-devel

[jeremyhu (Jeremy Huddleston Sequoia)]

Both of those have the fix. The version you are using is xorg-server-devel 1.17.99.902_0 , which doesn't have the fix.

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

Both of those have the fix. The version you are using is xorg-server-devel 1.17.99.902_0 , which doesn't have the fix.

No, right now I am using XQuartz 2.7.7 (xorg-server 1.18.0). And it has the artefacts I shot yesterday.

pete 53 /\ port installed | grep xorg-server | grep active
  xorg-server-devel @1.18.0_0 (active)

[jeremyhu (Jeremy Huddleston Sequoia)]

The report states that the issue is with xorg-server-devel @1.17.99.902_0. That most recent comment is the first indication that you are seeing issues with 1.18.0. 1.18.0 has the changes that you provided in #49465.

Does 1.17.4_1 work ok for you?

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

The report states that the issue is with xorg-server-devel @1.17.99.902_0. That most recent comment is the first indication that you are seeing issues with 1.18.0. 1.18.0 has the changes that you provided in #49465.

Maybe I was too fast here. What I still see are artefacts with Macports' GNU Emacs 24.5, see the attached screenshot. I'll have to launch xorg-server-devel @1.18.0_0 later (in the evening, presumingly?), to check exactly. The "artefacts again" screenshot is indeed from xorg-server-devel @1.17.99.902_0.

Does 1.17.4_1 work ok for you?

Quite good, except the mentioned artefact. After 1545 pixels the topmost black frame in the decoration ends and becomes white. This effect is also visible with xorg-server-devel @1.18.0_0.

[ballapete (Peter "Pete" Dyballa)]

Artefact in window decoration of Macports' GNU Emacs 24.5

[jeremyhu (Jeremy Huddleston Sequoia)]

Quite good, except the mentioned artefact

So then what did your patch fix? As I understand it, 1.7.4_1 includes your patch to fix the issue you reported in #49465, yet you say you are still seeing the issue.

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

So then what did your patch fix? As I understand it, 1.7.4_1 includes your patch to fix the issue you reported in #49465, yet you say you are still seeing the issue.

This little artefact is left. It's only left for Macports' GNU Emacs 24.5. And it only appears when this Emacs instance is fully initialised. What I mean is that the scheme of displaying the X clients on :0, then on :1, then on :2, and so on, creates errors in GNU Emacs version greater 23.x which stop full initialisation, which is changing the windows size from some default to particular dimensions. When I make the not fully initialised window as wide as I want it, the artefact does not appear. This is true for both fixed versions, i.e.:

xorg-server                    @1.17.4         x11/xorg-server
xorg-server-devel              @1.18.0         x11/xorg-server-devel

[jeremyhu (Jeremy Huddleston Sequoia)]

The "which display does the server use" issue is not related to this issue. Please don't conflate problems. With respect to rendering artifacts, what did your patch in #49465 fix? My understanding was that it fixed the exact issue you are reporting in this bug.

[ballapete (Peter "Pete" Dyballa)]

Artefacts in title and footer

[ballapete (Peter "Pete" Dyballa)]

Artefacts in title and footer after resizing

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

The "which display does the server use" issue is not related to this issue. Please don't conflate problems.

Well, it confused GNU Emacs, because it tries to record which windows ("frames") were open on which display and tries to re-open them on next launch.

With respect to rendering artifacts, what did your patch in #49465 fix? My understanding was that it fixed the exact issue you are reporting in this bug.

This was my idea too! But with Macports' GNU Emacs 24.5 (x86_64-apple-darwin10.8.0, GTK+ Version 2.24.28) artefacts in title and footer still exist, see image titled Artefacts in title and footer (the file's name is not correct, I erroneously re-used the wrong version number from another screenshot). After resizing or minimizing and re-opening GNU Emacs the number of artefacts is reduced, as the image titled Artefacts in title and footer after resizing demonstrates. This happens with these active packages:

  quartz-wm @1.3.2_0 (active)
  xinit @1.3.4_2 (active)
  xorg-server-devel @1.18.0_0 (active)

and also this set:

  quartz-wm @1.3.2_0 (active)
  xinit @1.3.4_2 (active)
  xorg-server @1.17.4_1 (active)

Sorry, I did not check exactly! Most artefacts were removed, obviously, so probably I did not check with Macports' GNU Emacs 24.5 because the other X clients showed so many failures before and after patching they did not. Probably I would have recognised and reported these last left artefacts if it would not have happened that so many bugs had reappeared suddenly.

[ballapete (Peter "Pete" Dyballa)]

I can reproduce this effect with a few local Emacsen of different versions using my account, provided that some part of Emacs is off-screen, is more right than the right border of the screen. It also works with Emacsen I launch from an SSH session running on my PowerBook G4 with Tiger, Mac OS X 10.4.11.

Trying the same with Macports' GNU Emacs 24.5 I can see that the frame (X window) is first drawn partially off-screen, but then the whole window jumps left to become completely visible. Outside the screen the decoration was obviously drawn a bit too much optimised…

[jeremyhu (Jeremy Huddleston Sequoia)]

Well, given that the change you provided in #49465 is about drawing borders, and you're having issues with the window border, I suspect the workaround is incomplete. I suggest you revisit those changes.

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

Well, given that the change you provided in #49465 is about drawing borders, and you're having issues with the window border, I suspect the workaround is incomplete. I suggest you revisit those changes.

I can't. I don't understand what the patches (and the surrounding code) are doing. Somebody else wrote them, I just determined anew the line numbers where they belong to.

[ballapete (Peter "Pete" Dyballa)]

On PPC Tiger, Mac OS X 10.4.11, I cannot reproduce the effect with its own XQuartz 2.7.7 (xorg-server 1.17.4), on PPC Leopard, Mac OS X 10.5.8, I can with the same X.Org server.

[ballapete (Peter "Pete" Dyballa)]

I am still seeing this on Mac OS X 10.6.8 with XQuartz 1.18.99.1 (xorg-server 1.18.99.1) – when will this defect be corrected?

[ballapete (Peter "Pete" Dyballa)]

XQuartz 1.18.99.1 (xorg-server 1.18.99.1) and GNU Emacs 25.0.95.2 (x86_64-apple-darwin10.8.0, X toolkit, cairo version 1.14.6, Xaw3d scroll bars) of 2016-06-14

[ballapete (Peter "Pete" Dyballa)]

I also see it with XQuartz 1.18.3 (xorg.server 1.18.3) on PPC Mac OS X 10.5.8, Leopard.

[jeremyhu (Jeremy Huddleston Sequoia)]

Please open a new ticket with fresh details.