[es] - Linux prebacio 4%

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
*.dynamic.isp.telekom.rs.

+2789 Profil

^{04.11.2020. u 13:57 - pre 42 meseci}

DC na Windows-u može da se odnosi na memorijsku bitmapu. Onda lepo može svaki thread da vrši renderovanje u DC memorijske bitmape, da bi onda thread koji obrađuje sistemske događaje (jer može biti i drugih event pool-ova) iscrtava tu bitmapu u DC-u prozora. Bitmapa može da bude atribut klase prozora i onda se po završetku renderovanja prozor invalidira.

Pojmovi koji su logički različiti treba da se implementiraju odvojeno, a ne da se trpaju u isti koš. Trpanje u isti koš je špageti kod i to jeste pogrešno. Posle je teže za održavanje. Promeniš jedan deo, na način koji je bezbedan, to jest ne remeti druge delove.

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
82.117.201.26

+1064 Profil

Re: Linux prebacio 2%

^{04.11.2020. u 14:10 - pre 42 meseci}

Tako i radi, vec sam napisao. U onpaint f-ji se poziva f-ja koja sa bitblt iskopira iz ostalih dc-jeva u onaj koji ce se iscrtati vizuelno.

Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
*.dynamic.isp.telekom.rs.

+2789 Profil

Re: Linux prebacio 2%

^{04.11.2020. u 14:43 - pre 42 meseci}

Pa, onda je ceo GUI u istoj niti. Nemaš nikakve GUI pozive iz drugih niti.

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Odgovor na temu

Ivan Dimkovic

Administrator
Član broj: 13
Poruke: 16687
..1e1:dd00:3545:f7db:47e4:bab3

+7173 Profil

Re: Linux prebacio 2%

^{04.11.2020. u 20:24 - pre 42 meseci}

Citat:

Nedeljko:
@Ivan Dimkovic,

Znaš li kako na Linux-u radi to sa TCHAR?

Nema TCHAR. Ceo API je UTF-8 bez BOM-a. Dakle, jedini tip stringova u API-ju je char*. Radi odmah i kao ASCII i kao UNICODE, sa istim build-om, bez ikakvih podešavanja, nemaš dvostruke API funkcije zbog toga, ali...

i to ima svoju cenu. Nemaš direktan pristup znaku sa zadatim indeksom (kao str[ i ]), nego prvo transformiši UTF-8 char* bez BOM-a u wchar_t* da bi mogao normalno da rukuješ stringovima. Dakle, za argument argv main funkcije važi da je argv[ i ] tipa char* i da pije UNICODE, ali posle treba da se transformiše u wchar_t* za normalan rad.

Ali pazi, bukvalno 90% planete koristi neki jezik koji se ne uklapa u ASCII. Za njih, i ovako i onako neces moci da prodjes sa ASCII, tako da vecina planete i ovako i onako odavno i ne razmislja na ASCII nacin.

OK, problem koji navodis jeste problem - nemas direktan pristup preko indeksa. Ali pazi, ako ti to treba, mislim da je daleko pametnije kad to radis uraditi konverziju (ili ces sve drzati u fiksnoj sirini ako su ti takve performanse bitne), nego da ceo ostatak koda (i sveta) bude prisiljen na obrnuto.

Primeti da se UTF-8 dobro primio, sto znaci da ocigledno njegove karakteristike nisu lose.

Ali cek, Win32 je koristio UCS-2 do Win 2000, a od Win 2000 UTF-16, ali im je wchar_t 16-bitni (za razliku od Linuxa, gde je wchar_t 32-bitni)... hmmm, znaci - imas sve mane varijabilnog kodiranja bez prednosti koje bi imao sa UTF-8?

Da, zvuci kao Win32, jos jedan primer... pameti :-)

DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos: http://www.digicortex.net/node/17 Gallery: http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! - https://github.com/psyq321/PowerMonkey

Odgovor na temu

Ivan Dimkovic

Administrator
Član broj: 13
Poruke: 16687
..1e1:dd00:3545:f7db:47e4:bab3

+7173 Profil

Re: Linux prebacio 2%

^{04.11.2020. u 20:32 - pre 42 meseci}

Citat:

Branimir Maksimovic:

Citat:

Nedeljko:
Ako thread-ovi renderuju u bitmapu, koja se onda crta, onda nema potrebe da ti thread-ovi budu GUI.

To što ste uradili je greška u dizanu.

Ne renderuju bitmapu i crtaju svako po svom dc-ju ...
Mislim da gresis kada kazes GUI thread, ispravno je reci event processing thread, koji je zaista jedan.

Imati vise GUI niti znaci da iz vise niti izvrsavas operacije koje su vezane za kontekst jednog prozora. Ako su u pitanju 2 prozora, imas vise srece - mada i tada u Win32 mozete imati deljen queue.

To moze da izazove gomilu zanimljivih problema. Osim deadlock-a, Win32 API nema puno problema sa samim crtanjem, posto nudi funkcije iz 80-tih.

Ako imas nesto ozbiljnije danas, recimo GL, ideja da vise niti "crtkaju" po jednom GL prozoru je ludilo. Ako bas hoces da razbijes operacije na vise niti, imaces niti za "simulaciju" koje pohranjuju svoje rezultate u neku teksturu / graficki bafer, a glavna nit to onda na kraju naredi GPU-u da iscrta.

A i tada nisam siguran da je to preterano pametno, koliko niti treba da imas za GL render onda varira od arhitekture do arhitekture, pa je mnogo bolje takvu vrstu paralelizma ostvariti na nivou drajvera.

Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
*.dynamic.isp.telekom.rs.

+2789 Profil

Re: Linux prebacio 2%

^{04.11.2020. u 20:47 - pre 42 meseci}

Vidi, ja pojma nemam da li je taj Linux/glibc char* kodiran sa uvek istim byte order-om ili zavisi od arhitekture. Možda Branimir Maksimović zna.

E, sad, šta ti misliš, da li je bolje to ili ovo MS-ovo? Ja mislim da je dobro oboje i da u oba slučaja može da se programira.

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
*.dynamic.isp.telekom.rs.

+2789 Profil

Re: Linux prebacio 2%

^{04.11.2020. u 22:45 - pre 42 meseci}

Crtkanje i ne treba da se radi pred očima korisnika, da bi prikaz bio gladak, nego u memorijsku bitmapu, koja se odjednom iscrta.

Takođe, kada se razvija softver, dizajn treba da bude takav da se logički različiti pojmovi implementiraju zasebno i da se implementiraju logičke veze između njih. Onda se promena u jednom delu koda ili reflektuje samo na taj modul ili se reflektuje i na ostale module na smislen način. Tako kod postaje lak za održavanje.

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Odgovor na temu

Ivan Dimkovic

Administrator
Član broj: 13
Poruke: 16687
..1e1:dd00:3545:f7db:47e4:bab3

+7173 Profil

Re: Linux prebacio 2%

^{04.11.2020. u 23:33 - pre 42 meseci}

Citat:

Nedeljko:
Vidi, ja pojma nemam da li je taj Linux/glibc char* kodiran sa uvek istim byte order-om ili zavisi od arhitekture. Možda Branimir Maksimović zna.

E, sad, šta ti misliš, da li je bolje to ili ovo MS-ovo? Ja mislim da je dobro oboje i da u oba slučaja može da se programira.

Naravno da je bolje Linux resenje (u jbt...) - i naravno da "u oba slucaja moze da se programira", wtf? Mozes da programiras i na papiru, busenim karticama, u masinskom kodu... nisi bas puno rekao sa tim.

Zato je Linux pristup bolji?

1. Zato sto ti je od starta internacionalno (UTF-8) - Microsoftu su trebale godine i godine da "namoli" korisnike da predju na "UNICODE"

2. UTF-8 te tera da se "ponasas" i pazis ako ti trebaju pozicije karaktera... A! Znaci dobre sanse za bagoviti kod? Da, ali... ni Microsoftov 16-bitni "UNICODE" nije fiksne velicine, ako nizi Kinez manje su sanse da vidis bagove, ali bez brige... tu su :-)

3. UTF-8 zahteva, sto ja zovem "zdravu" kompleksnost koda: to je kompleksnost koja je ili neizbezna ili pokriva vecinu slucajeva. Znaci od samog starta znas da velicina u bajtovima nije nuzno duzina stringa u karakterima, te da adresiranje nije direktno. S*anje? Zavisi, to te tera da to imas u vidu i da kod prilagodis kako treba - ako ti treba direktno adresiranje zbog performansi, to ces biti prisiljen da uradis svesno (sto povecava sansu da znas sta radis). Ako ne znas, oslonices se na neku biblioteku koju je pisao neko kompetentan i resio probleme za tebe.

Kako se to razlikuje od Win32 API-ja: pa pogledaj Windows-ov "UNICODE": za pocetak, wchar_t u Win32 je 16-bitni, sto znaci da i tu ne mozes da izbegnes dr*anje ALI godine i godine lose prakse su gomili dali uverenje da je jedan karakter = 16 bita, sto i jeste bilo tako do Win2K, kada je Microsoft UCS-2 zamenio sa UTF-16... pogadjas, na kretenski nacin - odjednom je "UNICODE" postao UTF-16 preko noci, Win32FunkcijaW je postala UTF-16 i tako dalje...

Ovo je vec uobicajeni nivo idiotizma koji ocekujes od Win32...

Ali neeeee.... ima jos!

Vidis, Microsoft je uspeo da za*ere i svoj "UNICODE"... standard? Pa su tako imena fajlova zapisana sa kodiranjem koje je... interesantno:

https://unascribed.com/b/2019-08-02-the-tragedy-of-ucs2.html

Citat:

Windows, being such a popular platform (and therefore having a lot of... not very good developers making software for it) has become somewhat well-known for having filenames and other such things with malformed UTF-16, such as a surrogate pair in the wrong order, or only one half of a surrogate pair, due to naive string manipulation code that expects UCS-2 and not UTF-16. This has resulted in the creation of WTF-8, which stands for Wobbly Transformation Format, not what you thought it stood for. Sheesh.

WTF-8 is UTF-8 but capable of encoding malformed UTF-16 surrogates, to faithfully reproduce these broken strings on systems that use UTF-8.

Najbolji dokaz da je API djubre je ovo gore - cak i tvoji sopstveni developeri se za*base. Sta ocekujes od drugih tj. "trecih strana" :-)

Uspeh: kada ljudi naprave format koji se zove WTF-8, samo da bi mogli da parsiraju tvoj bagoviti kvazi-UTF-16.

Btw, jasno je da je u pocetku u pitanju bio samo los tajming - Microsoft je NT dizajnirao u vreme kada nisu postojali ni UTF-8 ni UTF-16, vec samo UCS-2. UTF-8 je nastao 1992 (UTF-16 1996-te.).

Ali kada su prelazili na novi format u Windows 2000, mogli su komotno da predju na UTF-8. Naravno, kao i uvek, Microsoft je odabrao put najmanjeg otpora, kako bi oni i armije 3rd party programera imali manji posao, ali vise bagova. To je skroz OK, zato i imamo WTF-8... ali brate, to ima svoj izraz: djubre. U ovom slucaju "jeftino". Komercijalno to ima smisla, bas kao sto i "pink slime" proteinski proizvod koji neki zovu meso ima smisla. Ali ima i svoje ime.

Odgovor na temu

Ivan Dimkovic

Administrator
Član broj: 13
Poruke: 16687
..1e1:dd00:3545:f7db:47e4:bab3

+7173 Profil

Re: Linux prebacio 2%

^{04.11.2020. u 23:53 - pre 42 meseci}

Citat:

Nedeljko:
Crtkanje i ne treba da se radi pred očima korisnika, da bi prikaz bio gladak, nego u memorijsku bitmapu, koja se odjednom iscrta.

Napredovali smo jos. U 2020 je svakako najbolje je da crtas direktno u GPU bafere iz shader-a, zato sto imas superiorne mogucnosti za AA, filtriranje, enormnu brzinu za prolaz kroz piksele, "besplatne" geometrijske transformacije i sl. Bukvalno sve od PC-jeva sto ima ekran ima GPU.

ALI! Vidis, Win32 je str8 port Win16 API-ja - u ta vremena bi ovaj savet koji si dao bio komentarisan sa "koji si ti ludak, ko ima toliko memorije". OK, moj savet sa GPU-om bi bio docekan sa: WTF je GPU?

Bilo je tu jos problema, obicno su tadasnje graficke kartice imale svoj VRAM koji je bio konfigurisan za adekvatnu upotrebu (nije kesiran i sl.). Sistemska memorija je posebna. Ako crtas u memorijski DC, to ide u sistemsku memoriju i mora da se iskopira u VRAM. To je bilo vreme bez PCIe transfera, drajver je morao da angazuje DMA, itd.. show.

A, da, zbog pateticne brzine popunjavanja piksela na CPU-u, gomila kartica iz te ere su imale i akceleratorske f-je, koje su koriscene tako sto je video drajver implementirao tzv. GDI akceleraciju (GDI = matori Win32 graficki API). Vracanje na crtanje u memorijski bafer na CPU-u je cesto bilo usporenje u odnosu sta su mocne VLB kartice tog vremena mogle da urade. Naravno, ovo je bilo rezervisano samo za vrlo skupe masine, sumnjam da si mogao da po defaultu racunas na to.

Tako je vecina aplikacija iz 80-tih i sa pocetka 90-tih koristila direktno iscrtavanje (single-buffer), sa gomilom trikova da se izbegne previse crtanja ili, ne daj boze, BitBlit-ovanja.

Ako si sve uradio "po propisu", u WM_PAINT event-u sta god da naredis GDI-ju, to je odmah islo na ekran.

Treperenje je bilo tolerisano, osim ako se ne radi bas o necemu gde nije OK - u kom slucaju si mozda radio off-screen render, ali si za to od korisnika trazio postenu masinu :-)

Tek sa Vista-om je Microsoft uveo double-buffering za svaki prozor po default-u za Vista+ aplikacije (ako ukljucis izvesni heder), za stare su malo hakovali sve, pa su double-bufferovali samo svoje kontrole (ali i to je dinamit).

--

Sto je ovo bitno? Verovao ili ne, i dalje imas gomilu aplikacija koje crtaju u WM_PAINT ono, k'o artisti - ajmo linija ovde, krug ovde... ajde malo BitBlt, pa crtkaj tekst ovde... zlo :-) I to radi...

Ako znas sta radis, batalices sve to naravno i koristices ili neki Direct2D ili GL sa Orto projekcijom, ili ce framework API kao sto je WPF, to raditi za tebe "ispod haube" bez i da te briga gde se combo box iscrtava.

Citat:

Takođe, kada se razvija softver, dizajn treba da bude takav da se logički različiti pojmovi implementiraju zasebno i da se implementiraju logičke veze između njih. Onda se promena u jednom delu koda ili reflektuje samo na taj modul ili se reflektuje i na ostale module na smislen način. Tako kod postaje lak za održavanje.

Slazemo se. Problem sa Win32 je sto je bukvalno pozivao na krsenje te paradigme na milion nacina.

Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
p2-115.p59.bvcom.net.

+1064 Profil

Re: Linux prebacio 2%

^{05.11.2020. u 01:37 - pre 42 meseci}

Citat:

Nedeljko:
Pa, onda je ceo GUI u istoj niti. Nemaš nikakve GUI pozive iz drugih niti.

Kako nemam? Pa sve f-je koje iscrtavajau su GUI, samo sto to ide u druge DC-je.. iz kojih se u onpaint-fji iskopira u dc koji ce ici na ekran,
Ali da ako striktno gledamo iscrtavanje se desava samo u 1 threadu.

Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
p2-115.p59.bvcom.net.

+1064 Profil

Re: Linux prebacio 2%

^{05.11.2020. u 01:44 - pre 42 meseci}

Citat:

Ivan Dimkovic:

Citat:

Branimir Maksimovic:

Citat:

Nedeljko:
Ako thread-ovi renderuju u bitmapu, koja se onda crta, onda nema potrebe da ti thread-ovi budu GUI.

To što ste uradili je greška u dizanu.

Ne renderuju bitmapu i crtaju svako po svom dc-ju ...
Mislim da gresis kada kazes GUI thread, ispravno je reci event processing thread, koji je zaista jedan.

Sa opengl sam se bavio pre jedno 15 godina, nista ozbiljno osim sto sam pretabavao neke turorijale na asembler :P
Sto se Windows-a tice, nema nikakvih problema da svaki thread iscrtava u svoj dc. Ali nema svrhe da krajnji rezultat ne iskopiras samo u jedan thread, posto je bitblt f-ja blazingly fast.

Odgovor na temu