Assistenza remota simil Team Viewer

[DragoRosso]

Si, risolvi impostando a DPI Aware Per Monitor V2 in opzioni progetto.

Ciao

[xinyiman]

Grazie mille DragoRosso. Partendo da qui ora estraggo le immagini riga per riga per fare il confronto. Ti tengo aggiornato

[xinyiman]

Provate questa versione, dovrebbe essere abbastanza intuitiva. Premete prima i fue pulsanti in alto e poi esplorate le 3 tab. Se non è chiaro come funziona basta chiedere.

[Stilgar]

hihihi,
Ma farvi un repo git privato?


Stilgar

[DragoRosso]

hihihi,
Ma farvi un repo git privato?
Stilgar

Ma no, lavoriamo in pubblico.

[Stilgar]

Allora un repo pubblico

[nomorelogic]

in mancanza di un repo pubblico...
ho fatto un programmino per testare le differenze tra le immagini

ho messo un algoritmo di confronto, chi vuole può aggiungerne altri così da confrontare i tempi

[DragoRosso]

In attesa di un repository pubblico, per ora uno privato.

https://github.com/SiveaITA/KrogRD

Verrà convertito in pubblico al momento in cui ci saranno degli sviluppi proponibili pubblicamente.
Per ora siamo ancora in fase embrionale.

Mandatemi un messaggio privato con il nome di account di GITHUB affinchè vi dia accesso al repo.

Può partecipare chiunque sia interessato a proporre / testare soluzioni.

Ciao

[DragoRosso]

Ai fini Linux, abbiamo visto che due sistemi grafici (server grafici) vengono usati prevalentemente:

1) X11
2) Wayland

Mentre X11 è stato da sempre il server "de facto" di Linux, il recente Wayland è stato adottato ufficialmente da Ubuntu nella versione 22.04 (e già adottao sia da Debian che da Fedora).

Sotto X11 non c'è granchè da dire, il supporto è ormai standardizzato e tutti i pacchetti grafici di interfaccia (GTK, QT, etc..) girano tranquillamente; in Wayland ci sono ancora alcuni problemi di incompatibilità, spesso dovuta alla vetustà delle applicazioni, ad esempio il mantenimento di GTK2 (deprecata), passando per GTK3 quando GTK4 viene già normalmente usata.

Poi ci sono ulteriori problematiche dovute alle implementazioni di sicurezza che in Wayland sono native (banalmente, ma non è la sola, lo screenshoot del desktop che non è fattibile da una normale applicazione senza appunto avere acquisito una apposito "token" dal server Wayland).

Anche QT5, sembra non sia pienamente compatibile ed è stata "moddata" una versione apposta per Wayland.
Lo cose si stanno muovendo molto rapidamente, quindi in attesa di tempi più stabili proporrei che per adesso si ignori Wayland e si continui a perseguire la strada standard di X11.

Dalle prove effettuate, appare chiaro che Lazarus produca (sia per GTK2, sia per QT5) applicazioni perfettamente standard e che funzionano correttamente sotto X11 anche in varie versioni di Linux. Così non è in Wayland dove le applicazioni prodotte hanno dei limiti (ma non per colpa di Lazarus) anche se marginali (però sono propri quelli che incidono nel progetto KRD).

Direi alla fine fine di posporre le attività di test e verifica su Wayland in attesa di una stabilizzazione (per inciso, in Virtual Box con Wayland ci sono diversi problemi, così come in Lazarus già nell'IDE grafico, però magari è un limite dell'ambiente Virtual Box).

Creerò nel repository una sezione Waylnad dove "accumulare" eventuali materiali da studiare / verificare / testare successivamente.

Per chi usasse Ubuntu 22.04, passare a X11 è semplicissimo, e ciò fà capire quanto l'adozione di Wayland sia comunque "fonte di incertezza" anche per chi l'adottato. Posto uno scrennshot per chiarire.

P.S.: se installate Ubuntu 22.04 Desktop, potreste avere dei problemi tipo il "Terminale" che non si apre. Cambiate eventualmente dalle opzioni la lingua in un'altra (Inglese dell'Inghilterra ad esempio).

Ciao

[DragoRosso]

in mancanza di un repo pubblico...
ho fatto un programmino per testare le differenze tra le immagini

ho messo un algoritmo di confronto, chi vuole può aggiungerne altri così da confrontare i tempi

Ciao, ho provato l'algoritmo, ed effettivamente non me l'aspettavo ma è veloce ... ma c'è il trucco: sfrutta la funzionalità di TBGRABitmap nel crearsi una copia "lineare" della bitmap in memoria. In questo modo il compilato non è null'altro che una veloce sequenza ciclica di un paio di istruzioni in assembler (o giù di li) per la parte di confronto.

Occorre vedere tutto il processo di caricamento da DC se ne vale la pena: comunque vale solo un frame e quindi complessivamente fà una operazione che non verrà mai più usata (e inoltre dovrebbe fare una iniziale scanline teoricamente).

Rimarrebbe il problema della trasmissione: si dovrebbero marcare le differenze in un qualche modo (chunk) primitivo per trasmettere meno dati possibile ma comunque identificarli, quindi o ritorniamo alla linea (scanline) dell'immagine, alle porzioni di immagine rettangolari, a compressori (tipo MPeg o meglio MJpeg) ...

Ciao

[nomorelogic]

sto facendo delle prove anche in quel senso
cercando di dividere una immagine in chunk

se raggiungo qualche risultato soddisfacente vi faccio sapere


Edit:
in effetti BGRAbitmao è molto ottimizzato e userei quello in quanto riuscirebbe a garantire ottime prestazioni su tutte le piattaforme
resta da vedere se c'è un modo veloce per copiare da DC alla bitmap
ma credo che possa essere una operazione veloce


Edit 2:
https://forum.lazarus.freepascal.org/index.php/topic,63171.msg478040.html#msg478040
thread di xinyiman

[DragoRosso]

Edit 2:
https://forum.lazarus.freepascal.org/index.php/topic,63171.msg478040.html#msg478040
thread di xinyiman

Si, era legato a quanto verificato e riportato anche in questi post. Con Wayland ci sono problemi su cui in questo momento è meglio soprassedere. Ubuntu mette a disposizione l'interfaccia X11 al posto di Wayland con un click.

Ciao

[DragoRosso]

Ahh, ulteriormente:

sto facendo delle prove anche in quel senso
cercando di dividere una immagine in chunk
se raggiungo qualche risultato soddisfacente vi faccio sapere

facendo diversi test, anche con sistemi di teleassistenza professionali, ho visto che l'MTU rimane comunque a 1,5 KB. Inoltre il "trunk" di dati trasmissibili a blocco (quindi senza ack continuo) si assesta intorno ai 16 KB (che è quello che usa anche Indy).

In pratica, ma devo approfondire il discorso appena avrò terminato con la parte dei Thread, 16KB corrisponderebbe a una linea (scanline) non compressa di una immagine a 4K (anzi, di meno visto che il canale Alpha potremmo anche gettarlo alle ortiche).

Se manteniamo il blocco dati intorno a quelle dimensioni potremmo ottenere buone prestazioni.

Però, una volta che il sistema di trasmissione sarà consolidato potremmo fare le prove con varie soluzioni per trovare l'ottimale.

Nel contesto delle prove che state facendo sulla grafica, mettiamoci anche un punto di domanda sulla qualità. E direi che molto probabilmente qualità / prestazioni verranno definite solo dalla quantità di dati inviata. Per ciò che ho visto non è l'analisi dei frame che rallenterà ne il client ne il sistema remoto.

Ciao

[xinyiman]

Ahh, ulteriormente:

sto facendo delle prove anche in quel senso
cercando di dividere una immagine in chunk
se raggiungo qualche risultato soddisfacente vi faccio sapere

facendo diversi test, anche con sistemi di teleassistenza professionali, ho visto che l'MTU rimane comunque a 1,5 KB. Inoltre il "trunk" di dati trasmissibili a blocco (quindi senza ack continuo) si assesta intorno ai 16 KB (che è quello che usa anche Indy).

In pratica, ma devo approfondire il discorso appena avrò terminato con la parte dei Thread, 16KB corrisponderebbe a una linea (scanline) non compressa di una immagine a 4K (anzi, di meno visto che il canale Alpha potremmo anche gettarlo alle ortiche).

Se manteniamo il blocco dati intorno a quelle dimensioni potremmo ottenere buone prestazioni.

Però, una volta che il sistema di trasmissione sarà consolidato potremmo fare le prove con varie soluzioni per trovare l'ottimale.

Nel contesto delle prove che state facendo sulla grafica, mettiamoci anche un punto di domanda sulla qualità. E direi che molto probabilmente qualità / prestazioni verranno definite solo dalla quantità di dati inviata. Per ciò che ho visto non è l'analisi dei frame che rallenterà ne il client ne il sistema remoto.

Ciao

Ottime notizie quindi. Per quanto riguarda la qualità secondo i miei test passati la cosa più veloce era recuperare lo screenshot in jpeg compresso con perdità della qualità impostabile come parametro (default ad un 25/30%). Così l'immagine di partenza di suo era già leggera e poi si lavora solo sulle differenze.

[DragoRosso]

L'immagine Jpeg è sicuramente la base di partenza per per il full frame, perchè ogni tot. è da inviare un full frame per pareggiare eventuali scostamenti incrementali.

Occorre fare un pò di prove per verificare tempi e carico di lavoro. Tanto per fare un esempio, un sistema come il mio con desktop da doppio monitor più o meno equivalente ad un 4K, la routine di @nomorelogic postata (che scansiona ogni pixel  ) ci impiega al massimo 16 ms. a scansionare tutti i pixel (poi bisogna vedere nella cattura del frame quanto ci mette).

Questo per dire che le scelte che si possono fare sono ampie, e tra loro non ci saranno molti scostamenti. Certo è che non dobbiamo metterci a fare un compressore video (encoder / decoder) ... esistono già e sono normati e testati.

1) JPeg come full frame di partenza.
2) Differenziale a linea, a pixel, a rettangoli, (ma anche jpeg stesso) ......
3) Trasmissione bilanciata;

Come cappello, sempre con il concetto che il client remoto abbia un carico dato dalla teleassistenza comunque contenuto.

N.B.: ulteriore nota, dobbiamo anche tenere conto che la banda "internet" a disposizione sul client emoto non sarà tutta per la teleassistenza, E' per quello che ho provato linee lente (300 Kb).