4. Lösungsvorschläge | Client-Server | Desktop übertragen

Lösungsvorschläge | Client-Server | Desktop übertragen

  • B

    huhu,

    ich möchte eine Socket-Anwendung schreiben wo der Server-Desktop
    zum Client gesendet und dort ausgegeben wird.

    meine fragen:
    - wie kann ich den Server-Desktop inkrementell auslesen? jedes pixel einzelnd und auf veränderungen vergleichen?
    - wie kann ich es über "send(...);" am bestem zum Client schicken?

    wäre euch für lösungsvorschläge sehr dankbar 🙂

    0
  • C

    babelduo schrieb:

    - wie kann ich den Server-Desktop inkrementell auslesen? jedes pixel einzelnd und auf veränderungen vergleichen?

    Deine Leitung wird Dir zwar explodieren oder dein Prozessor Dich erschlagen, aber:
    GetDesktopWindow, bzw GetDC(NULL) und GetPixel...Farbwerte sind einfache Integer-Werte; wie man die vergleicht sollte klar sein :p .

    babelduo schrieb:

    - wie kann ich es über "send(...);" am bestem zum Client schicken?

    Entweder Du schickst die gesamte Bitmap(-Datei), was aber eigentlich relativ resourcen-fressend ist, auf Dauer. Eine andere (sinnvollere) Möglichkeit wäre es, nur den differenten Teil zu verschicken 😉 .

    0
  • ?

    CodeFinder schrieb:

    Eine andere (sinnvollere) Möglichkeit wäre es, nur den differenten Teil zu verschicken 😉 .

    Ich glaube darum will er vergleichen 💡

    0
  • ?

    ja genau ich möchte ja nur die veränderten sachen schicken!

    ich gucke also beim Server in einem bestimmten intervall ob sich etwas verändert
    hat und schicke die veränderungen... aber wie am besten?

    mein lösungsvorschlag wäre nun:

    10;100;farbwert

    den string kann man ja beim Client leicht wieder in die einzelteile
    per strtok teilen!

    das heißt das sich das pixel verändert hat
    (10te reihe von oben, 100pixel von links)

    natürlich würde ich mehrere veränderungen hintereinander schicken.

    10;100;farbwert;526;10;farbwert;701;846;farbwert;900;100;farbwert;

    (die veränderungen der pixel sind zwar eher nicht realitätsnah da sie weit auseinander liegen aber ihr wisst was ich meine ;))

    hättet ihr noch vorschläge zur optimierung?

    0
  • C

    hättet ihr noch vorschläge zur optimierung?

    Jo^^.

    struct SPixelUpdate
{
   short sX; // X-Koordinate
   short sY; // X-Koordinate
   unsigned int uiNewClr; // Neuer Farbwert
};

    Vorteile: Geringerer Speicherverbrauch und einfachere Handhabung 😉

    0
  • ?

    hey danke schonmal 🙂

    ich habe schon mit strukturen gearbeitet - allerdings habe ich noch
    keine struktur über "send(...);" gesendet und mit "recv(...);" wieder
    ausgelesen!

    wie kann ich das denn handeln?

    0
  • C

    babelduo (net eingeloggt) schrieb:

    wie kann ich das denn handeln?

    In etwa so:

    SPixelUpdate pixData;
pixData.sX       = 45;
pixData.sY       = 569;
pixData.uiNewClr = RGB(0,0,0);
int iRet = send(skDest, reinterpret_cast<char*>(&pixData), sizeof(pixData), WSA...);

    PS: Du musst mal darauf achten, das es keinen Overflow wegen den Koordinaten in Bezug auf den Datentyp short gibt - könnte doch etwas zu klein sein.

    0
  • C

    Mir ist grad noch eingefallen:
    Du könntest vllt auch ein Pixelfeld zur Aktualisierung 'markieren'.
    Das ließe sich beispielsweise mit nem std::vector (STL, C++) und einem
    Anfangskoordinatenpunkt und einem Endkoordinatenpunkt 😉 .
    Damit kann man noch den aufkommenden Transfer-Speicher reduzieren.

    EDIT: Vertipper 😉 .

    0
  • N

    CodeFinder schrieb:

    ...und GetPixel...

    bist du verrückt 😮 das killt die stärkste maschine.

    besser (usermode): mit 'CreateDibSection' eine solche anlegen und dann mit
    BitBlt den ganzen desktop da rein. auf die daten in der disbsection kann man dann ganz normal über pointer zugreifen, alles komprimieren und abschicken.

    noch besser: einen mirror driver basteln: http://msdn2.microsoft.com/en-us/library/ms797878.aspx

    0
  • C

    net schrieb:

    CodeFinder schrieb:

    ...und GetPixel...

    bist du verrückt 😮 das killt die stärkste maschine.

    😃 😃

    Muahaha ich sag ja: Sprengt jede Maschine... 😃 😃 ...

    Aber hast Recht, mit ner DIB-Section ist das besser 😉 .

    0
  • B

    hmm ja, jedes pixel auszulesen verbraucht wirklich ein par viele
    ressourcen 🙂

    ich habe hier nun mal ein beispiel wo ein Screenshot gemacht wird und
    "CreateDIBSection()" angewendet wird:

    HDC hdc, hdc2;
hdc=GetDC(NULL);
hdc2=CreateCompatibleDC(hdc);
HBITMAP aBmp; 
BITMAPINFO bi; 
HGDIOBJ OldObj; 
void *dibvalues; 
HANDLE fileHandle; 
BITMAPFILEHEADER bmfh; 
BITMAPINFOHEADER bmih; 
DWORD bytes_write; 
DWORD bytes_written; 
ZeroMemory(&bmih,sizeof(BITMAPINFOHEADER));

int width_s=800;
int height_s=600;

int width=width_s;
int height=height_s;

bmih.biSize=sizeof(BITMAPINFOHEADER); 
bmih.biHeight=height; 
bmih.biWidth=width; 
bmih.biPlanes=1; 
bmih.biBitCount=16; 
bmih.biCompression=BI_RGB; 
bmih.biSizeImage = ((((bmih.biWidth * bmih.biBitCount) + 31) & ~31) >> 3) * bmih.biHeight; 
bmih.biXPelsPerMeter = 0; 
bmih.biYPelsPerMeter = 0; 
bmih.biClrImportant = 0; 
bi.bmiHeader=bmih; 

aBmp=[b]CreateDIBSection[/b](hdc,&bi,DIB_RGB_COLORS,(void**)&dibvalues,NULL,NULL); 

if (aBmp==NULL) 
{ 
return 0;
} 

OldObj=SelectObject(hdc2,aBmp);

//BitBlt(hdc2,0,0,width,height,hdc,0,0,SRCCOPY);
StretchBlt(hdc2,0,0,width_s,height_s,hdc,0,0,GetSystemMetrics(SM_CXSCREEN),GetSystemMetrics(SM_CYSCREEN),SRCCOPY);

    ich benutze StretchBlt anstatt BitBlt da ich so die Möglichkeit habe das Bild auf (hier) 800x600 zu schrumpfen und somit schon vor dem senden zu verkleinern.

    aber wie gehts nun weiter? nun "meine" methode anwenden und bei hdc2 jedes
    pixel auslesen und per strukt versenden?

    meintet ihr das so?

    danke schonmal 🙂

    0
  • N

    babelduo schrieb:

    aber wie gehts nun weiter? nun "meine" methode anwenden und bei hdc2 jedes
    pixel auslesen und per strukt versenden?

    na fast. der trick bei den dibsections ist ja, das man für weitere aktionen das 'hdc' graffel nicht mehr braucht. dein pointer 'dibvalues' zeigt dann auf die pixeldaten (bei 'nem 16bit/pixel rgb format, jeweils 5 bits, eins ist unbenutzt). die daten kannste direkt durch 'nen kompressor jagen und dann senden (ich glaub' das bild steht auf dem kopf, aber das sollte nicht das problem sein).

    btw: jedesmal das ganze bild zu senden ist aber auch nicht der weisheit letzter schuss 😉

    0
  • B

    @net
    nein ich wollte ja eig. auch immer nur die inkrementellen sachen verschicken -
    halt was sich geändert hat.
    mit GetPixel hätte ich halt jedes pixel ausgelesen und geguckt ob sich etwas
    verändert hat.

    0
  • J

    GetPixel kannst Du vergessen. Da wird Dein vergleich vermutlich erst morgen Fertig...
    Hol Dir das ganze Bitmap und greife dann direkt auf das kopierte Bitmap zu. Nur so ist es performant (Du musst dann halt die Farbtiefe beachten, damit Du den koorekten Offset berechnest).

    0
  • N

    Jochen Kalmbach schrieb:

    GetPixel kannst Du vergessen. Da wird Dein vergleich vermutlich erst morgen Fertig...

    das wissen wir schon seit der ersten seite 😉

    0
  • J

    net schrieb:

    Jochen Kalmbach schrieb:

    GetPixel kannst Du vergessen. Da wird Dein vergleich vermutlich erst morgen Fertig...

    das wissen wir schon seit der ersten seite 😉

    Aber es scheint so als ob es beim OP immer noch nicht angekommen ist... oder schwelgt er in alten Zeiten?

    0
  • N

    ach, noch was zur geschwindigkeit: der speed des 'BitBlt' in eine dibsection ist stark von dem passenenden BITMAPINFOHEADER und der grafikhardware abhängig. bei mir waren immer 16bits/pixel das schnellste. bei inkompatiblen formaten muss windows alles umrechnen. das kostet nochmals viel zeit...

    0
  • J

    net schrieb:

    bei inkompatiblen formaten muss windows alles umrechnen. das kostet nochmals viel zeit...

    Ja, aus diesem Grunde immer das *gleiche* Format verwenden, dann entspricht die Geschwindigkeit des BitBlt ungefähr einem memcpy 😉

    0
  • B

    @Jochen Kalmbach
    nene die alten zeiten hab ich abgelegt... hoffe ich^^

    also ich arbeitete mich gerade auch erst ein wenig ein - hab mit
    CreateDIBSection() noch net gearbeitet.
    aber ich kann nun so auf die pixel zugreifen:

    for(int i = 0; i < height_s * width_s * 3; i += 3)
    {
    // R G B
    printf("%i_%i_%i ", dibvalues[i+2], dibvalues[i+1], dibvalues[i]);
    }

    meint ihr das so? das ich hier die farben der pixel vergleiche und nur
    die veränderten sende?

    danke euch aber schonmal 🙂 !

    0
  • N

    babelduo schrieb:

    for(int i = 0; i < height_s * width_s * 3; i += 3)
    {
    // R G B
    printf("%i_%i_%i ", dibvalues[i+2], dibvalues[i+1], dibvalues[i]);
    }

    ja, so ähnlich. du musst 'dibvalues', der ja ein void* ist, für so'ne schleife in den richtigen typ umwandeln. bei 24 und 32 bits/pixel muss es ein DWORD sein und bei 16bits/pixel ein WORD.

    babelduo schrieb:

    meint ihr das so? das ich hier die farben der pixel vergleiche und nur
    die veränderten sende?

    naja, das vergleichen und senden ist ein anderes thema. man kann z.b. den screen in kleine, rechteckige bereiche 'kacheln'. wenn man eine änderung festgestellt hat, schickt man die entsprechende 'kachel'. kacheln mit gleichem inhalt (z.b. einfarbiger desktophintergrund) braucht man nur einmal zu schicken und danach nur deren 'kachelnummer' und position.
    vielleicht schauste dir mal an, wie vnc sowas macht:
    http://grox.net/doc/apps/vnc/howitworks.html

    0
  • ?

    ja ok!
    also das mit dem nachschauen und nur dem verändertem senden kann ich ja
    dann machen da schaue ich mal...

    aber wie genau ist das mit dem umwandeln gemeint?

    WORD* test;
test=(WORD*)dibvalues;

for(int i = 0; i < height_s * width_s * 3; i += 3)
{

	printf("%i_%i_%i ", test[i+2], test[i+1], test[i]);
}

    ?

    da kommen dann farbwerte raus die so ausschauen:

    31875_39312_65535
0_812_0
87_46_116
454_47482_43851

    naja und wenn ich den ganzen desktop (bei mir 1280x1024) nehme
    sürtzt mein programm ab wegen eines laufzeitfehlers!

    wenn ich mittels StretchBlt(...) auf 100x100 "schrumpfe"
    läuft er wenigstens ohne laufzeitfehler durch 😉

    ich nehme an das liegt an der pointer-konvertierung?

    0
Anmelden zum Antworten