DeskStream 2 Release Candidate 1.8

**Sprenger120**

Hi,
Hmm ich hab die Funktion mal minimal verändert und das hat bereits zu Fehlern bzw. Hardcrash's geführt.

Spoiler anzeigen

[autoit]

Func _LZNTCompress($vInput, $iCompressionFormatAndEngine = 2)

[/autoit] [autoit][/autoit] [autoit]

If Not ($iCompressionFormatAndEngine = 258) Then
$iCompressionFormatAndEngine = 2
EndIf

[/autoit] [autoit][/autoit] [autoit]

Local $bBinary = Binary($vInput)

[/autoit] [autoit][/autoit] [autoit]

Local Static $tInput = DllStructCreate("byte[" & $iWidth * $iHeight & "]")
DllStructSetData($tInput, 1, $bBinary)

[/autoit] [autoit][/autoit] [autoit]

Local $a_Call = DllCall("ntdll.dll", "int", "RtlGetCompressionWorkSpaceSize", _
"ushort", $iCompressionFormatAndEngine, _
"dword*", 0, _
"dword*", 0)

[/autoit] [autoit][/autoit] [autoit]

If @error Or $a_Call[0] Then
Return SetError(1, 0, "") ; error determining workspace buffer size
EndIf

[/autoit] [autoit][/autoit] [autoit]

Local Static $tWorkSpace = DllStructCreate("byte[" & $a_Call[2] & "]") ; workspace is needed for compression
Local $tBuffer = DllStructCreate("byte[" & 16 * DllStructGetSize($tInput) & "]") ; initially oversizing buffer

[/autoit] [autoit][/autoit] [autoit]

Local $a_Call = DllCall("ntdll.dll", "int", "RtlCompressBuffer", _
"ushort", $iCompressionFormatAndEngine, _
"ptr", DllStructGetPtr($tInput), _
"dword", DllStructGetSize($tInput), _
"ptr", DllStructGetPtr($tBuffer), _
"dword", DllStructGetSize($tBuffer), _
"dword", 4096, _
"dword*", 0, _
"ptr", DllStructGetPtr($tWorkSpace))

[/autoit] [autoit][/autoit] [autoit]

If @error Or $a_Call[0] Then
Return SetError(2, 0, "") ; error compressing
EndIf

[/autoit] [autoit][/autoit] [autoit]

Local $tOutput = DllStructCreate("byte[" & $a_Call[7] & "]", DllStructGetPtr($tBuffer))

[/autoit] [autoit][/autoit] [autoit]

Return SetError(0, 0, DllStructGetData($tOutput, 1))
EndFunc ;==>_LZNTCompress

[/autoit]

Was ich mitbekommen hab ist das Workspace immer gleich bleibt und daher Static bleiben kann. Jedoch ändern sich alle anderen Werte...

//Edit: Das problem mit dem Hardcrash des Clients besteht immernoch... Ich hatte bereits versucht beim Server immer die DC des Desktops bzw. des Fensters, das gerade im Vollbildmodus ist, zu nehmen aber es ist immer das gleiche.

**Sprenger120**

Soo nach langer Zeit mal wieder ein Update. Es hat sich sehr viel getan. Die vielen PM's und Stunden im IRC haben sich also gelohnt.

~~Update 1.0 RC~~
-Komprimierung der Bildaten
-Client Crasht nicht mehr bei Vollbildanwendungen
-Bei Übertragungsfehlern wird der 'Müll' aus dem Puffer entfernt und ein neuer Frame Angefordert
-Einstarung an Structs und an Speicherbewegung
-Neues Menü beim Client

Auswahl der Gewünschten GUI Größe und somit der gesendeten Auflösung
HQ Modus

-Sämtliche Einstellungen sowie IP und Port der letzten erfolgreichen Verbindungen werden jetzt gespeichert
-Stabilität erhöht durch Prüfung des Pixel Offsets

Viel Spaß damit

**Andy**

Es bleibt noch ein wenig zu tun^^

Todo:
Mausklicks in das Clientfenster sollen an den Server "durchgereicht" werden => Fernsteuerung des Servers
Zoomen per Mausrad und Verschieben (Pan-Modus) per rechter Maustaste.

Technische Verbesserungen:
Weitere Minimierung der Cache-Misses, das hat auch mit dem Speicherverbrauch zu tun.
Eigener Stretchblt()-Algorithmus, mal schauen welcher Filter ordentliche Ergebnisse bringt und trotzdem einfach zu implementieren ist....Ideen?

**UEZ**

Klasse Arbeit!

Gefällt mir sehr gut!

Wenn man noch die Bildqualität erhöhen könnte, wäre das echt super!

Gruß,
UEZ

**Raupi**

Hi, Sprenger120 und Andy.

Finde das Script super aber irgendwie ist das ganze noch verbugt.
autoit.de/wcf/attachment/12419/

Wenn ich auf dem Server ein Fenster bewege kommt es beim Client zu Pixelfehler.
Irgendwie wird der Hintergrund an manchen Stellen in der falschen Farbe gezeichnet.
Der Server läuft auf WinXP Sp3 und der Client auf Win7 64. Im umgekehrten Fall sind die selben Fehler zu sehen.

Edit: Komischerweise passieren die Pixelfehler nur bei ganz hellen Hintergründen.
Wenn ich den Client strarte wird kein Bild angezeigt, solange sich auf dem Serverrechner nichts ändert.
Solle beim Start nicht 1 mal das ganze Bild übermittelt werden?

UEZ, vom Clientfenster kann ich mit deinem Screenshooter kein Bild machen. Bis auf die Titelzeile ist der Screenshoot leer.
MIt dem Snipet Tool funzt es aber, siehe Bild oben.

**UEZ**

Zitat

UEZ, vom Clientfenster kann ich mit deinem Screenshooter kein Bild machen. Bis auf die Titelzeile ist der Screenshoot leer.
MIt dem Snipet Tool funzt es aber, siehe Bild oben.

Das hat leider mit der Funktion: DllCall("User32.dll", "int", "PrintWindow", "hwnd", $hWnd, "handle", $hMemDC, "int", 0) zu tun. Ich kenne leider keine andere Funktion, die von verdeckten Fenstern ein Screenshot machen kann. Ferner funzt das Ganze auch nicht mit GDI+ Fenstern richtig!
Wenn du auch die "Grab Screen" Funktion nimmst, kannst du das Fenster manuell "grabben" oder F11/F12 als Fullscreen Screenshot.

Wenn du als Pixelfehler die "Streifen" auf hellem Hintergrund meinst, dann sehe ich sie auch, aber das ist nicht so schlimm.

Gruß,
UEZ

**Raupi**

Zitat

Wenn du als Pixelfehler die "Streifen" auf hellem Hintergrund meinst, dann sehe ich sie auch, aber das ist nicht so schlimm.

Ja,das meinte ich. Mich stört es auch nicht sehr, aber Fehler sollte man doch melden.
Ich bin immer froh wenn mir jemand sagt, wenn etwa nicht funzt. Das ist besser, als wenn keiner was sagt
und einem die Fehler erst nach Wochen selbst auffallen. Bugsuche ist geil, bei uns werden sie wenigstens gefixt
wenn möglich und nicht wie bei Miniweich unter den Teppich gekehrt.

**Sprenger120**

Hi Rapui,
das liegt an RtlGetCompressionWorkSpaceSize. Das gibt einen zu kleinen Wert zurück und dann wird nicht richtig Dekomprimiert.
Daher kommen diese Pixel fehler.
In der nächsten Version werde ich das beheben.

UEZ: Inwiefern erhöhen ? Client->Erweitert->Haken bei HQ-Modus und ggf. die Auflösung anpassen damit es nicht so gequetscht ist.

**UEZ**

Ich dachte da eher an eine Funktion wie _GDIPlus_GraphicsSetInterpolationMode() bei GDI+, wo du 8 Stufen für die Qualität hat. Da ihr hier mit GDI+ nichts macht, weiß ich nicht, ob man das zusätzlich noch einbauen kann.

Gruß,
UEZ

**Sprenger120**

Hi UEZ,
Hmm ja gute Frage... Aber eigentlich ist es unnötig. Wenn du den HQ Modus anmachst und die Fenstergröße auf die des Servers einstellst dann ist die Bild Quali 1:1.

//Edit: Sie ist fast 1:1 denn es werden 1-2 Bits von der Farbe weggeschnitten.

**Andy**

Hi,

Zitat

Wenn du als Pixelfehler die "Streifen" auf hellem Hintergrund meinst, dann sehe ich sie auch, aber das ist nicht so schlimm.

It´s not a bug, it´s a feature
Naja, wenigstens fast....diese "hellen Streifen" kommen von der Reduzierung von 32Bit-Farbtiefe auf 16 zu übertragende Bit pro Farbe.
Weiterhin werden werden alle folgenden Pixel, bei denen je Farbkanal die obersten 5 Bit identisch mit dem "Startpixel" sind, als "gleichfarbig" betrachtet. Das führt bei horizontalen Farbverläufen z.B. im Fenstertitel, zu gleichfarbigen Feldern im Client.

Zitat

Aber eigentlich ist es unnötig. Wenn du den HQ Modus anmachst und die Fenstergröße auf die des Servers einstellst dann ist die Bild Quali 1:1.

Wenn man 1:1 überträgt, d.h. die Clientfenstergrösse ist gleich der Bildschirmgrösse des Servers, braucht man den HQ-Modus nicht...
@Sprenger, da solltest du einbauen, dass BitBlt() statt StretchBlt() verwendet wird, ist etwas schneller!

Raupi ,
das erste Frame wird immer übertragen, hab leider nur XP-Maschinen zum Testen, da kommt das erste Frame auch immer an, auch wenn der Server danach nichts sendet.
@Sprenger, man sollte einbauen, dass man per Hotkey einen komplett neuen Frame anfordern kann.

UEZ,
unser "HQ"-Modus verursacht durch

[autoit]

$Ret = DllCall("gdi32.dll", "int", "SetStretchBltMode", "dword", $hBitmapDC_source, "int", 4)

[/autoit]

macht schon ein recht ansehnliches(verkleinertes) Bild. Jedenfalls ist es bei weitem besser als ein "normales" stretchblt. Aber dafür auch 4-5x langsamer^^
Daher habe ich mich entschlossen, 1:1 (sehr schnell) in einen Puffer zu blitten und dann z.B. per Lanczos-Filter in ASM zu skalieren. Das würde nochmal richtig Schub beim Server bringen. Wenn ich dann auch noch die Komprimierung weiter verbessere, könnte man auch die _LZNTCompress()-Funktion weglassen, denn die bringt sowieso nur 10-20% an Grösse, verbraucht aber 30-40x die Zeit des ASM-Codes!

Es gibt noch reichlich zu tun, vielen Dank jedenfalls für die Tests und das Feedback!

**Andy**

Kurzer Tip zwischendurch!
Wer den Server-Desktop 1:1 in den Client weiterreichen möchte, sollte im Server die Zeile 130

[autoit]

_WinAPI_StretchBlt($DCnew, 0, 0, $iWidth, $iHeight, $hDesktopDC, 0, 0, @DesktopWidth, @DesktopHeight, $SRCCOPY)

[/autoit]

auskommentieren und mit

[autoit]

_WinAPI_bitBlt($DCnew, 0, 0, $iWidth, $iHeight, $hDesktopDC, 0, 0, $SRCCOPY)

[/autoit]

ersetzen. Das beschleunigt ca. um Faktor 5!

**Sprenger120**

Zitat von Andy

Daher habe ich mich entschlossen, 1:1 (sehr schnell) in einen Puffer zu blitten und dann z.B. per Lanczos-Filter in ASM zu skalieren.

Das wusste ich noch gar nicht . Gib alles

Zitat von Andy

@Sprenger, man sollte einbauen, dass man per Hotkey einen komplett neuen Frame anfordern kann.

->Todo

Zitat von Andy

@Sprenger, da solltest du einbauen, dass BitBlt() statt StretchBlt() verwendet wird, ist etwas schneller!

Hmm. Jetzt beim Server oder wie ?. Aber eigentlich hat sich das denn wegen dem Filter.

**Andy**

Zitat

Hmm. Jetzt beim Server oder wie ?. Aber eigentlich hat sich das denn wegen dem Filter.

Eigentlich nicht, den stretchblt() ist imho langsamer als bitblt(), auch ohne "stretch". Daher meine Intention, auf dem Client ein kleines Fenster einzustellen und ggf.Teile des (Server)Bildschirms per Mausrad zu vergrössern und zu verschieben, so dass man die schnelle 1:1 Übertragung des "wichtigen" Bildschirmteils erreicht!

Zitat

Daher habe ich mich entschlossen, 1:1 (sehr schnell) in einen Puffer zu blitten und dann z.B. per Lanczos-Filter in ASM zu skalieren.

Es gibt ja hier im Forum glücklicherweise Spezialisten zu diesem Thema, die man auch mal Fragen kann! Wenn es fertige Funktionen gibt, um so besser....

MatthiasG.

Hey!

Super-Projekt - wirklich!

Ich würde es gerne als Teamviewerersatz nehmen. Denn hier reicht es das Skript auszuführen und es läuft (als exe). Bei sehr "dummen" Leuten braucht man etwas simpleres als TV: Dein Skript!

Ich würde mich über die Maussynchronisation freuen - schau dir vielleicht Synergy+ an?

Des weiteren wäre es toll, wenn der Server beim Start auf Wunsch die UAC deaktiviert, damit die Sitzung dadurch nicht unterbrochen wird.

Gruß,
Matthias

Lesato

Zitat

Unterm Strich macht das rund 25FPS. Mann kann also bequem Filme gucken

Ich hab mal versucht per VLC oder MediaPlayer unter WinXP einen Film anzuschauen, aber ausser einem schwarzen
Fenster bekomm ich nix zu sehen.Ich geh mal davon aus das es das Gleiche Problem sein dürfte warum man auch
keinen Screenshot vom VLC machen kann.

cu, Lesato!

**Sprenger120**

Hi,
das liegt daran das VLC nicht auf den Desktop zeichnet wie z.B. GDI+ sondern direkt über die Grafikkarte ausgeben lässt. Für Windows ist das nur ein schwarzes Fenster weil es nicht mitbekommt was über die Graka ausgegeben wird.

progandy

Zitat von Sprenger120

Hi,
das liegt daran das VLC nicht auf den Desktop zeichnet wie z.B. GDI+ sondern direkt über die Grafikkarte ausgeben lässt. Für Windows ist das nur ein schwarzes Fenster weil es nicht mitbekommt was über die Graka ausgegeben wird.

Den VLC kann man übrigens auf Windows-GDI Ausgabe stellen. (Einstellungen -> Video -> Asugabe)

**Sprenger120**

In der nächsten Version werden wir höchstwarscheinlich _LZNTDecompress bzw. _LZNTCompress rausnehmen weil es einfach zu viele Cashe Misses gibt (100k pro Bild FTW!). Außerdem Sparen wir dadurch 2 Structs und es muss weniger Speicher bewegt werden was den Bus entlastet.
Und diese ewigen C0000242 Erros kann sich keiner Erklären. Selbst als ich 100mb Puffer gegeben hat kam er :wacko:

**Andy**

Zitat

In der nächsten Version werden wir höchstwarscheinlich _LZNTDecompress bzw. _LZNTCompress rausnehmen

sicher sogar...hab die Kompression im asm-code nun etwas forciert, da holt _LZNTCompress nur noch 5% raus, das lohnt nicht. Jedenfalls nicht, wenn man sieht, was diese Funktion im (und mit dem) Speicher veranstaltet.
Weiterhin werden nun rechte und linke Mausklicks ins Clientfenster an den Server "durchgereicht". Volle Fernsteuerung also.

Zitat

Unterm Strich macht das rund 25FPS. Mann kann also bequem Filme gucken

das ist natürlich nur im Bereich von ca. 500x400 Pixeln oder kleiner möglich! Und auch dann nur im "Videomodus" , d.h. bei starker Kompression, interlaced und einem fetten Rechner auf Serverseite und ebenso "fettem" Netzwerk. Wobei zzt. die Leistung auf Serverseite der limitierende Faktor ist. Selbst mein 10MBit-Netzwerk ist "nur" zu 20%-30% ausgelastet. Wobei die Frage ist, wieso man dann keine Videostream-Software benutzt, die überträgt dann auch Ton

Aber mittlerweile ist es so wie bei jeder anderen Optimierung auch. Der Punkt ist erreicht, wo man nur noch mit grossem Aufwand relativ wenig Mehrnutzen bekommt. Jetzt nioch bissl Usability verbessern und der DeskStream ist wirklich "rund"