Re: Layered Windows in VMWare and Terminal Services
- From: "Ivan Brugiolo [MSFT]" <ivanbrug@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 20 Dec 2007 12:03:12 -0800
You do not need to update the content of a
ULW-Layered Window on move or resize.
That is the whole point. You supply the content
and, the OS takes care of tracking the poistion of the window,
and composes the overlays and underalys of that windows
as appropriate.
Even callinng InvalidateRect(hWnd,NULL) is a nop.
I'm afraid you are running into a variety of display-driver issue.
I'm not sure what is the display driver doing in a VWMware
virtual machine, but, it may be doing some Alphablending
incorrectly.
I'm not sure if it will make you feel better, but, if you have a Vista
machine, try running the sidebar.exe at 8bbp, 24bpp on different
hardwares/display-drivers than the WDDM ones.
You will experience a variety of visual artifacts.
I'm afraid you cannot do much better than that,
short of disabling fancy effects under TS or when you detect
misbehaving drivers.
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Fredo" <fredo@xxxxxxxxxxx> wrote in message
news:zZKdnQVeJ5GtCffanZ2dnUVZ_o-mnZ2d@xxxxxxxxxxxxxxx
I think we're getting bogged down in the 8bpp stuff and that's not really
the issue. When I run it under VMWare, I've got it at 32bpp and I still
have issues, so that's not my specific issue. It's simply a situation in
which the rendering is worst case.
I'm sure TS can do better, I was talking about a specific machine which
was a server with, I suspect, a really crappy video card that would only
allow 800x600x8. But that's neither here nor there. It's simply one case.
I'm more concerned about the general issue in that the layered windows
don't render properly under TS, or VMWare regardless of video settings
(unless you do a mode change).
Really, I'd just like some ideas for stuff I could try to see if there's
anything I can do to make the app work right without changing modes.
As for Layered Windows not needing to receive WM_PAINT, actually, we do
painting in some of them, but not via WM_PAINT. We do it at times when
WM_PAINT would normally get called, such as location change, size change,
visibility change, etc, but they're not in response to WM_PAINT messages.
We have a layered window that we use to draw shadows of certain dialogs
(Login and Splash, for example). We draw the shadow in the layered window.
"Ivan Brugiolo [MSFT]" <ivanbrug@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:%230GNZ9qQIHA.280@xxxxxxxxxxxxxxxxxxxxxxx
The terminal server display driver can do better than 800x600@8bpp.
It can do up to 4096x2048@32bpp in Vista/WS08,
and something less at 24bpp in WinXp/WS03
The code path used by UpdateLayeredWindows
down-converts a 32bpp DIB-Section to the color-depth
of the display. In the case of a 32bpp to 8bpp conversion, the
algorithm used is
32bpp-A8R8G8B8 -> 15bpp-R5G5B5 -> Inverse-Palette-Mapping
The default system-paletted is used, if nothing else is provided, and
that palette has only 20 entried aliased in the inverse-mapping space.
In simpler terms, it mens that ULW can only map to 20 color.
I'm not sure why you say that it maps always to black.
To be honest, I don't think this limitations of 32bpp->8bpp is
a remote-display-driver-limitation.
If you can ger a VGA device from the old-good-days,
you should be experiencing this in the local case as well.
Or, if you use BitBlt from two memory-DC with a source at 32bpp
and a destination at 8bpp, all of the above would apply as well.
A mode change causes all the device realizations to be invalidated
and re-created. At 8bpp, the relevant device realizations are the
palettes.
The description you give below is still very confusing, and,
I'm note sure about the exact sequence of mode-changes
and UpdateLayeredWindow.
In theory, ULW-Windows don't ever need to paint
(in fact, they should never receive WM_PAINT after
thay have been layered),
because their content is retained for the lifetime of the window
(or until the WS_EX_LAYERED bit is toggled.)
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Fredo" <fredo@xxxxxxxxxxx> wrote in message
news:C_OdnWE4c6NKpfTanZ2dnUVZ_tKinZ2d@xxxxxxxxxxxxxxx
Ivan,
Thanks for the info...
We're using UpdateLayeredWindow.
The problem is noticeably worse, for example, on a machine with Terminal
Services that's limited to 800x600x256. In that case, our splash screen
and login dialogs (both of which use ULW) show up completely black.
I actually have my development environment set up in a VMWare VM, which
is where I've personally experienced the issue the most. I've seen it in
TS and it's a bit different, but I suspect the underlying problem is
pretty similar.
MS has acknowledged that layered windows in terminal services is broken
and said they have no plans to fix it (I no longer have a link to the
issue where this was raised).
VMWare has their own SVGA driver which appears to be (or act) a bit
higher-end than what I've seen in the TS drivers.
I know that the display change is causing a repaint (a couple or three,
actually), but there's something else going on. After a display change,
something is either being reset or initialized that allows ULW to
continue to function in the app for the lifetime of the app.
It's this reset/initialization that I'd like to reproduce, if possible,
from within the code. I suspect it's something happening at the driver
level that I probably won't be able to reproduce without actually
causing a mode change, however.
I used Spy++ to get all the messages sent to the window during a mode
change and then I tried to internally send any that appeared they might
have some affect, using the same parameters (where applicable) that
happened during the mode change. None of these had any effect, however.
What I'm seeing, specifically, is the areas where we have layered
windows in use, the window itself is entirely transparent (invisible)
with the exception of controls that are on the window. When I do the
mode change, the windows display correctly.
Since our splash and login dialogs are both using ULW, they both show up
transparent except for the controls on them. For our main app, the main
frame window uses ULW and therefore there's a transparent border around
the app that doesn't repaint right (that is, when it's first displayed,
you see through the areas of the frame window and see what's behind
them, but when you move the app window around, the frame window doesn't
repaint, so you see whatever was behind the frame window when it
originally displayed being dragged around.
Does that make sense?
Pete
"Ivan Brugiolo [MSFT]" <ivanbrug@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:e1TOYPcQIHA.5160@xxxxxxxxxxxxxxxxxxxxxxx
Does this behavior reproes, for example, on the local machine,
without WMWare or anything else, when you have installed
the VGA display driver and you change,
for example, from 800x600@32bpp to 800x600@16bpp,
or from 800x600@32bpp to 1024x768@32bpp ?
In general, Layered Windows can be of two kind:
ULW (from UpdateLayeredWindow) or SLWA (SetLayeredWindowAttribute).
ULW window are always backed by a system memory redirection
surface, while SLWA may have a video-memory copy, depending
on what the display driver supports,
and if you are running Win20009, WinXp, Win2003 or Vista.
You naturally understand that any display-driver realization is lost
and possibly transfered between mode-changes, but, the system is
designed in such a way that either the resource is transferred (the ULW
case),
or, if it is destroyed, the application is asked to repaint
in order to recreate the resource underneath (this would be the SLWA
case).
That said for the general theory of mode-changes, I seem to remember
that most of the Visual Machine software do emulate some well-known
ancient video-card (for example, an S3 from the late 90's), for which
either VGA.sys is the display driver, or, some un-optimized compatible
display driver is used.
Can you describe, at this point, a little bit better what the
application
is doing, what are the expected results, and what are the actual
results ?
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
Use of any included script samples are subject to the terms specified
at
http://www.microsoft.com/info/cpyright.htm
"Fredo" <fredo@xxxxxxxxxxx> wrote in message
news:t7CdnabLGasLs_XanZ2dnUVZ_tOtnZ2d@xxxxxxxxxxxxxxx
Our application uses layered windows in several places and,
invariably, we have issues running the app inside Terminal Services
and VMWare.
I've noticed that, at least in VMWare (I haven't tested this in
terminal services yet), if I change the screen resolution while the
app is running (even if I change it and then change it back to the
original settings), the app then displays properly until I close the
app. It's like something gets triggered by the resolution change that
makes layered windows work. Does anyone have any idea what might be
going on here? Maybe it's something I can reproduce programmatically
(without actually changing the screen resolution).
Thanks
.
- References:
- Layered Windows in VMWare and Terminal Services
- From: Fredo
- Re: Layered Windows in VMWare and Terminal Services
- From: Ivan Brugiolo [MSFT]
- Re: Layered Windows in VMWare and Terminal Services
- From: Fredo
- Re: Layered Windows in VMWare and Terminal Services
- From: Ivan Brugiolo [MSFT]
- Re: Layered Windows in VMWare and Terminal Services
- From: Fredo
- Layered Windows in VMWare and Terminal Services
- Prev by Date: Re: compressed bitmaps...
- Next by Date: Re: How to go from GDI+ Bitmap to BitmapInfo Dib?
- Previous by thread: Re: Layered Windows in VMWare and Terminal Services
- Next by thread: Re: Layered Windows in VMWare and Terminal Services
- Index(es):
Relevant Pages
|
