EVALUATION
More information found during the review:
Now we only disable the pipeline on Windows XP or newer
client-class OS-es. This excludes Win2003, Win2K, Win9x/ME,
and Windows Server 2008.
The reason for disabling this on Windows 2008 is that
it doesn't even enable Aero theme by default - looks like
a weird Win2k, actually (and there is no way to enable it)
so clearly they don't care that much about graphics on
the server.
The driver for Windows Vista did install successfully on
2008, so it's possible that they will have the same
drivers versions for both client and server - even though
this is not relevant now.
There is one more scenario I'd like to test. It's
Win2008 Server with Terminal services enabled, with
"Aero experience" enabled for the clients. I'm not quite
sure how will that look like and whether it would use
the local or remote hw acceleration in this case.
I suspect that it would only be relevant to the WPF
applications (xaml+c#) - so they will ship only xaml
over the wire and render it on the client with hw
acceleration. Obviously we will unlikely be able to
use hw acceleration in this case which is why I'm
filing the webrev even before trying this experiment
(I don't expect terminal services to be easy
to configure =)
-------
Phil replied:
> maybe it depends. Here, talking just about cleartype,
> http://blogs.msdn.com/ts/archive/2006/09/08/747023.aspx
> it sounds like there's extra server side processing for
> GDI apps, and extra bandwidth needed
>
> But here http://msdn2.microsoft.com/en-us/windowsvista/aa905016.aspx
> it sounds like WPF would use client-side acceleration
Yes, like I said (this will require that both client and
server are Vista or better). But since we're not a WPF app we
will not benefit from this - to Windows we look just like
some Direct3D (or GDI) application - we don't even do
GDI to the screen, only blit to it.
I've setup the Terminal Server and client in the lab.
When connected to the server applications see local
hw resources in some form. For example, Direct3D apps
(including us) see a "RDPDD Chained DD" device with
device/vendor id of 0x0000. We do successfully
create the d3d device and everything works fine.
However, it is rather slow (and I put an ATI 9800 Pro
in the server, a pretty fast board) - even though both
client and server are sitting next to each other in
the same subnet. With D3D disabled the application
works much snappier.
In this case the client system had a board on which
we do not enable d3d acceleration if run locally
(it's a MX board).
I think it is still a good idea to disable d3d
for this (server-class OS) case - which we currently
do since we detect that we're running on a server OS.
Note that there is another scenario - when we do remote
desktop from Vista to Vista. In this case we still
enable d3d if the hw permits. And "hw" in this case is this
Chained DD device. I've setup this configuration as well -
two Vista systems, one Remote Desktop-ing to another (note
that it's different from Terminal services case since there
could be only one user RD-ing, but on a Terminal Server you
can have multiple users logged in and working at the same time).
So in this config both Vista systems had decent video boards
and RD was showing as Aero, with composition effects
enabled (not the default option). But I couldn't really
see that much of a difference between running Java with
D3D enabled and disabled - I've checked network utilization,
cpu utilization. Interestingly, in say Java2D demo both CPUs
(on client and server) were pegged. That kind of
surprised me.
Anyway, I think at this point we can leave it as is -
allow d3d in Remote Desktop case. We can disable
it later if needed.
Another scenario I've tested is "net meeting" - the Vista
version.
In this case one can setup a meeting and then "share"
some of applications or the whole desktop.
To the remote participator it looks like some kind of
VNC session. A direct3D application (us) in
this case sees the real local device (ATI x1900 in this case),
so we successfully initialized the Direct3D pipeline.
Performance was fine either way - with or w/o d3d
enabled. One thing though: if d3d application
is "shared" Aero is disabled on the host system for the
time the shared app is running. Any d3d app, not only us, so
it's fine I assume.
|
Java