Skip to main content
added 8 characters in body
Source Link
Nishant
  • 673
  • 12
  • 24

I was reading a book called Low Level X Window Programming by Ross Maloney. He was talking about one of the mainkey aspects of a stacked window system i.e restoration of "hidden" contents when you remove"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. However though some implementations provides this servicedoes.

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.

  1. If this is not something that x server provides, should it be implemented in the client side?
  2. How do some of the typical window manager implement stacking?
  3. 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 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 provides this feature, is there any specific algorithm that is used especially for "save under"? I couldn't understand how saving a copy of the overlapping area can be used when you have multiple overlaps. Can such "delta"'s be used to reconstruct the stack?

In general 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 on how this works.

I was reading a book called Low Level X Window Programming by Ross Maloney. He was talking about one of the main 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. However some implementations provides this service.

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 provides this feature, is there any specific algorithm that is used especially for "save under"? I couldn't understand how saving a copy of the overlapping area can be used when you have multiple overlaps. Can such "delta"'s be used to reconstruct the stack?

In general 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 on how this works.

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.

  1. If this is not something that x server provides, should it be implemented in the client side?
  2. How do some of the typical window manager implement stacking?
  3. 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.

deleted 27 characters in body
Source Link
Nishant
  • 673
  • 12
  • 24

I was reading a book called Low Level X Window Programming by Ross Maloney where he. He was talking about one of the main aspects of a common problem in stacked window systemssystem i. Ife restoration of "hidden" contents when you remove any of the stacked windows,a window.

Normally you would expect the content "behind" to be immediately visible. However, apparently this is not something that is mandatory for an x implementation has to provide. Currently there are two ways to achieveHowever some implementations provides this known as "save under" and "backing store"service.

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.

IsIf this is not something that x server has to provide orprovides, should it be implemented (more chance of optimization) in the client (less chance of optimizing)side? How do some of the typical window manager implement stacking? If xorg provides this feature, is there any specific algorithm that is used for especially for "save under"? I couldn't understand how saving a copy of the overlapoverlapping area can be used especially when you have multiple overlaps. Can such "delta"'s be used to reconstruct the stack?

If not,In general 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 on how this works.

I was reading Low Level X Window Programming by Ross Maloney where he was talking about a common problem in stacked window systems. If you remove any of the stacked windows, you would expect the content "behind" to be immediately visible. However, this is not something that is mandatory for an x implementation to provide. Currently there are two ways to achieve this known as "save under" and "backing store".

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.

Is this something that server has to provide or should it be implemented (more chance of optimization) in the client (less chance of optimizing)? How do window manager implement stacking? If xorg provides this feature, is there any specific algorithm that is used for especially for "save under"? I couldn't understand how saving a copy of the overlap area can be used especially when you have multiple overlaps. 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 on how this works.

I was reading a book called Low Level X Window Programming by Ross Maloney. He was talking about one of the main 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. However some implementations provides this service.

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 provides this feature, is there any specific algorithm that is used especially for "save under"? I couldn't understand how saving a copy of the overlapping area can be used when you have multiple overlaps. Can such "delta"'s be used to reconstruct the stack?

In general 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 on how this works.

Source Link
Nishant
  • 673
  • 12
  • 24

How does xorg paint stacked windows?

I was reading Low Level X Window Programming by Ross Maloney where he was talking about a common problem in stacked window systems. If you remove any of the stacked windows, you would expect the content "behind" to be immediately visible. However, this is not something that is mandatory for an x implementation to provide. Currently there are two ways to achieve this known as "save under" and "backing store".

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.

Is this something that server has to provide or should it be implemented (more chance of optimization) in the client (less chance of optimizing)? How do window manager implement stacking? If xorg provides this feature, is there any specific algorithm that is used for especially for "save under"? I couldn't understand how saving a copy of the overlap area can be used especially when you have multiple overlaps. 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 on how this works.