Cred ca am gasit un bug prin xorg, legat de orientarea ecranului.
Cu ecran orientat normal, scrolling-ul si drag-ul la ferestre e destul de smooth (depinde de platforma si implementare).
Daca il rotesti (de exemplu cu xrandr), un drag pe noua directie ‘verticala’ (adica vechea orizontala) rezulta in tearing la fereastra trasa. Nu e acelasi lucru cu ‘screen tearing’, se manifesta doar la fereastra trasa (sau in care se face scroll).
Asta e in ciuda vsync-ului, indiferent ce buffering se face, cu ce se face desenarea (opengl sau xrender), ce composer se foloseste, etc, dar un composer poate sa faca problema mai vizibila (contrar asteptarilor).
Depinde ce intelegi prin ‘normal’. Asa am considerat si eu, pana mi s-a atras atentia.
Nu e chiar asa de usor de observat, trebuie sa tragi fereastra destul de rapid. In mod normal e desenata ok, cand e screen-ul rotit de exemplu daca te uiti la bara o sa vezi ca e ‘rupta’ din cand in cand. Cu composer cu vsync activat situatia e si mai observabila, din cand in cand apar niste benzi verticale unde fereastra e ‘rupta’.
Tu zici de efectul de rupere care apare ca în poză? Ăsta da, e sesizabil, dar efectul pare şi când ecranul nu e rotit şi mişti rapid fereastra pe orizontală. Pare mai degrabă o problema a modului în care se produce refresh-ul pe orizontală.
Da, de ala. Efectul ala la mine nu apare cand e ‘normal’, cu compositor si vsync activat. Cu astea doua insa cand e ecranul rotit, e nasol de tot, mai rau decat ce ai tu in poza, am descris mai sus.
La mine apare în ambele cazuri, când probabil mişcarea nu este in-sync cu frecvenţa de refresh pe orizontală. Poate depinde şi de chipsetul video, de driver, de kernel (cu bălăria aia de modeset), de window manager, de panoul LCD etc.
De pe vremea lui Z80 ţin minte că era foarte greu să faci o chestie gen “news ticker”, dacă mişcarea nu era perfect sincronizată cu 15625 Hz (dacă nu mă înşel, trebuia să faci scroll-ul la intervale de multipli de 64 ms) apărea grosolan efectul ăsta de “tearing” şi “stuttering”. Acum că avem diverse rezoluţiii, probabil e şi mai complicat să te sincronizezi pe orizontală.
Da, probabil ca nu ai chiar situatia mea (de-aia am scris ca depinde).
Si eu am considerat situatia ‘normala’, de-aia am trecut-o cu vederea, insa cum am implementat un device driver ce are legatura cu subiectul, normal ca mi s-au adresat mie ca sa rezolv. Imediat am instalat compton https://github.com/chjj/compton am activat vsync si backend glx, am testat in mod normal si am declarat succes.
Doar ca aia vor sa mearga cu ecranul rotit… si acolo situatia s-a agravat, de fapt
Dupa foarte multe teste si uitat prin cod, am decis ca problema nu e nici in driverele ce tin de video, nici in implementarea opengl, nici in xfwm (problema se manifesta la scrolling si fara asta, oricum n-are nici o treaba cu scrolling-ul, doar cu ‘decoarea’, etc), nici in compositor.
Exista tot felul de probleme cu rotirea ecranului prin tot felul de locuri, de exemplu patch-ul asta rezolva cateva bug-uri: https://git.xfce.org/xfce/xfwm4/commit?id=27aa2c7a6f978b2b4485b3241daa3580eb2edd63 (au amestecat dimensiunile rotite cu cele normale si a iesit varza).
Suspectez ceva similar la partea ce tine de damage. Din pacate cred ca nu ma platesc destul ca sa localizez sursa si sa rezolv, asa ca ii las sa se chinuie cu wayland. Ala merge bine, dar are alte neajunsuri, nu merge chiar tot ce vrei pe el.
De fapt vsync-ul cred că nu ajută cu nimic în situaţia în care ecranul e rotit. Dacă roteşti fizic monitorul, vsync devine un soi de “hsync”, iar pe verticală devine “nesincronizat”.
De curiozitate nu ai încercat să simulezi o scrollare pe orizontală sincronizată cu frecvenţa baleiajului orizontal? (nu sunt sigur că termenul e corect în contextul monitoarelor LCD) Poate chiar există vreun mecanism care să te informeze când începe o “linie” nouă, să te sincronizezi cu ea.
Rotirea de fapt e doar ‘software’, in realitate (pentru device-ul asta particular), nici macar nu trebuie sa rotesti imaginea, ajunge sa indici hardware-ului ca doresti sa roteasca frame-ul, ca stie el cum sa culeaga pixelii si sa-i transmita.
Sincronizarea e tot aia, nici o diferenta. vsync-ul ala nu face decat sa marcheze momentul cand se face switch-ul cu un alt frame gata pregatit/desenat.
Problema de vsync (cand sincronizarea lipseste) e diferita, sa ‘rupe’ tot ecranul, nu doar fereastra mutata/scrollata, si de obicei doar intr-un loc, ca in imaginea de mai sus. Nu e cazul aici, aici problema e strict cu o fereastra. Acea fereastra ar trebui sa fie desenata complet mutata intr-o noua pozitie inainte de a se face switch-ul la frame. Problema e ca nu se face asa. ‘Ceva’ o rupe in loc s-o deseneze complet mutata.
Intr-o lume ideala, panel-ul ar trebui sa stie singur sa faca rotatia, pana la urma e o matrice de pixeli, si nu ar trebui sa-i pese prea mult care e coordonata x si care y. Problema e ca e fabricat de chinezi si desi poate ca e capabil de asa ceva, modul in care am implementat softul a fost cu specificatii lipsa, ceva informatii vagi cu privire la initializare si atata tot, restul, reverse engineering. Daca as sti cum sa initializez display-ul ca sa fie rotit, tot soft-ul nu ar vedea decat un panel cu rezolutie diferita si n-ar mai trebui sa se efectueze nici o rotatie pe partea ‘software’, caz in care ar functiona cum functioneaza cum ne-rotit, adica fara probleme. Problema e ca probabil chinezii n-o sa furnizeze acea informatie
