Line drawing in 1.5 and 1.6 servers
I think a similar problem has been mentioned before, but in the 1.5 server sometimes lines are not drawn correctly. Here is an example from an application that uses its own custom toolkit, where the lines around each button are not drawn. Attached is a screen shot of how the buttons display correctly in server 1.4, and another screen shot of how the buttons appear incorrectly in server 1.5 without the borders. I need to investigate whether the black outlines are being drawn as white, or if just a white shadow from underneath is being displayed over the black outlines. I also tried one of the 1.6 servers from the download site, and it shows the same behavior as the 1.5 server. Is there anything I can do to help locate where in the server this could be happening? Thanks, Martin
Hi Martin, My hunch is that the white is actually "nothing" rather than "white" ... the default color if we were to put nothing there is white... so I think some blt just isn't happening and somewhere in the pipe, the ball is getting dropped, but I have no idea "where" in the pipe that is and haven't done much research into it just yet. I've been more concerned with (1) fixing issues in the 1.4 server, (2) getting X11 building into another prefix for SnowLeopard, and (3) figuring out some bugs with the build system that are causing me headaches under SnowLeopard (hence the 2.4.1-alpha1 delay). On Sep 15, 2009, at 09:34, Martin Otte wrote:
I think a similar problem has been mentioned before, but in the 1.5 server sometimes lines are not drawn correctly. Here is an example from an application that uses its own custom toolkit, where the lines around each button are not drawn.
Attached is a screen shot of how the buttons display correctly in server 1.4,
<server_14.png>
and another screen shot of how the buttons appear incorrectly in server 1.5 without the borders.
<server_15.png>
I need to investigate whether the black outlines are being drawn as white, or if just a white shadow from underneath is being displayed over the black outlines. I also tried one of the 1.6 servers from the download site, and it shows the same behavior as the 1.5 server.
Is there anything I can do to help locate where in the server this could be happening?
Thanks, Martin
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Hi, The problem with the lines not drawn correctly occurs when calling XCreateSimpleWindow. The program I have uses XCreateSimpleWindow to create the buttons and their borders. When I increase the size of the border in XCreateSimpleWindow and turn off all other decorations, this is what I see: It is interesting to see part of the quartz-wm frame imposed on the button borders. My guess is that the border pixmap is not being created/shown correctly in the server. Looking through dix/window.c and mi/miexpose.c a lot has changed between the 1.4 and 1.5 versions of the server, so I don't think I'll be much help in tracking down the problem. Martin On Sep 15, 2009, at 3:07 PM, Jeremy Huddleston wrote:
Hi Martin,
My hunch is that the white is actually "nothing" rather than "white" ... the default color if we were to put nothing there is white... so I think some blt just isn't happening and somewhere in the pipe, the ball is getting dropped, but I have no idea "where" in the pipe that is and haven't done much research into it just yet. I've been more concerned with (1) fixing issues in the 1.4 server, (2) getting X11 building into another prefix for SnowLeopard, and (3) figuring out some bugs with the build system that are causing me headaches under SnowLeopard (hence the 2.4.1-alpha1 delay).
On Sep 15, 2009, at 09:34, Martin Otte wrote:
I think a similar problem has been mentioned before, but in the 1.5 server sometimes lines are not drawn correctly. Here is an example from an application that uses its own custom toolkit, where the lines around each button are not drawn.
Attached is a screen shot of how the buttons display correctly in server 1.4,
<server_14.png>
and another screen shot of how the buttons appear incorrectly in server 1.5 without the borders.
<server_15.png>
I need to investigate whether the black outlines are being drawn as white, or if just a white shadow from underneath is being displayed over the black outlines. I also tried one of the 1.6 servers from the download site, and it shows the same behavior as the 1.5 server.
Is there anything I can do to help locate where in the server this could be happening?
Thanks, Martin
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Sep 17, 2009, at 11:48, Martin Otte wrote:
Hi,
The problem with the lines not drawn correctly occurs when calling XCreateSimpleWindow. The program I have uses XCreateSimpleWindow to create the buttons and their borders. When I increase the size of the border in XCreateSimpleWindow and turn off all other decorations, this is what I see:
<border.png>
It is interesting to see part of the quartz-wm frame imposed on the button borders. My guess is that the border pixmap is not being created/shown correctly in the server. Looking through dix/window.c and mi/miexpose.c a lot has changed between the 1.4 and 1.5 versions of the server, so I don't think I'll be much help in tracking down the problem.
My guess is that the changes have just resulted in nothing actually being drawn. What you're seeing in the background there is actually just the uninitialized garbage that happened to be at the memory location allocated for that backing store which was previously used to draw a quartz-wm widget. Can you provide me with your simplified test case. That'll be easier than dragging the xterm window resize around every time I want to debug this. Thanks, Jeremy
Hi, The example is simple, but it is part of a bigger program. I'll try to hack away to get the bare minimal example that causes the problem with the borders. Thanks, Martin On Sep 18, 2009, at 12:49 AM, Jeremy Huddleston wrote:
On Sep 17, 2009, at 11:48, Martin Otte wrote:
Hi,
The problem with the lines not drawn correctly occurs when calling XCreateSimpleWindow. The program I have uses XCreateSimpleWindow to create the buttons and their borders. When I increase the size of the border in XCreateSimpleWindow and turn off all other decorations, this is what I see:
<border.png>
It is interesting to see part of the quartz-wm frame imposed on the button borders. My guess is that the border pixmap is not being created/shown correctly in the server. Looking through dix/window.c and mi/miexpose.c a lot has changed between the 1.4 and 1.5 versions of the server, so I don't think I'll be much help in tracking down the problem.
My guess is that the changes have just resulted in nothing actually being drawn. What you're seeing in the background there is actually just the uninitialized garbage that happened to be at the memory location allocated for that backing store which was previously used to draw a quartz-wm widget.
Can you provide me with your simplified test case. That'll be easier than dragging the xterm window resize around every time I want to debug this.
Thanks, Jeremy
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Hi, Attached is a simplified test case showing that in a call to XCreateSimpleWindow, the border around the subwindow is not displayed. With the 1.4 server, the program displays: but with the 1.5 server, the border of the inner window is not shown: I also added this example code to bug report #290. Hope this helps, Martin On Sep 18, 2009, at 12:49 AM, Jeremy Huddleston wrote:
On Sep 17, 2009, at 11:48, Martin Otte wrote:
Hi,
The problem with the lines not drawn correctly occurs when calling XCreateSimpleWindow. The program I have uses XCreateSimpleWindow to create the buttons and their borders. When I increase the size of the border in XCreateSimpleWindow and turn off all other decorations, this is what I see:
<border.png>
It is interesting to see part of the quartz-wm frame imposed on the button borders. My guess is that the border pixmap is not being created/shown correctly in the server. Looking through dix/window.c and mi/miexpose.c a lot has changed between the 1.4 and 1.5 versions of the server, so I don't think I'll be much help in tracking down the problem.
My guess is that the changes have just resulted in nothing actually being drawn. What you're seeing in the background there is actually just the uninitialized garbage that happened to be at the memory location allocated for that backing store which was previously used to draw a quartz-wm widget.
Can you provide me with your simplified test case. That'll be easier than dragging the xterm window resize around every time I want to debug this.
Thanks, Jeremy
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Thanks Martin, This will help tremendously. I'm going to look at it this weekend, and if I can't figure it out, I'll ask the brain trust at XDC next week. Thanks, Jeremy On Sep 24, 2009, at 13:38, Martin Otte wrote:
Hi,
Attached is a simplified test case showing that in a call to XCreateSimpleWindow, the border around the subwindow is not displayed. With the 1.4 server, the program displays:
<server_1.4.png>
but with the 1.5 server, the border of the inner window is not shown:
<server_1.5.png>
I also added this example code to bug report #290.
Hope this helps, Martin
<border.c>
On Sep 18, 2009, at 12:49 AM, Jeremy Huddleston wrote:
On Sep 17, 2009, at 11:48, Martin Otte wrote:
Hi,
The problem with the lines not drawn correctly occurs when calling XCreateSimpleWindow. The program I have uses XCreateSimpleWindow to create the buttons and their borders. When I increase the size of the border in XCreateSimpleWindow and turn off all other decorations, this is what I see:
<border.png>
It is interesting to see part of the quartz-wm frame imposed on the button borders. My guess is that the border pixmap is not being created/shown correctly in the server. Looking through dix/ window.c and mi/miexpose.c a lot has changed between the 1.4 and 1.5 versions of the server, so I don't think I'll be much help in tracking down the problem.
My guess is that the changes have just resulted in nothing actually being drawn. What you're seeing in the background there is actually just the uninitialized garbage that happened to be at the memory location allocated for that backing store which was previously used to draw a quartz-wm widget.
Can you provide me with your simplified test case. That'll be easier than dragging the xterm window resize around every time I want to debug this.
Thanks, Jeremy
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Ok, I think I found the cause and a hackish workaround for this issue... The problem stems from the fact that the core/common X server code no longer has hooks for paintWindowBorder and paintWindowBackground. We were using those hooks for correcting alpha values as well as handling cases like this. After the core X developers nuked those callbacks a while back, I went through and fixed hacked the alpha values back into place, but I missed this particular problem. I have a bit of a hack to get functionality back in place, but it's not elegant. I'm going to try finding a better solution for all of this. I essentially resurrected some code that had been punted and found a place to put it into the pipe, but my guess is that there's a better location for it. --Jeremy ---- diff --git a/mi/miexpose.c b/mi/miexpose.c index 961c35c..d540a9f 100644 --- a/mi/miexpose.c +++ b/mi/miexpose.c @@ -531,6 +531,14 @@ miWindowExposures(pWin, prgn, other_exposed) REGION_DESTROY( pWin->drawable.pScreen, exposures); } +#ifdef ROOTLESS +/* Ugly, ugly, but we lost our hooks into miPaintWindow... =/ */ +void RootlessSetPixmapOfAncestors(WindowPtr pWin); +void RootlessStartDrawing(WindowPtr pWin); +void RootlessDamageRegion(WindowPtr pWin, RegionPtr prgn); +Bool IsFramedWindow(WindowPtr pWin); +#endif + _X_EXPORT void miPaintWindow(WindowPtr pWin, RegionPtr prgn, int what) { @@ -556,6 +564,19 @@ miPaintWindow(WindowPtr pWin, RegionPtr prgn, int what) Bool solid = TRUE; DrawablePtr drawable = &pWin->drawable; +#ifdef ROOTLESS + if(IsFramedWindow(pWin)) { + RootlessStartDrawing(pWin); + RootlessDamageRegion(pWin, prgn); + + if(pWin->backgroundState == ParentRelative) { + if((what == PW_BACKGROUND) || + (what == PW_BORDER && !pWin->borderIsPixel)) + RootlessSetPixmapOfAncestors(pWin); + } + } +#endif + if (what == PW_BACKGROUND) { while (pWin->backgroundState == ParentRelative) diff --git a/miext/rootless/rootlessWindow.c b/miext/rootless/ rootlessWindow.c index 3787e7e..2e5e84c 100644 --- a/miext/rootless/rootlessWindow.c +++ b/miext/rootless/rootlessWindow.c @@ -1692,3 +1692,29 @@ RootlessShowAllWindows (void) RootlessScreenExpose (pScreen); } } + +/* + * SetPixmapOfAncestors + * Set the Pixmaps on all ParentRelative windows up the ancestor chain. + */ +void +RootlessSetPixmapOfAncestors(WindowPtr pWin) +{ + ScreenPtr pScreen = pWin->drawable.pScreen; + WindowPtr topWin = TopLevelParent(pWin); + RootlessWindowRec *topWinRec = WINREC(topWin); + + while (pWin->backgroundState == ParentRelative) { + if (pWin == topWin) { + // disallow ParentRelative background state on top level + XID pixel = 0; + ChangeWindowAttributes(pWin, CWBackPixel, &pixel, serverClient); + RL_DEBUG_MSG("Cleared ParentRelative on 0x%x.\n", pWin); + break; + } + + pWin = pWin->parent; + pScreen->SetWindowPixmap(pWin, topWinRec->pixmap); + } +} + On Sep 24, 2009, at 14:29, Jeremy Huddleston wrote:
Thanks Martin,
This will help tremendously. I'm going to look at it this weekend, and if I can't figure it out, I'll ask the brain trust at XDC next week.
Thanks, Jeremy
On Sep 24, 2009, at 13:38, Martin Otte wrote:
Hi,
Attached is a simplified test case showing that in a call to XCreateSimpleWindow, the border around the subwindow is not displayed. With the 1.4 server, the program displays:
<server_1.4.png>
but with the 1.5 server, the border of the inner window is not shown:
<server_1.5.png>
I also added this example code to bug report #290.
Hope this helps, Martin
<border.c>
On Sep 18, 2009, at 12:49 AM, Jeremy Huddleston wrote:
On Sep 17, 2009, at 11:48, Martin Otte wrote:
Hi,
The problem with the lines not drawn correctly occurs when calling XCreateSimpleWindow. The program I have uses XCreateSimpleWindow to create the buttons and their borders. When I increase the size of the border in XCreateSimpleWindow and turn off all other decorations, this is what I see:
<border.png>
It is interesting to see part of the quartz-wm frame imposed on the button borders. My guess is that the border pixmap is not being created/shown correctly in the server. Looking through dix/ window.c and mi/miexpose.c a lot has changed between the 1.4 and 1.5 versions of the server, so I don't think I'll be much help in tracking down the problem.
My guess is that the changes have just resulted in nothing actually being drawn. What you're seeing in the background there is actually just the uninitialized garbage that happened to be at the memory location allocated for that backing store which was previously used to draw a quartz-wm widget.
Can you provide me with your simplified test case. That'll be easier than dragging the xterm window resize around every time I want to debug this.
Thanks, Jeremy
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Ok, I think I found the cause and a hackish workaround for this issue... The problem stems from the fact that the core/common X server code no longer has hooks for paintWindowBorder and paintWindowBackground. We were using those hooks for correcting alpha values as well as handling cases like this. After the core X developers nuked those callbacks a while back, I went through and fixed hacked the alpha values back into place, but I missed this particular problem. I have a bit of a hack to get functionality back in place, but it's not elegant. I'm going to try finding a better solution for all of this. I essentially resurrected some code that had been punted and found a place to put it into the pipe, but my guess is that there's a better location for it. --Jeremy ---- diff --git a/mi/miexpose.c b/mi/miexpose.c index 961c35c..d540a9f 100644 --- a/mi/miexpose.c +++ b/mi/miexpose.c @@ -531,6 +531,14 @@ miWindowExposures(pWin, prgn, other_exposed) REGION_DESTROY( pWin->drawable.pScreen, exposures); } +#ifdef ROOTLESS +/* Ugly, ugly, but we lost our hooks into miPaintWindow... =/ */ +void RootlessSetPixmapOfAncestors(WindowPtr pWin); +void RootlessStartDrawing(WindowPtr pWin); +void RootlessDamageRegion(WindowPtr pWin, RegionPtr prgn); +Bool IsFramedWindow(WindowPtr pWin); +#endif + _X_EXPORT void miPaintWindow(WindowPtr pWin, RegionPtr prgn, int what) { @@ -556,6 +564,19 @@ miPaintWindow(WindowPtr pWin, RegionPtr prgn, int what) Bool solid = TRUE; DrawablePtr drawable = &pWin->drawable; +#ifdef ROOTLESS + if(IsFramedWindow(pWin)) { + RootlessStartDrawing(pWin); + RootlessDamageRegion(pWin, prgn); + + if(pWin->backgroundState == ParentRelative) { + if((what == PW_BACKGROUND) || + (what == PW_BORDER && !pWin->borderIsPixel)) + RootlessSetPixmapOfAncestors(pWin); + } + } +#endif + if (what == PW_BACKGROUND) { while (pWin->backgroundState == ParentRelative) diff --git a/miext/rootless/rootlessWindow.c b/miext/rootless/ rootlessWindow.c index 3787e7e..2e5e84c 100644 --- a/miext/rootless/rootlessWindow.c +++ b/miext/rootless/rootlessWindow.c @@ -1692,3 +1692,29 @@ RootlessShowAllWindows (void) RootlessScreenExpose (pScreen); } } + +/* + * SetPixmapOfAncestors + * Set the Pixmaps on all ParentRelative windows up the ancestor chain. + */ +void +RootlessSetPixmapOfAncestors(WindowPtr pWin) +{ + ScreenPtr pScreen = pWin->drawable.pScreen; + WindowPtr topWin = TopLevelParent(pWin); + RootlessWindowRec *topWinRec = WINREC(topWin); + + while (pWin->backgroundState == ParentRelative) { + if (pWin == topWin) { + // disallow ParentRelative background state on top level + XID pixel = 0; + ChangeWindowAttributes(pWin, CWBackPixel, &pixel, serverClient); + RL_DEBUG_MSG("Cleared ParentRelative on 0x%x.\n", pWin); + break; + } + + pWin = pWin->parent; + pScreen->SetWindowPixmap(pWin, topWinRec->pixmap); + } +} + On Sep 24, 2009, at 13:38, Martin Otte wrote:
Hi,
Attached is a simplified test case showing that in a call to XCreateSimpleWindow, the border around the subwindow is not displayed. With the 1.4 server, the program displays:
<server_1.4.png>
but with the 1.5 server, the border of the inner window is not shown:
<server_1.5.png>
I also added this example code to bug report #290.
Hope this helps, Martin
<border.c>
On Sep 18, 2009, at 12:49 AM, Jeremy Huddleston wrote:
On Sep 17, 2009, at 11:48, Martin Otte wrote:
Hi,
The problem with the lines not drawn correctly occurs when calling XCreateSimpleWindow. The program I have uses XCreateSimpleWindow to create the buttons and their borders. When I increase the size of the border in XCreateSimpleWindow and turn off all other decorations, this is what I see:
<border.png>
It is interesting to see part of the quartz-wm frame imposed on the button borders. My guess is that the border pixmap is not being created/shown correctly in the server. Looking through dix/ window.c and mi/miexpose.c a lot has changed between the 1.4 and 1.5 versions of the server, so I don't think I'll be much help in tracking down the problem.
My guess is that the changes have just resulted in nothing actually being drawn. What you're seeing in the background there is actually just the uninitialized garbage that happened to be at the memory location allocated for that backing store which was previously used to draw a quartz-wm widget.
Can you provide me with your simplified test case. That'll be easier than dragging the xterm window resize around every time I want to debug this.
Thanks, Jeremy
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
participants (3)
-
Jeremy Huddleston
-
Jeremy Huddleston
-
Martin Otte