Re: On a side note - display resolution changes now handled
Jehan wrote: Harold Hunt wrote: You must be tired. Well, actually yes :p. I did some canoeing last Friday and I haven't recovered yet. :) Are you talking about canoeing, or ``canoeing''. When we went ``canoeing'' it involved a cooler full of beer and as the day progressed the cooler full of beer was spotted more and more often floating down the river next to a coule of upside down canoes and a bunch of guys trying to get the cooler back into a righted canoe before the precious contents were lost. But I digress... :) If we create a new offscreen surface (which I was not talking about doing, I only said we have to recreate the primary (onscreen) surface) with a different depth/format/etc than the original offscreen surface, then we have effectively changed the X graphics mode and we would need to use some sort of X extension to notify clients that all pixmaps and visuals have been reset. If there is such an extension, I am not aware of it. I'm not familiar with DirectX nor the internal of X so maybe I used the wrong words. I'm not actually talking of changing what the X server think the screen resolution/depth is. But we can already have a different resolution/depth for the visual than for the monitor, which means that there is a conversion at some point when the depth doesn't match. So why can't you just throw away everything that is after the conversion? I would think that, at worst, if the conversion happens when drawing into the offscreen surface, all the buffers would have to be recreated and that X would just have to ask all X windows to redraw their content in the new offscreen buffer. I think I see where you are confused. I said previously that we can handle screen resolution changes because we essentially just enable scrollbars, if necessary, to allow the extra area to be viewed. With the Shadow GDI engine, that is all that has to be done. However, with the Shadow DirectDraw and Shadow DirectDraw Non-Locking engines we must release and recreate the primary surface using the same size as it had before. This is really just a technicality. You see, DirectDraw allows a surface to be larger than the screen size. But, when you change the screen resolution, DirectDraw requires that you release the primary surface and create again. DirectDraw doesn't care if you recreate the primary surface using the exact same parameters; rather, it just wants you to recreate it. Yes, this is silly, but that is what DirectDraw requires. I also said previously that screen depth changes were much more disruptive than screen resolution changes. First, a little background on surfaces. We create an offscreen surface and we provide the X graphics layers with a pointer into the memory used to represent the pixels on that surface. All X graphics operations (fb, shadow, mi, etc.) are done by calculating offsets of various pixels in this ``framebuffer'' and applying various transformations to those pixels. Thus, a horizontal blue line would be drawn by offsetting to the start of that line, then flipping the value for the next x pixels to blue. The ``shadow'' layer in X allows graphics to be drawn to an offscreen framebuffer. Shadow keeps track of the regions in the offscreen fraembuffer that have been updated, and it occasionally calls a ``shadow update'' function that tells us to transfer those regions to the screen. DirectDraw has something called a ``primary surface'' that represents what is being displayed on the screen. When we want to display the updated bits of the offscreen framebuffer, we do a ``bit block transfer'' from the offscreen surface to the primary surface. The offscreen surface and the primary surface usually have the same format (that is, they have the same pixel format that specifies how many bits for red, green, and blue and how many bits are used per pixel value in the framebuffer). If the offscreen surface and the primary surface have the same format, then a bit block transfer between them is essentially a memory copy from the system memory to the video memory (with lots of fun synching issues that Windows takes care of for us). Imagine for a second that the offscreen surface was allowed to have a different format than the primary surface. Then a bit block transfer from the offscreen surface to the primary surface now must examine *every single pixel* and transform the color values from, say, 16 bits per pixel to 32 bits per pixel. That is a hell of a lot more complex than doing a simple memory transfer. DirectDraw is primarily concerned with enabling high-performance. Therefore, I think that allowing the offscreen surface to have a different depth than the primary surface would be contradictory to the purpose of DirectDraw. I have not checked the DirectDraw documentation to see whether offscreen surfaces must have the same depth as primary surfaces. I did say that
Re: On a side note - display resolution changes now handled
Jehan wrote: Harold L Hunt II wrote: Well, actually yes :p. I did some canoeing last Friday and I haven't recovered yet. :) Are you talking about canoeing, or ``canoeing''. When we went ``canoeing'' it involved a cooler full of beer and as the day progressed the cooler full of beer was spotted more and more often floating down the river next to a coule of upside down canoes and a bunch of guys trying to get the cooler back into a righted canoe before the precious contents were lost. But I digress... :) Sounds nice :). But this was a social event from my company so no alcohol. Moreover, I don't drink alcohol. I don't trust myself to stop when I have too much :p. Heh... booze was a little too fun for me too. I only drink it rarely now. Never more than a single drink at a time. But have I got some stories from the good old days :) If we create a new offscreen surface (which I was not talking about doing, I only said we have to recreate the primary (onscreen) surface) with a different depth/format/etc than the original offscreen surface, then we have effectively changed the X graphics mode and we would need to use some sort of X extension to notify clients that all pixmaps and visuals have been reset. If there is such an extension, I am not aware of it. I'm not familiar with DirectX nor the internal of X so maybe I used the wrong words. I'm not actually talking of changing what the X server think the screen resolution/depth is. But we can already have a different resolution/depth for the visual than for the monitor, which means that there is a conversion at some point when the depth doesn't match. So why can't you just throw away everything that is after the conversion? I would think that, at worst, if the conversion happens when drawing into the offscreen surface, all the buffers would have to be recreated and that X would just have to ask all X windows to redraw their content in the new offscreen buffer. I think I see where you are confused. I said previously that we can handle screen resolution changes because we essentially just enable scrollbars, if necessary, to allow the extra area to be viewed. With the Shadow GDI engine, that is all that has to be done. However, with the Shadow DirectDraw and Shadow DirectDraw Non-Locking engines we must release and recreate the primary surface using the same size as it had before. This is really just a technicality. You see, DirectDraw allows a surface to be larger than the screen size. But, when you change the screen resolution, DirectDraw requires that you release the primary surface and create again. DirectDraw doesn't care if you recreate the primary surface using the exact same parameters; rather, it just wants you to recreate it. Yes, this is silly, but that is what DirectDraw requires. I also said previously that screen depth changes were much more disruptive than screen resolution changes. First, a little background on surfaces. We create an offscreen surface and we provide the X graphics layers with a pointer into the memory used to represent the pixels on that surface. All X graphics operations (fb, shadow, mi, etc.) are done by calculating offsets of various pixels in this ``framebuffer'' and applying various transformations to those pixels. Thus, a horizontal blue line would be drawn by offsetting to the start of that line, then flipping the value for the next x pixels to blue. The ``shadow'' layer in X allows graphics to be drawn to an offscreen framebuffer. Shadow keeps track of the regions in the offscreen fraembuffer that have been updated, and it occasionally calls a ``shadow update'' function that tells us to transfer those regions to the screen. DirectDraw has something called a ``primary surface'' that represents what is being displayed on the screen. When we want to display the updated bits of the offscreen framebuffer, we do a ``bit block transfer'' from the offscreen surface to the primary surface. The offscreen surface and the primary surface usually have the same format (that is, they have the same pixel format that specifies how many bits for red, green, and blue and how many bits are used per pixel value in the framebuffer). If the offscreen surface and the primary surface have the same format, then a bit block transfer between them is essentially a memory copy from the system memory to the video memory (with lots of fun synching issues that Windows takes care of for us). Imagine for a second that the offscreen surface was allowed to have a different format than the primary surface. Then a bit block transfer from the offscreen surface to the primary surface now must examine *every single pixel* and transform the color values from, say, 16 bits per pixel to 32 bits per pixel. That is a hell of a lot more complex than doing a simple memory
RE: On a side note - display resolution changes now handled
Jehan, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jehan Sent: Sunday, July 21, 2002 6:43 PM To: [EMAIL PROTECTED] Subject: Re: On a side note - display resolution changes now handled Harold Hunt wrote: On the other hand, display depth changes are much more disruptive, I think. I don't think that DirectDraw can handle transfering bits from an offscreen surface of different format than the primary surface; doing so would seem to defeat the whole purpose of DirectDraw. My current thinking is that we will simply display a popup message indicating that Cygwin/XFree86 will be unavailable until the display depth is returned to the original depth. Isn't it possible to just froget about the previous offscreen buffer and ask all X windows to redraw themselves into the newly created surface? Jehan You must be tired. If we create a new offscreen surface (which I was not talking about doing, I only said we have to recreate the primary (onscreen) surface) with a different depth/format/etc than the original offscreen surface, then we have effectively changed the X graphics mode and we would need to use some sort of X extension to notify clients that all pixmaps and visuals have been reset. If there is such an extension, I am not aware of it. Harold
Re: On a side note - display resolution changes now handled
Harold Hunt wrote: You must be tired. Well, actually yes :p. I did some canoeing last Friday and I haven't recovered yet. :) If we create a new offscreen surface (which I was not talking about doing, I only said we have to recreate the primary (onscreen) surface) with a different depth/format/etc than the original offscreen surface, then we have effectively changed the X graphics mode and we would need to use some sort of X extension to notify clients that all pixmaps and visuals have been reset. If there is such an extension, I am not aware of it. I'm not familiar with DirectX nor the internal of X so maybe I used the wrong words. I'm not actually talking of changing what the X server think the screen resolution/depth is. But we can already have a different resolution/depth for the visual than for the monitor, which means that there is a conversion at some point when the depth doesn't match. So why can't you just throw away everything that is after the conversion? I would think that, at worst, if the conversion happens when drawing into the offscreen surface, all the buffers would have to be recreated and that X would just have to ask all X windows to redraw their content in the new offscreen buffer. Jehan
