Skip to content
Permalink
master
Go to file
 
 
Cannot retrieve contributors at this time
454 lines (209 sloc) 16.1 KB
original_url created_at updated_at closed_at status type resolution reporter owner priority milestone component version keywords
2009-07-28 23:26:34 -0700
2015-10-14 01:14:03 -0700
2010-04-23 18:14:56 -0700
closed
usability
Fixed
pc@…
jeremyhu@…
Important
2.5.1
xserver
2.4.0 (xserver-1.5.3-apple14)
regression

REGRESSION: xorg-server > 1.4 misrender borders

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@… commented on Jul 28, 2009

Screen grab of a 2.3.3 Xterm for reference


pc@… commented on Jul 28, 2009

Screen grab of a 2.4.0 Xterm


pc@… commented on Jul 28, 2009

  • Attachment x11.mov (3.8 MB) added

Movie of resize behaviour


pc@… commented on Jul 28, 2009

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@… commented on Jul 28, 2009

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


jeremyhu@… commented on Jul 29, 2009

  • Status changed from new to assigned
  • Milestone set to 2.4.0

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@… commented on Jul 29, 2009

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@… commented on Jul 31, 2009

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@… commented on Jul 31, 2009

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.


jeremyhu@… commented on Aug 3, 2009

  • Milestone changed from 2.4.0 to 2.4.1

dcarter@… commented on Aug 19, 2009

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@… commented on Aug 19, 2009

@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@… commented on Sep 24, 2009

Simple program demonstrating borders not being drawn


otte@… commented on Sep 24, 2009

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@… commented on Nov 27, 2009

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@… commented on Nov 27, 2009

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)


jeremyhu@… commented on Feb 26, 2010

  • Milestone changed from 2.5.0 to 2.5.1

pc@… commented on Mar 30, 2010

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@… commented on Mar 30, 2010

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


pc@… commented on Mar 30, 2010

xterm action menus showing borders being incorrectly rendered.


pc@… commented on Mar 30, 2010

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@… commented on Mar 30, 2010

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@… commented on Mar 30, 2010

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@… commented on Mar 30, 2010

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


pc@… commented on Mar 30, 2010

OK


jeremyhu@… commented on Mar 30, 2010

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@… commented on Mar 31, 2010

Fixed..


pc@… commented on Mar 31, 2010

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


jeremyhu@… commented on Apr 2, 2010

  • Summary changed from Xterm scrollbar margin line missing to REGRESSION: xorg-server > 1.4 misrender borders
  • Version changed from dev (master) to 2.4.0 (xserver-1.5)
  • Keywords regression added
  • Priority changed from minor to major

jeremyhu@… commented on Apr 16, 2010

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


jeremyhu@… commented on Apr 17, 2010

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@… commented on Apr 18, 2010

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@… commented on Apr 18, 2010

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@… commented on Apr 19, 2010

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@… commented on Apr 19, 2010

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@… commented on Apr 19, 2010

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@… commented on Apr 22, 2010

Please test 2.5.1_beta2


pc@… commented on Apr 22, 2010

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


jeremyhu@… commented on Apr 23, 2010

  • Status changed from assigned to closed
  • Resolution changed from to fixed

jeremyhu@… commented on Oct 14, 2015

I suspect this was fixed by http://cgit.freedesktop.org/xorg/xserver/commit/?id=b4061cf5f76241157b2dc81dec053012075311c0, so I'm removing the previous workaround. Please test XQuartz 2.7.9_rc1 when it is released.

You can’t perform that action at this time.