REGRESSION: xorg-server > 1.4 misrender borders

[pc@…]

For 2.4.0 the scrollbar in Xterms is missing it's outermost single pixel black line. This can be made to reappear in 'patches' when the window is resized. The problem occurs when a remote xterm is used - implying that it's something to do with the order that Xaw is rendering the scrollbar and the main V100 widget.

The problem is not hardware specific.

The problem disappears when 1.4.2-apple46 is installed. It's still present for 1.6.2-apple1.

[pc@…]

Screen grab of a 2.3.3 Xterm for reference

[pc@…]

Screen grab of a 2.4.0 Xterm

[pc@…]

Movie of resize behaviour

[pc@…]

I forgot: The GIF files show that there is no horizontal change in position of the scrollbar or Xterm content between the two, so I am guessing this is a one-off blanking error. and To provoke the scroll behaviour you need to drag the window diagonally downwards increasing the length and width of the window.

[pc@…]

and it should have said: The problem ALSO occurs when a remote xterm is used. It fails on local xterms.

[jeremyhu@…]

I'll try to figure it out for 2.4.0 because this trivial issue might signal a deeper problem... but if I can't figure it out easily, it'll probably be deferred for 2.4.1

[pc@…]

Well I will guess that it's a blanking issue. In regular use, the scrollbar is probably drawn first, then the main screen area - which overwrites the scrollbar edge. On the resize - I'll bet that the scrollbar pieces are redrawn after the main window - exposing it. You are probably looking for missing or extra = after a > or a < - and that's hard. But then you've probably figured that out anyway.

[jeremyhu@…]

It's a bit of a long shot, but could you try the 1.5.3-apple13 server? I changed fixed up some bugs in the visuals, so there is a small chance this might be fixed.

[pc@…]

Replying to jeremyhu@…:

It's a bit of a long shot, but could you try the 1.5.3-apple13 server? I changed fixed up some bugs in the visuals, so there is a small chance this might be fixed.

Sorry - bug still there.

[dcarter@…]

Just wanted to confirm the details of this bug. It is definitely server related as both remove and local xterms have the same behavior. I did not see this problem until going from 2.3.3.2 to 2.4.0. Now that I've gone back to 2.3.3.2, the bug has gone away.

[jeremyhu@…]

@dcarter You're better off using 2.4.0 and installing the 1.4.2-apple47 server than using 2.3.3.2.

Install 2.4.0 then do the following:

curl -LO http://static.macosforge.org/xquartz/downloads/X11.bin-1.4.2-apple47.bz2
bunzip2 X11.bin-1.4.2-apple47.bz2
sudo cp X11.bin-1.4.2-apple47 /Applications/Utilities/X11.app/Contents/MacOS/X11.bin
sudo chmod 755 /Applications/Utilities/X11.app/Contents/MacOS/X11.bin

[otte@…]

Simple program demonstrating borders not being drawn

[otte@…]

I added a simple example (border.c) showing that in a call to XCreateSimpleWindow, the subwindow borders are not drawn when using the 1.5.3-apple servers.

[jeremyhu@…]

I seem to recall that the fix I made for this is incomplete. Can you please update the test case to show how it is still problematic with the latest servers (like 1.7.2?)

[pc@…]

Replying to jeremyhu@…: My SL is vanilla release X11 - I tried installing X11.bin-1.7.0.901 onto my 2.4.0 Leopard but it says:

Library not loaded: /usr/X11/lib/libX11.5.dylib
Referenced from /Applications/Utilities/..... X11.bin
Reason: Incompatible library version: X11.bin requires version 10.0.0 or later, but libX11.6.dylib provides version 9.0.0

(And which 'sensible' person decided that I would never wish to cut from dialog boxes)

[pc@…]

Well this is still an active problem for 2.5.0 although it seems to have altered.

When I open an xterm the single pixel line that marks the edge of the scroll bar stops about 1.5 lines up from the bottom. The line doesn't expand if you expand the xterm, it stays in its original position. Previously - the emacs inverted status bar would overwrite into this area so as you scrolled the line became moth-eaten. I've seen a little of the moth eating the line behaviour today, but it's not as bad as it was.

I think that previously the line was scrolling in some circumstances. This doesn't seem to happen now. I think that this is happening with the 10.6.3 release.

I played with the menu turning scroll bars on and off - and it made no difference.

However, the xterm menus have an 'interesting' border around them. The menu border is supposed to be black - but is white on all but one menu which has black in the top left hand quadrant.

I'll upload two graphics which show what I am seeing.

Otto - if you are still there... some idea of how to compile border.c for people who don't know would have helped. Always a problem with C - don't know how to compile things.

[pc@…]

What happens at the bottom of a 'standard' xterm.

[pc@…]

xterm action menus showing borders being incorrectly rendered.

[pc@…]

Using Snow Leopard X11.app, I have stepped back from the 10.6.3 release of xorg-server 1.4.2-apple53. Xterm is OK when running xorg-server 1.4.2-apple48 and is broken when running xorg-server 1.4.2-apple49.

Behaviour: initial xterm window doesn't display menu line growing the window down draws the line in the new space new line is 'fragmented'

[jeremyhu@…]

the only changes between 1.4.2-apple48 and 1.4.2-apple49 are related to the keymap and other trivial changes:

​http://cgit.freedesktop.org/~jeremyhu/xserver/log/?h=9af39f090ab4a6bde225d3dd7a954ba866751b5b

[jeremyhu@…]

Actually, an odd change crept in here:

​http://cgit.freedesktop.org/~jeremyhu/xserver/commit/?h=9af39f090ab4a6bde225d3dd7a954ba866751b5b&id=e39bd3ddd13c1122e94139f4a5d778a081db44cb

in miext/rootless/rootlessWindow.c ... that change is obviously not right and the commit shows it was supposed to be just clang fixes...

[jeremyhu@…]

(I'll get a build for you to try tomorrow)

[pc@…]

OK

[jeremyhu@…]

Actually, it finished fast enough... please try this with your X11.app (not XQuartz.app)

​http://static.macosforge.org/xquartz/downloads/testing/X11.bin-PR-290.bz2

It is the latest server-1.4-apple branch with that '0 &&' removed.

[pc@…]

Fixed..

[pc@…]

and the border around the xterm menus are 'correct' too.

[jeremyhu@…]

Im starting to think that ​https://bugs.freedesktop.org/show_bug.cgi?id=26124 might be related...

[jeremyhu@…]

So... my original thoughts were that this was related to the "#ifdef ROOTLESS" hunks in miPaintWindow not matching what was previously done in rootlessWindow.c, but that doesn't seem to be the case... I thought it was a problem with the RootlessSetPixmapOfAncestors(), but that doesn't even get triggered on 1.4.

I spent some time rebasing our current DDX against old master where this goes bad. I created a branch here that is at the bug point:

​http://cgit.freedesktop.org/~jeremyhu/xserver/log/?h=PR-290

There are three patches of interest:

1) aad51e26de4d4573cc55e350042c590ad04fbecb rebases our current DDX at the commit before the bug is introduced
2) 6c28ac35c46c021715e22dbdd3ca85df6ed0a8f6 introduces this bug as a cherry-commit of the commit that proceeds the commit after our branch point
3) 9e1ae9a5ef4d20d9f116d2ad35d878a4d3c26a8b integrates some fixes to regressions from this commit that were already fixed

So I just need to disect 6c28ac35c46c021715e22dbdd3ca85df6ed0a8f6 to figure out what is going on.

[jeremyhu@…]

I just pushed one more patch which is a minimal "fix" for this issue by bringing back fbPaintWindow() ... so there is something "off" where miPaintWindow and fbPaintWindow don't end up with the same result...

[jeremyhu@…]

a reduced workaround for master:

​http://cgit.freedesktop.org/~jeremyhu/xserver/commit/?h=PR-290-1.9

I emailed xorg-devel... hopefully someone else can shed some light here...

​http://lists.x.org/archives/xorg-devel/2010-April/007518.html

[jeremyhu@…]

Ok, can someone please give this build a try: ​http://static.macosforge.org/xquartz/downloads/testing/X11.bin-PR-290-1.9.bz2

You'll need to install 2.5.1_beta1 first.

I think that should work around the problem as it's showing up here... the real problem is deeper, but I want to atleast get something into 2.5.1 that works from the user's perspective.

[pc@…]

Tried to do this - installed 2.5.1_beta1 and replaced X11.bin.. won't fly because

Dyld Error Message:

Library not loaded: /opt/X11/lib/libpixman-1.0.dylib Referenced from: /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin Reason: Incompatible library version: X11.bin requires version 20.0.0 or later, but libpixman-1.0.dylib provides version 19.0.0

tried a reboot of machine just in case. But still no go. Have I managed to not install things correctly?

[jeremyhu@…]

meh. it looks like you'll have to wait for beta2. I thought pixman made it into beta1... oh well, sorry for getting your hopes up. beta2 should be out in the next week or so depending on how much of my time I can devote to X11 versus my other responsibilities.

[jeremyhu@…]

Please test 2.5.1_beta2

[pc@…]

Installed, ran and fixed the Xterm problem. Also fixes the border around the Xterm menu problem that was seen on earlier releases.