Re: Layered Windows in VMWare and Terminal Services

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









.

Relevant Pages

  • Re: display array in a frame wnd
    ... you have to create an app that is suitable for displaying an image. ... There would never be a need to create a frame window; it is not at all clear why such code ... I have to display results. ... Why is this not in an OnPaint handler? ...
    (microsoft.public.vc.mfc)
  • Re: display array in a frame wnd
    ... An SDI app, where the image is displayed in the view. ... There would never be a need to create a frame window; ... I better prefered to reuse display provided with the librairy opencv, ...
    (microsoft.public.vc.mfc)
  • Re: display array in a frame wnd
    ... An SDI app, where the image is displayed in the view. ... There would never be a need to create a frame window; ... I better prefered to reuse display provided with the librairy opencv, ...
    (microsoft.public.vc.mfc)
  • Re: Layered Windows in VMWare and Terminal Services
    ... I know that the display change is causing a repaint (a couple or three, ... to function in the app for the lifetime of the app. ... I used Spy++ to get all the messages sent to the window during a mode change ... the VGA display driver and you change, ...
    (microsoft.public.win32.programmer.gdi)
  • Re: Popup window blocking in XP Service Pack 2
    ... > I have a web app that has a legitimate use for pop up windows. ... > I also use it later to display a pdf application form. ... If I display it in the main window then I would have to ...
    (microsoft.public.dotnet.framework.aspnet)