Remote Desktop Demo doesn’t work if it is compiled in kbmMW 5_14, 5_15

[VadimMest]

Hello

The Remote Desktop Demo doesn’t work if it is compiled in kbmMW 5_14, 5_15 and it works if it is compiled in 5_13_10. There seems to be a problem with FScreenLock.BeginWrite.

Did someone is able to collect this project?

Thanks
Vadim Mescheryakov

 

 

[Babis Michael]

Nope it doesn’t work on me either with the latest version. (No screen)

[Babis Michael]

Kim ?

The client connects but it doesn’t display anything!

[kimbomadsen]

Grr…. it is a problem due to the use of TBitmap in threads.

It has always been somewhat scary to use TBitmap in a multithreaded environment. But it usually worked, when one remembered to lock the canvas before use.

However I think something has changed in the locking mechanism, since TBitmap.Canvas.Lock quite often ends up in a deadlock situation. As I remember, it did not do that with an earlier Delphi compiler.

Anyway…. it has resulted in almost 3 days and nights without much sleep, adding a new kbmMWDIB.pas unit, and completely dropping the use of TBitmap on the server side.

The good thing is that the new TkbmMWDIB bitmap class is much faster for what we use it for, because it does not contain any fluff like TBitmap and TCanvas, and specifically it does not require locking to operate in its own thread.

In addition I have changed the transport on the server from Indy to our own native IOCP transport, because it scales vastly better and performs very well.

All changes in the release being prepped right now!

/Kim

[Babis Michael]

Love you!

[Babis Michael]

Changing to capture mode DirectX freezes server!

[kimbomadsen]

Hi,

I do not see server freezing in my setup, but I do see it no longer grabbing screenshots.
In my case it is because the DirectX stuff is running out of resources of some reason (code 0x80070057).

One reason could  be that my screen is 5120×2500.

Switching back to GDI makes it capture fine again without problems.

If indeed your server freezes, it is most likely due to problems with the DirectX GPU drivers.

/Kim

[Babis Michael]

Rtx 3090 with latest drivers, 4k monitor and windows 11! You’ll notice that the server application will be busy (can’t do anything) when you switch to DirectX mode.

• This reply was modified 3 years, 1 month ago by Babis Michael.

[kimbomadsen]

Hi,

Problem is that I do not see a server unresponsive situation. In fact the server continues fine, but no screens are forwarded in my case and I can switch on the fly to GDI.

I’m running on dual Titan V cards.

So it will probably need some debugging on your specific setup to figure out where it hangs.

/Kim

[Babis Michael]

Found the problem it’s on the below line but i don’t know how to resolve the AV or Stack Overflow.
Maybe the map is still locked or something and can’t let it copy the bytes to DIB ?

function TkbmMWRemoteDesktopServer.GetScreenDXGI ….

…
ABmp.DrawData(map.pBits); //AV Here
….

Thank you

[Babis Michael]

Due my experiments replaced the Move with CopyMemory and it works although it copies the 2nd monitor instead of the 1st.

So the problem is when you have a 4k Monitor and a 2nd 1080p monitor and switch to DirectX.
Seems it grabs the wrong monitor for the buffer or the opposite.

Thank you

[Babis Michael]

Seems their is problem multi monitor environments eg. it doesn’t register monitor 1/primary. the FMonitors[0] value is nil while FMonitors[1]  (monitor 2) is mdwn_2.

Changed this line in order to work:

constructor TkbmMWRemoteDesktopClient.Create(AOwner:TComponent);

{$IFDEF FMX}
FID:=TkbmMWRemoteDesktopMonitor.mwrdm_1;
{$ELSE}
// Original: FID:=TkbmMWRemoteDesktopMonitor(Screen.PrimaryMonitor.MonitorNum)

FID:=TkbmMWRemoteDesktopMonitor(Screen.PrimaryMonitor.MonitorNum -1);

Testing ….

• This reply was modified 2 years, 11 months ago by Babis Michael.

[Babis Michael]

Ok i found the issue … DXGI needs the monitor array backwards!

according to chromium sources:

dxgi_adapter_duplicator.cc
duplicators_.push_back(std::move(duplicator));

• This reply was modified 2 years, 11 months ago by Babis Michael.

[kimbomadsen]

Well CopyMemory does internally use Move and nothing else.

But the problem most likely is that DrawData should be changed to:

procedure TkbmMWDIB.DrawData(const ASourceData:pointer);
begin
if ASourceData<>nil then
Move(ASourceData^,FData^,FBytes);
end;

Regarding order of monitors.

According to the Win32 docs, then EnumAdapters1 will first return the adapter holding the primary monitor (index 0).

On that adapter, EnumOutputs will first return the output that is connected to the primary monitor (again index 0).

So there should be no reversal in the way that kbmMW remote server DXGI retrieves monitors as far as I can see.

/Kim

[Author]

Posts