How does xorg paint stacked windows?
I was reading a book called Low Level X Window Programming
by Ross Maloney. He was talking about one of the key aspects of a stacked window system i.e restoration of "hidden" contents when you "remove" a window.
Normally you would expect the content "behind" to be immediately visible. However, apparently, this is not something that an x
implementation has to provide though some does.
The save under and backing store services differ slightly. In save
under, the contents of the screen onto which a window is mapped is
save by the server at the instance before the window is mapped, using
the memory of the server.
- If this is not something that
x
server provides, should it be implemented in the client side? - How do some of the typical window manager implement stacking?
- If
xorg
does provide this feature, is there any specific algorithm that can be used especially for "save under"? I didn't understand how saving a copy of the overlapping area can be used later especially when you have multiple overlaps =) My mind is already blowing! Can such delta's be used to reconstruct the stack?
If not, does it repaint each of the stacked window one by one in case of a random window removal? Wikipedia says the following:
Stacking is a relatively slow process, requiring the redrawing of
every window one-by-one, from the rear-most and outer-most to the
front most and inner-most. Many stacking window managers don't always
redraw background windows. Others can detect when a redraw of all
windows is required, as some applications request stacking when their
output has changed. Re-stacking is usually done through a function
call to the window manager, which selectively redraws windows as
needed. For example, if a background window is brought to the front,
only that window should need to be redrawn.
PS: I know this is a big question, but it would be helpful to get some pointers.
xorg window-manager window
add a comment |
I was reading a book called Low Level X Window Programming
by Ross Maloney. He was talking about one of the key aspects of a stacked window system i.e restoration of "hidden" contents when you "remove" a window.
Normally you would expect the content "behind" to be immediately visible. However, apparently, this is not something that an x
implementation has to provide though some does.
The save under and backing store services differ slightly. In save
under, the contents of the screen onto which a window is mapped is
save by the server at the instance before the window is mapped, using
the memory of the server.
- If this is not something that
x
server provides, should it be implemented in the client side? - How do some of the typical window manager implement stacking?
- If
xorg
does provide this feature, is there any specific algorithm that can be used especially for "save under"? I didn't understand how saving a copy of the overlapping area can be used later especially when you have multiple overlaps =) My mind is already blowing! Can such delta's be used to reconstruct the stack?
If not, does it repaint each of the stacked window one by one in case of a random window removal? Wikipedia says the following:
Stacking is a relatively slow process, requiring the redrawing of
every window one-by-one, from the rear-most and outer-most to the
front most and inner-most. Many stacking window managers don't always
redraw background windows. Others can detect when a redraw of all
windows is required, as some applications request stacking when their
output has changed. Re-stacking is usually done through a function
call to the window manager, which selectively redraws windows as
needed. For example, if a background window is brought to the front,
only that window should need to be redrawn.
PS: I know this is a big question, but it would be helpful to get some pointers.
xorg window-manager window
add a comment |
I was reading a book called Low Level X Window Programming
by Ross Maloney. He was talking about one of the key aspects of a stacked window system i.e restoration of "hidden" contents when you "remove" a window.
Normally you would expect the content "behind" to be immediately visible. However, apparently, this is not something that an x
implementation has to provide though some does.
The save under and backing store services differ slightly. In save
under, the contents of the screen onto which a window is mapped is
save by the server at the instance before the window is mapped, using
the memory of the server.
- If this is not something that
x
server provides, should it be implemented in the client side? - How do some of the typical window manager implement stacking?
- If
xorg
does provide this feature, is there any specific algorithm that can be used especially for "save under"? I didn't understand how saving a copy of the overlapping area can be used later especially when you have multiple overlaps =) My mind is already blowing! Can such delta's be used to reconstruct the stack?
If not, does it repaint each of the stacked window one by one in case of a random window removal? Wikipedia says the following:
Stacking is a relatively slow process, requiring the redrawing of
every window one-by-one, from the rear-most and outer-most to the
front most and inner-most. Many stacking window managers don't always
redraw background windows. Others can detect when a redraw of all
windows is required, as some applications request stacking when their
output has changed. Re-stacking is usually done through a function
call to the window manager, which selectively redraws windows as
needed. For example, if a background window is brought to the front,
only that window should need to be redrawn.
PS: I know this is a big question, but it would be helpful to get some pointers.
xorg window-manager window
I was reading a book called Low Level X Window Programming
by Ross Maloney. He was talking about one of the key aspects of a stacked window system i.e restoration of "hidden" contents when you "remove" a window.
Normally you would expect the content "behind" to be immediately visible. However, apparently, this is not something that an x
implementation has to provide though some does.
The save under and backing store services differ slightly. In save
under, the contents of the screen onto which a window is mapped is
save by the server at the instance before the window is mapped, using
the memory of the server.
- If this is not something that
x
server provides, should it be implemented in the client side? - How do some of the typical window manager implement stacking?
- If
xorg
does provide this feature, is there any specific algorithm that can be used especially for "save under"? I didn't understand how saving a copy of the overlapping area can be used later especially when you have multiple overlaps =) My mind is already blowing! Can such delta's be used to reconstruct the stack?
If not, does it repaint each of the stacked window one by one in case of a random window removal? Wikipedia says the following:
Stacking is a relatively slow process, requiring the redrawing of
every window one-by-one, from the rear-most and outer-most to the
front most and inner-most. Many stacking window managers don't always
redraw background windows. Others can detect when a redraw of all
windows is required, as some applications request stacking when their
output has changed. Re-stacking is usually done through a function
call to the window manager, which selectively redraws windows as
needed. For example, if a background window is brought to the front,
only that window should need to be redrawn.
PS: I know this is a big question, but it would be helpful to get some pointers.
xorg window-manager window
xorg window-manager window
edited 1 hour ago
asked 1 hour ago
Nishant
1739
1739
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Both backing store and save under are attributes/flags that can be set when creating a window with XCreateWindow
. However, they're only hints to the X11 server, are not on by default, and are not really worth the trouble with modern hardware.
Generally, when (part of) a background window becomes visible, the XServer will send an Expose event to the X11 client, which should cause it to redraw it. Since those are only hints, the X11 server may still send an Expose
even if the client had set both .backing_store = Always
on the window and CWSaveUnder
on the popups it opened on top of it.
The window manager has nothing to do with all this; it does not redraw any windows (other than its own: the title bars, close buttons).
add a comment |
If not, does it repaint each of the stacked window one by one in case of a random window removal?
Most popular desktops use the more recent XCOMPOSITE extension. The entire window contents is rendered to off-screen buffers, so they are all available to the compositing manager without needing to request applications to redraw them.
This extension causes a entire sub-tree of the window hierarchy to be rendered to an off-screen buffer. Applications can then take the contents of that buffer and do whatever they like. The off-screen buffer can be automatically merged into the parent window or merged by external programs, called compositing managers. Compositing managers enable lots of fun effects.
2
Nothing to do with it. And yes, Xorg does implement backing-store, though it's not enabled by default (with modern hardware, it's not really worth it; but the backing store implementation was the reason for some nasty legal stuff, Rob Pike heckling, etc) The XCOMPOSITE extension is basically about something different: implementing translucent, alpha-compositing windows.
– Uncle Billy
1 hour ago
Thanks @sourcejedi. Do you know of any algorithms that can be used to implement "save under" kind of thing?!
– Nishant
1 hour ago
@UncleBilly, interesting. I am just reading this commandcenter.blogspot.com/2006/06/… from Rob Pikes' blog.
– Nishant
50 mins ago
@UncleBilly and Nishant: edited. XCOMPOSITE is related in the sense that using it removes the need for any other solution to this problem.
– sourcejedi
29 mins ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f491359%2fhow-does-xorg-paint-stacked-windows%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Both backing store and save under are attributes/flags that can be set when creating a window with XCreateWindow
. However, they're only hints to the X11 server, are not on by default, and are not really worth the trouble with modern hardware.
Generally, when (part of) a background window becomes visible, the XServer will send an Expose event to the X11 client, which should cause it to redraw it. Since those are only hints, the X11 server may still send an Expose
even if the client had set both .backing_store = Always
on the window and CWSaveUnder
on the popups it opened on top of it.
The window manager has nothing to do with all this; it does not redraw any windows (other than its own: the title bars, close buttons).
add a comment |
Both backing store and save under are attributes/flags that can be set when creating a window with XCreateWindow
. However, they're only hints to the X11 server, are not on by default, and are not really worth the trouble with modern hardware.
Generally, when (part of) a background window becomes visible, the XServer will send an Expose event to the X11 client, which should cause it to redraw it. Since those are only hints, the X11 server may still send an Expose
even if the client had set both .backing_store = Always
on the window and CWSaveUnder
on the popups it opened on top of it.
The window manager has nothing to do with all this; it does not redraw any windows (other than its own: the title bars, close buttons).
add a comment |
Both backing store and save under are attributes/flags that can be set when creating a window with XCreateWindow
. However, they're only hints to the X11 server, are not on by default, and are not really worth the trouble with modern hardware.
Generally, when (part of) a background window becomes visible, the XServer will send an Expose event to the X11 client, which should cause it to redraw it. Since those are only hints, the X11 server may still send an Expose
even if the client had set both .backing_store = Always
on the window and CWSaveUnder
on the popups it opened on top of it.
The window manager has nothing to do with all this; it does not redraw any windows (other than its own: the title bars, close buttons).
Both backing store and save under are attributes/flags that can be set when creating a window with XCreateWindow
. However, they're only hints to the X11 server, are not on by default, and are not really worth the trouble with modern hardware.
Generally, when (part of) a background window becomes visible, the XServer will send an Expose event to the X11 client, which should cause it to redraw it. Since those are only hints, the X11 server may still send an Expose
even if the client had set both .backing_store = Always
on the window and CWSaveUnder
on the popups it opened on top of it.
The window manager has nothing to do with all this; it does not redraw any windows (other than its own: the title bars, close buttons).
answered 8 mins ago
Uncle Billy
3135
3135
add a comment |
add a comment |
If not, does it repaint each of the stacked window one by one in case of a random window removal?
Most popular desktops use the more recent XCOMPOSITE extension. The entire window contents is rendered to off-screen buffers, so they are all available to the compositing manager without needing to request applications to redraw them.
This extension causes a entire sub-tree of the window hierarchy to be rendered to an off-screen buffer. Applications can then take the contents of that buffer and do whatever they like. The off-screen buffer can be automatically merged into the parent window or merged by external programs, called compositing managers. Compositing managers enable lots of fun effects.
2
Nothing to do with it. And yes, Xorg does implement backing-store, though it's not enabled by default (with modern hardware, it's not really worth it; but the backing store implementation was the reason for some nasty legal stuff, Rob Pike heckling, etc) The XCOMPOSITE extension is basically about something different: implementing translucent, alpha-compositing windows.
– Uncle Billy
1 hour ago
Thanks @sourcejedi. Do you know of any algorithms that can be used to implement "save under" kind of thing?!
– Nishant
1 hour ago
@UncleBilly, interesting. I am just reading this commandcenter.blogspot.com/2006/06/… from Rob Pikes' blog.
– Nishant
50 mins ago
@UncleBilly and Nishant: edited. XCOMPOSITE is related in the sense that using it removes the need for any other solution to this problem.
– sourcejedi
29 mins ago
add a comment |
If not, does it repaint each of the stacked window one by one in case of a random window removal?
Most popular desktops use the more recent XCOMPOSITE extension. The entire window contents is rendered to off-screen buffers, so they are all available to the compositing manager without needing to request applications to redraw them.
This extension causes a entire sub-tree of the window hierarchy to be rendered to an off-screen buffer. Applications can then take the contents of that buffer and do whatever they like. The off-screen buffer can be automatically merged into the parent window or merged by external programs, called compositing managers. Compositing managers enable lots of fun effects.
2
Nothing to do with it. And yes, Xorg does implement backing-store, though it's not enabled by default (with modern hardware, it's not really worth it; but the backing store implementation was the reason for some nasty legal stuff, Rob Pike heckling, etc) The XCOMPOSITE extension is basically about something different: implementing translucent, alpha-compositing windows.
– Uncle Billy
1 hour ago
Thanks @sourcejedi. Do you know of any algorithms that can be used to implement "save under" kind of thing?!
– Nishant
1 hour ago
@UncleBilly, interesting. I am just reading this commandcenter.blogspot.com/2006/06/… from Rob Pikes' blog.
– Nishant
50 mins ago
@UncleBilly and Nishant: edited. XCOMPOSITE is related in the sense that using it removes the need for any other solution to this problem.
– sourcejedi
29 mins ago
add a comment |
If not, does it repaint each of the stacked window one by one in case of a random window removal?
Most popular desktops use the more recent XCOMPOSITE extension. The entire window contents is rendered to off-screen buffers, so they are all available to the compositing manager without needing to request applications to redraw them.
This extension causes a entire sub-tree of the window hierarchy to be rendered to an off-screen buffer. Applications can then take the contents of that buffer and do whatever they like. The off-screen buffer can be automatically merged into the parent window or merged by external programs, called compositing managers. Compositing managers enable lots of fun effects.
If not, does it repaint each of the stacked window one by one in case of a random window removal?
Most popular desktops use the more recent XCOMPOSITE extension. The entire window contents is rendered to off-screen buffers, so they are all available to the compositing manager without needing to request applications to redraw them.
This extension causes a entire sub-tree of the window hierarchy to be rendered to an off-screen buffer. Applications can then take the contents of that buffer and do whatever they like. The off-screen buffer can be automatically merged into the parent window or merged by external programs, called compositing managers. Compositing managers enable lots of fun effects.
edited 31 mins ago
answered 1 hour ago
sourcejedi
22.7k435100
22.7k435100
2
Nothing to do with it. And yes, Xorg does implement backing-store, though it's not enabled by default (with modern hardware, it's not really worth it; but the backing store implementation was the reason for some nasty legal stuff, Rob Pike heckling, etc) The XCOMPOSITE extension is basically about something different: implementing translucent, alpha-compositing windows.
– Uncle Billy
1 hour ago
Thanks @sourcejedi. Do you know of any algorithms that can be used to implement "save under" kind of thing?!
– Nishant
1 hour ago
@UncleBilly, interesting. I am just reading this commandcenter.blogspot.com/2006/06/… from Rob Pikes' blog.
– Nishant
50 mins ago
@UncleBilly and Nishant: edited. XCOMPOSITE is related in the sense that using it removes the need for any other solution to this problem.
– sourcejedi
29 mins ago
add a comment |
2
Nothing to do with it. And yes, Xorg does implement backing-store, though it's not enabled by default (with modern hardware, it's not really worth it; but the backing store implementation was the reason for some nasty legal stuff, Rob Pike heckling, etc) The XCOMPOSITE extension is basically about something different: implementing translucent, alpha-compositing windows.
– Uncle Billy
1 hour ago
Thanks @sourcejedi. Do you know of any algorithms that can be used to implement "save under" kind of thing?!
– Nishant
1 hour ago
@UncleBilly, interesting. I am just reading this commandcenter.blogspot.com/2006/06/… from Rob Pikes' blog.
– Nishant
50 mins ago
@UncleBilly and Nishant: edited. XCOMPOSITE is related in the sense that using it removes the need for any other solution to this problem.
– sourcejedi
29 mins ago
2
2
Nothing to do with it. And yes, Xorg does implement backing-store, though it's not enabled by default (with modern hardware, it's not really worth it; but the backing store implementation was the reason for some nasty legal stuff, Rob Pike heckling, etc) The XCOMPOSITE extension is basically about something different: implementing translucent, alpha-compositing windows.
– Uncle Billy
1 hour ago
Nothing to do with it. And yes, Xorg does implement backing-store, though it's not enabled by default (with modern hardware, it's not really worth it; but the backing store implementation was the reason for some nasty legal stuff, Rob Pike heckling, etc) The XCOMPOSITE extension is basically about something different: implementing translucent, alpha-compositing windows.
– Uncle Billy
1 hour ago
Thanks @sourcejedi. Do you know of any algorithms that can be used to implement "save under" kind of thing?!
– Nishant
1 hour ago
Thanks @sourcejedi. Do you know of any algorithms that can be used to implement "save under" kind of thing?!
– Nishant
1 hour ago
@UncleBilly, interesting. I am just reading this commandcenter.blogspot.com/2006/06/… from Rob Pikes' blog.
– Nishant
50 mins ago
@UncleBilly, interesting. I am just reading this commandcenter.blogspot.com/2006/06/… from Rob Pikes' blog.
– Nishant
50 mins ago
@UncleBilly and Nishant: edited. XCOMPOSITE is related in the sense that using it removes the need for any other solution to this problem.
– sourcejedi
29 mins ago
@UncleBilly and Nishant: edited. XCOMPOSITE is related in the sense that using it removes the need for any other solution to this problem.
– sourcejedi
29 mins ago
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f491359%2fhow-does-xorg-paint-stacked-windows%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown