On a side note - display resolution changes now handled

[Harold L Hunt II]

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 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 I did not think it likely that DirectDraw would allow 
>> different depths for the two surfaces.  You could verify this, but I 
>> am willing to bet that different depths are not allowed.
>>
>> Notice that we never change the format of the offscreen framebuffer. 
>> Thus, the structure of the framebuffer that X draws to us unchanged.  
>> X does not support screen depth changes while running, so changing the 
>> format of our offscreen framebuffer would causes all graphics 
>> operations to draw incorrectly and it would possibly cause a 
>> segmentation fault if the depth of the offscreen framebuffer was 
>> decreased (because the total memory region would then be smaller than 
>> X was expecting).
>>
>> ====
>>
>> With the Shadow GDI engine, Windows will transform *every single 
>> pixel* whenever we do a bit block transfer from a DIB to the screen 
>> and the depth of the two differs.  Thus, we are allowed to have a 
>> different depth for the X visual than for the Windows screen, but 
>> doing so causes a huge performance penalty.  However, I think that 
>> allowing this and providing a popup warning about the performance 
>> penalty is better than just ceasing to display graphics at all.
>>
>> ====
>>
>> With the DirectDraw engines I do not think that we can have a differnt 
>> depth for the two surfaces, so I fear that our only option in that 
>> case is to cease transferring the updated regions of the offscreen 
>> surface until such a time as the Windows screen depth has been 
>> returned to its original value.
>>
>> ====
>>
>> Does that answer your questions?
> 
> 
> Wow, what an answer. I was expecting that. Thanks.
 >

No problem.

> There was one question I didn't get the answer but it doesn't apply 
> anymore. I thought we could already have a different depth between the 
> visual and the screen (-depth option) but the option is ignore (at least 
> in windowed mode, didn't try in fullscreen).

It should be in the documentation (XWin.man, XWin -help, User's Guide) 
that the -depth parameter is ignored unless you are using a DirectDraw 
based engine with the -fullscreen parameter.  That is the only case 
where we can actually change the video mode to what we want it to be.

> I have another one though but maybe it doesn't apply in our case. I know 
> that in 3D games, you can have 16bit texture with a 32bit display and 
> vice versa.

Allowing a 16 bit texture for a 3D game that draws to a 32 bit display 
is not really all that different than allowing only 32 bit textures, if 
you think about it.  Drawing a 3D frame requires several steps, such as 
drawing the polygons, filling in the textures onto the surfaces of the 
polygons, lighting the scene, and finally rendering the whole scene. 
During rendering you may see that a 16 bit texture is lit such that the 
resulting color values are actually between the 16 bit color values 
available.  That is, the resulting color values could only be described 
in 32 bit color.  So, you can either truncate any pixel values after you 
light them, or you can just store the values that result from lighting 
as the new 32 bit color values.  So, you don't do any extra work to 
allow 16 bit textures on a 32 bit display.

DirectDraw, according to the docs, simply copies bits.  It does not 
interpret the bits, so it cannot convert between various depths.

 > So maybe DirectDraw does support the conversion. As for the
> performance issue, it may not be that much. DirectX usually uses 
> hardware acceleration (except on very old cards).
> Hmmm... After a quick read of MSDN, I got two different answers:
> - One says that surfaces can be converted:
> http://msdn.microsoft.com/library/default.asp?url=/workshop/browser/filter/overview/AboutTransformsandDXSurfaces.asp 
> 
> - One says that there DirectDraw doesn't provide format conversion.
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndxgen/html/dxfaq2.asp 
> 
> (Does DirectDraw convert between pixel formats while blitting?)
> And they say later on (How do I perform alpha blending?) that Direct3D 
> should be used for any "fancy" transformation.
> 

Transformations are not generally referring to pixel formats.  In the 
DirectX specs, when they talk about pixel formats they may be referring 
to whether or not an alpha channel or z-buffer is present.  I have no 
idea, but it doesn't seem like they are talking about 16 bit --> 32 bit 
translation, etc.

> Well, anyway, it's not as if the user keeps changing color depth. So a 
> simple popup dialog would be ok I guess... There is still a test that 
> need to be done: on dual screen systems, what happens if one screen is 
> 16bit while the other is 32bit? Is it even possible?
> 

I agree that the only reasonable solution is to essentially notify the 
user that changing depths is not supported.  In the future they can then 
avoid changing depths while Cygwin/XFree86 is running.  If they 
complain, we can simply defer them to the fact that the X protocol does 
not provide support for changing depths on the fly and that perhaps they 
would be interested in writing an extension to the protocol to support 
this :)

Harold