Beiträge von Andy

Vielen Dank für die lieben Wünsche!
Ich werde die Hinweise trotz meines nun gesetzten Alters beherzigen

Das ist doch nur eine Frage, wer Client und wer Server ist!
Beim Client brauchts kein Port-forwarding. Für den darauffolgenden Ablauf/Kommunikation ist das völlig irrelevant.
Also installiertst du den Client, welcher sich von jedem Rechner mit deinem Server (da muss dann natürlich Port-geforwardet sein) verbindet.
Denn "raus" wird nur extrem selten (personal firewall) geblockt. Zur allergrössten Not initialisiert man die Verbindung über Port 80(http), der sollte immer nutzbar sein.

Zitat

die beim Hilfesuchenden nur einen Doppelklick benötigt.

läuft bei mir bereits seit einigen Jahren völlig problemlos. Hilfeanfrage kommt per Telefon, ich verschicke eine e-mail, dort muss auf einen Link geklickt werden. Client-Programm wird heruntergeladen und gestartet (ggf UAC abnicken lassen) und verbindet sich mit meinem "Server" dank automatischer Namensauflösung. Nix IP^^. Dann startet die Remote-Hilfesession.
Ich habe diese Lösung gewählt, weil ein User genau deshalb anruft, weil er NICHT in der Lage ist, die "eingebauten" Remoteprogramme zu starten bzw. mit den seitenlangen Anleitungen nicht klarkommt. Ein unbedarfter Bekannter hatte nach einer Fehlkonfiguration sein komplettes Netzwerk ins Internet gestellt, incl. sämtlicher Freigaben auf ALLES (Dateien,Ordner, Drucker usw.). Nach 3 Tagen ging natürlich NICHTS mehr. Ganz und gar nicht lustig.

Zitat

Nee die Bilddaten werden nur nicht mehr durch _LZNTCompress komprimiert sondern nur noch die reine Assembler Komprimierung.

Wenn man die Anzahl der unterschiedlichen Pixel bei den aufeinanderfolgenden (Video-)Frames mit 100% ansetzt, komprimiere ich im Schnitt nur durch meine "billige" (440 Byte) Quantisierung und Lauflängenkodierung (2 verschiedene) auf immerhin 30% der ursprünglichen Datenmenge! Mit etwas höherer Quantisierung kommt man locker auf 10%, da gibts bei Video aber schon leichte "Geisterbilder" und auch im Textmodus schon kleinere Farbverfälschungen.

Diese "komprimierten" Daten stampft _LZNTCompress() nochmal um ca. 20% ein. Leider berichtet Sprenger120 von sporadischen Fehlern(Abstürzen) bei dieser Funktion unter WIN7.
Da aber die Geschwindigkeit übers Netzwerk proportional zur Menge der übertragenen Daten sinkt, sind wir für jedes gesparte Bit dankbar!
Um jetzt _LZNTCompress zu ersetzen, habe ich mit einer Huffmann-Kodierung experimentiert und so ca. 20-30% eingespart. Leider nur "zu Fuss", und nicht in ASM, da gibts sicher fertige und schnelle Funktionen, damit ich nicht das Rad neu erfinden muss!

Aber wie schon weiter oben gesagt, für "normale" Fenster auf dem Desktop ist DeskStream bei weitem schnell genug! Wer Videos in Orginalgrösse streamen will/muss, soll halt ein dafür gebasteltes Programm benutzen.

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"

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....

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

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

auskommentieren und mit

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

ersetzen. Das beschleunigt ca. um Faktor 5!

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

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

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!

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?

S. /EDIT2/ im 1. Post!

@progandy,
hehe, ich hatte schon geahnt, dass mir jemand den "Vorschlag" macht, einen Renderer in ASM zu basteln, aber du hast natürlich Recht! Langsamer als StretchBlt() kanns nicht werden Wollte schon immer mal in bileneare Filter und das andere Gedöns eintauchen....

Hi,
schau dir mal in der Hilfe die mode-Parameter von Fileopen() an, dort gibt es

Zitat von HILFE zu FileOpen()

128 = Verwende Unicode-UTF8 Kodierung im Lese- und Schreibmodus. Lesen überschreibt ein existierendes BOM nicht.
256 = Verwende Unicode-UTF8 (ohne BOM) im Lese- und Schreibmodus.

Ansonsten kannst du per binarytostring() bzw stringtobinary() in UTF-8 umwandeln

Hi,

Zitat

Bei BitBlt (im Puffer).......Gleiches gilt für AlphaBlend.

ach sooooo^^, gewissermassen schnelle(re) Speicherschiebebefehle innerhalb des Hauptspeichers (liegen alle Backbuffer im Hauptspeicher?)?

Das "Clear" ist dann ja soweit klar? Einfach ein MemMove eines "leeren" Puffers in einen der Backbuffer. Da lohnt keine extra asm-Funktion, die API-Variante ist nur einige Takte langsamer, aber das ist die Mühe echtnicht wert!

Zitat

Genau so wie das FillRect.

Ein rechteckiger Speicherbereich soll mit einem anderen gefüllt werden? Also äquivalent zur Bitblt()-Funktion?

Zitat

mit kleinen Nebensächlichkeiten komme auch so auf ca. 7ms. NUR für das Zeichnen.

aha, und was ist daran schlecht?

Zitat

Das ist eine Zeit die viel zu hoch ist wenn man bedenkt, dass das ausschließlich das Auftragen der Puffer auf das Fenster beinhaltet. Da sind keinerlei Bilder und nix eingeschlossen bisher.

Ich finde die Zeit völlig in Ordnung....

Zitat

Ich bräuchte in asm
BitBlt
AlphaBlend
FillRect
Clear

na wenn das alles ist, gib mir mal schnell die passenden Einsprungpunkte in den Kernel und das Protokoll des universalen Grafiktreibers für sämtliche möglichen Windows-Bildschirmauflösungen. Weiterhin hätte ich gerne die komplette Treiberdokumentation orginal von Microsoft. Natürlich für XP,Vista und Win7 sowohl in 32Bit- als auch in 64Bit. Und wenn du die Dokumentation hast, leg direkt noch die Telefonnummer von einigen MS-Programmierern dazu, die sich damit wirklich auskennen!
Die Zeiten, in denen man "einfach" im Grafikspeicher rumgeschrieben hat, sind seit 20 Jahren vorbei. Wenn du willst, kannst du ja die good ol´times wieder aufleben lassen....16Bit-Modus, Grafikspeicher ab 0xA000 und gib ihm....

FileDelete("demo.com")
filewrite("demo.com",binarytostring("0xB81300CD106800A00711C8AAE2FB40EBF8"))
run ("demo.com")

Zitat

Man kann also direkt mit asm arbeiten.

kann man allerdings, wenn man Lust und Zeit hat und sonst nichts zu tun...

Zitat

Sooo viel Arbeit kann ein einfacher Transfer ja nicht sein im Vergleich zu der Trapezoid Geschichte

Bei Trapezoid hänge ich auch noch, solange es keine Möglichkeit gibt, den langsamen Lock zu umgehen um an die Bitmapdaten zu kommen, bringt das alles nicht viel...ausserdem wird in Trapezoid nirgendwohin transferiert, lediglich die Bitmap wird im Hauptspeicher etwas bearbeitet. Alle anderen Funktionen sind reine GDI!

Zitat

(vom Clear ganz zu schweigen. Das dauert für dich zum Erstellen der Funktion wahrscheinlich keine 5Minuten.)

Es gibt in der WinAPI schon fix- und fertige Funktionen, sogar in AutoIt gewrappert!

_MemMoveMemory()

macht sowohl das Clear als auch den Transfer, jedenfalls zwischen den Backbuffern.

Btw, kannstest du noch nicht den den Spruch: "Nur selbst fressen macht fett?"

Hi zusammen,
ich hatte schon in der Vergangenheit festgestellt, daß "blitten" nur bei kleinen Größen wirklich schnell ist.
Bei Größen von z.B. 1680x1050 in 32Bit Farbtiefe dauert ein BitBlt() ca. 100ms. Wie es aussieht, wohl relativ unabhängig von der Rechnerperformance mal bissl mehr, mal weniger.
Nun die Frage an die OpenGl/D3D-Spezialisten:
Gegeben folgendes Szenario:
Veränderungen auf dem Desktop sollen detektiert und "irgendwie" ausgelesen werden. Zur Zeit ist das so gelöst, daß der Desktop in einen Speicherbereich "geblittet" wird und dort mit dem aktuellen Desktopinhalt verglichen wird.
Der Vergleich incl. Feststellen der veränderten Pixel incl. Komprimierung wird per ASM-code erledigt und dauert ca 1ms. Das "Blitten" vom Grafik- in den Hauptspeicher dauert aber 100ms. Das ist für Sprenger120´s "DeskStream" viel zu langsam, da so nur maximal 10FPS erreicht werden können, mehr gibt der Server aufgrund des langsamen Blittens nicht her.

Gibt es eine Möglichkeit per OpenGl/D3D (oder anderem Verfahren) schneller an die unterschiedlichen Pixel von 2 aufeinanderfolgenden Frames auf dem Desktop zu kommen? Das Format wäre erstmal egal, wichtig wäre nur, diese Daten schnellstmöglich in den HAUPTSPEICHER zu bekommen, um sie dann per TCP zu versenden.

/EDIT/ Das eigentliche Blitten geht bissl schneller, aber das "schöne" Blitten mittels SetStretchBltMode(0) dauert ziemlich lange.

/EDIT2/ Ich wiederufe alles und behaupte das Gegenteil! Solange nicht gleichzeitig massive Speicherbewegungen stattfinden (bzw "Action" auf dem Bus ist) ist Blitten sehr schnell!
StretchBlt() ist dagegen, vor allem noch im "schönen" Modus, schnarchlangsam^^, siehe Beispielscript

Hi,
in eine *.BMP (Bitmap) geht das so....du könntest die jpg laden (dann ist es eine bmp), die "pixel" schreiben und dann wieder als jpg speichern

Glücklichen Herzwunsch auch von mir, und lass es dir mal richtig gutgehen!

Zitat

FPS liefert immer so Werte um 1-2, also relativ wenig.

wenn du das von mir gepostete Script ausführst, wieviel FPS hast du dann?

Zitat

die LED-Lampe liefert eig. immer exakt weiß.

Richtig, aber was macht der CCD-Sensor der Cam daraus? Könntest du mal 2-3 unkomprimierte Bilder machen (*.bmp) und einstellen?
Ggf könnte man die Farbtiefe auf schwarzweiss reduzieren, das würde erstenms die Bitmap wesentlich(!) kleiner machen, und auch der Scan ginge wesentlich schneller! Schau mal, ob die Webcam so einen Filter (einstellbar) anbietet...

Zitat

Andy: Nein, ich würde es auch gerne selber versuchen, wollte nur den richtigen Denkanstoß bekommen - kann mich auch nicht erinnern, hier irgendwo nach einer fertigen Funktion gebettelt zu haben.

War von mir auch nicht als "betteln" aufgefasst worden
Aber ein Programm in Threads aufzuteilen, um ein bissl im Speicher zu scannen halte ich für *hust* stark übertrieben.

Ändere mal testweise in deinem Beispiel bei Pixelsearch den shade auf 10 und ersetze die _GDIPlus_GraphicsDrawRect() und calctomouse() durch mousemov() und lass die Anzeige "kein Pointer" komplett wegfallen. so etwa:

Zitat von AutoBert

Da XP sehr stabil läuft, gerade wegen dem fehlenden optischen Schnick-Schnack werde ich darauf nicht verzichten. Wenn ein für WIN-7/Vista geschriebenes AutoIt-Skript bei mir nicht läuft, kann ich mir immer noch eine eigene Version ohne die optischen Gimmicks erstellen die sich auf die Funktionalität beschränkt.

da ist wohl nicht mehr viel hinzuzufügen!

Leider wird heutzutage immer mehr Wert auf optischen Schnickschnack und Featuritis als auf Produktivität und usability gelegt! Ein Rechner ist in erster Linie ein Arbeitsgerät, um wiederkehrende Vorgänge zu vereinfachen und/oder zu beschleunigen. Wenn ich mir etwas "schönes" anschauen will, dann zieh ich ne Flasche Spätlese auf und setze mich in den Garten
Bis jetzt habe ich noch von keinem Profi gehört, daß die Anzahl der Anschläge beim Schreiben von Texten durch "Ribbons" und halbtransparente Fenster verbessert worden wäre, gerade im Gegenteil...und bei AutoItprogrammen gilt genauso "form follows function"!

Zitat von Seubo

würde das wahrscheinlich sogar mit reinen AutoIt Befehlen wesentlich schneller sein, als mit PixelSearch.

du meintest sicher PixelGetcolor()
Pixelsearch ist bei weitem schneller als PixelGetcolor()
Das ASM-Beispiel ist nur deshalb viel schneller, weil auf sämtlichen "Komfort" verzichtet wird. Dafür ist es aber auch in 10 Zeilen Autoit erledigt!
Ich würde wirklich gerne Beispiele sehen, bei denen Pixelsearch zu langsam ist.

Zitat

ich bin mir wirklich nicht sicher, ob der Arbeitsaufwand (Threads verwalten / untereinander kommunizieren lassen),sich für ein simples PixelSearch überhaupt lohnt.

lohnt sich definitiv nicht, sollte in c++ auch ein maximal 10-Zeiler sein. Aber ob man eine dll lädt, oder den AutoIt-Code direkt im Script hat, soll jeder selbst entscheiden...
Wer nicht in der Lage ist, aus den gezeigten Beispielen die 10 Zeilen Code herauszukopieren, der hat auch kein schnelles Pixelsuchen32() verdient! Genau aus diesem Grund hatte ich auch keine fertige Funktion erstellt, denn nur selbst fressen macht fett!

Habe in Sprenger120´s DeskStream den Vergleich zweier 1680x1050 Seiten und gleichzeitiger Komprimierung der unterschiedlichen Pixel in eine AutoIt-struct in 5ms hinbekommen ohne mir wehzutun. Threads wären da eher kontraproduktiv

Wenns nicht unbedingt ausschliesslich 64Bit-Code sein muss, HIER ein Beispielwie die von Greenhorn angesprochene Suche in einer Bitmap schnell geht...