Linux prebacio 4.5%

Konkretno ovde se iscrtava na onpaint, ali samo bitblt iz contexta koje pune (gui rendering) threadovi.

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.

Potpis

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

Koji OS i koji framework su u pitanju? Možda vam to i radi, ali svejedno dizajn ne valja.

Potpis

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

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.

Windows, MFC. Znas kako, ako neko radi drugacije od onoga kako si ti naucio, to automatski
ne znaci da dizajn ne valja.

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.

Potpis

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

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.

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

Potpis

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

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 :-)

Potpis

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

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.

Potpis

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

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.

Potpis

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

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.

Potpis

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

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



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.

Potpis

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

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.



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

Potpis

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

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.

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.

Qt ima podrazumevani double buffering počev od verzije 4.

Potpis

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

char* pointer je niz bajtova i nista vise. sta je iza toga zavisi sta stavljas. Moze biti da je neka struktura vezana za byte order svakako koju si upucao direktno
iz memorije.... zato se u tcp/ip programiranju koriste one f-je hton ntoh ;)

Ne pitam to, nego za funkcije scanf, fscanf, printf, fprintf, open, fopen i slično.

Potpis

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

scanf i s(n)printf rade sa ascii karakterima, znaci tu je samo ascii niz nista vise. printf prihvata host tipove i pretvara ih u ascii niz i salje na stdout.
Ako si mislio na utf8, ne prepoznaju utf8, mada mislim da gcc ima neku magiju pa moze :P