[SDL] Overlay surfaces [vs SDL 1.2.7]

[Thomas Harte]

I have been developing an application that uses overlay surfaces under 
SDL  with MSVC 6 using the DirectX 5.0 target. My application only uses 
overlay surfaces if it can get hardware acceleration. I have encountered 
several problems with overlay surfaces as accessed through SDL in a 
windowed application, namely:

- seemingly no SDL way to 'hide' overlay surfaces (i.e. access to 
DDOVER_HIDE for my target), so no way to write an application that can 
be minimised
- overlay surfaces are not obscured by overlapping windows (seems that 
destination colour keying is not in use?)
- if the SDL window is dragged even slightly off the edge of the screen, 
the overlay simply fails to move at all from the position of the window 
pre-dragging (it seems SDL is quite thick about source rectangles?)

Also, I am unhappy with the way that it seems there is no way to 
discover what overlay surfaces will be hardware accelerated without 
creating them and checking.

But besides all this, I was essentially happy, having restricted my 
application to only considering overlay surfaces if in full screen mode. 
This was under SDL 1.2.5. As I considered the latter two of my bullet 
pointed remarks might well be bugs I upgraded to SDL 1.2.7.

Under 1.2.7 I have a much greater problem - the same code on the same 
hardware and operating system now fails at SDL_DisplayYUVOverlay every 
time, returning -1. Also, as of 1.2.7, SDL seems to have discovered some 
way to use accelerated overlay surfaces on my hardware where it could 
not before - namely in high resolution and high colour depth displays 
where video memory is very tight.

Having glanced into the sources, this seems to be because at some stage 
the define at line 38 of SDL_dx5yuv.c has been commented out so that 
hardware overlay surfaces are never attempted under DirectX. Other than 
that there haven't been any functional changes.

As there is nothing whatsoever in the change log related to YUV overlays 
under DirectX, can I assume this was a simple oversight? If not, can I 
instead assume that in future the DirectX driver will not claim to have 
a hardware overlay surface when it hasn't (as presently at line 185)? 
Also, is there likely to be any change to any of the other issues I have 
faced in the near future?

Also, as I notice from reading the code that only 1x blitting and 2x 
blitting are supported for software overlay surfaces, perhaps the 
sentence in the doc project "If the dstrect is a larger or smaller than 
the overlay then the overlay will be scaled, this is optimized for 2x 
scaling." should be adjusted?

On a tangential note, I consider it unsatisfactory if I have to enable 
hardware overlays for myself and therefore build an sdl.dll which is 
different to everyone else's - to save myself a few minutes does anybody 
have a workspace that produces a statically linking version of SDL?

-Thomas