Wyświetlacz z interfejsem RGBTTL

sobota, 4 listopada 2023 o 13:25:55 UTC+1 Mirek napisał(a):

Ciekawa koncepcja. Po zastanowieniu warto sprawdzić, czy będzie wyświetlał jedną linię, czy również i to nie.

To przypomniało mi wyświetlacze 240*64 mono T6369C, jakie kupowaliśmy do tramwajów, kiedyś przez przypadek odczytałem cyferki na SRAMie i okazało się, że mają zamontowane piękne 62256, czyli 32kB. Szkoda że nie całe 64kB.

Dla porównania 240*128 miały tylko 16kB.

Nie ma do niego dokumentacji? Zazwyczaj te kolorowe maja własną pamięć.

Ja bym powiedział, że zazwyczaj nie mają. Tzn. te z interfejsem TTL RGB, jak w opisie, ew. wciśniętym w szeregowy LVDS, żeby było mniej drutów. To są takie wyświetlacze jak w laptokach i monitorach - pamięć i sterownik są w "osobnej'" "karcie graficznej". A one same mają "pamięć" na jedną linię.

Własną pamięć mają takie z wbudowanym sterownikiem. Ale wtedy interfejs jest jak magistrala,

8- czy 16-bitowa (czyli RD, WR - a nie hsync/vsync, jak w VGA) albo szeregowa, zwykle SPI.

Ale on nie ma szeregowego LVDS. Ma równoległy TTL.

Nie, to inny model. Ewidentnie nie jest to LVDS.

Istnieje spora szansa, że ma własną pamięć, jeśli nie ma sterowania polaryzacją (co to za sygnał DE?). Machanie Mhz aby zapewnośc odpowiednio szybkie wciskanie pixeli zanim się "wypalą" do nastepnego cyklu zmiany polaryzacji, w przypadku 24bit koloru, to dość sporo, nawet na współczesne uC. Więc ta "karta graficzna", nawet w przypadku 320x200, to już zaganienie sporego kalibru. A jak 24 bitowe wyświetlacze się pojawiły, to i pamięć była odpowiednio tania.

Tego nie wiadomo. Miałem w ręku kilka LCD z hsync/vsync posiadające własną pamięć, w tym sensie, że nie wymagały żadnej odgórnej prędkości wkładania pixeli. Od jednobitowych po kolorowe, chyba największy miał 16 bitów na kolor. Miałem też takie bez. Dlatego pytanie o dokumentację. Zgadywanie to nie jest nic sensownego, bo i iface mało typowy.

Hsync i Vsync sugerują raczej że wymaga ciągłego odświeżania.

To się różni tylko tym, że sygnały z siedmu drutów wkłada się w parę skrętki.

No nie jest, bo RGBTTL.

Nie wiem, czy były laptoki z RGBTTL, może bardzo stare. Ale wyświetlacze RGBTTL mają się dobrze do dziś. Np. używane z FT810.

Interfejsy do RGBTTL miałem też na jednopłytkowcach industrial PC Advantecha, od PCM-5820. Nie miałem wyświetlacza więc nie podłączyłem, ale miałem chyba 3 sztuki z wlutowanym chipem LVDS, a że podłączanie było na goldiny w rastrze 2mm to podłączyłem wyświetlacz z zepsutego laptoka i pięknie się pokazywało.

DE to bodajże "display enable", czyli włączanie wizji. Są też takie modele które mają hsync i vsync razem w sygnale o podobnej nazwie.

Zaś czy 24 bit 320*200 to dużo? Lata temu - 2010, a może i wcześniej - miałem w ręku płytkę z takim dużym uC Renesas, architektura SuperH. eCos i RedBoot, ale to było super, i miał możliwość bezpośredniego podłączenia właśnie RGBTTL. Miałem tylko 320*240, ale chyba mógł więcej. Minus był taki, że choć miał własne 64kB SRAM, to żeby wyświetlać musiał mieć podłączony zewnętrzny SDRAM. Tak, SDRAM, nie SRAM. Była kostka na płytce. Może to jeszcze gdzieś mam.

A teraz każdy może sobie z ATmegi sterować FT810, ma wbudowany 1MB, więc 800*600*16bit framebuffer jest. I oprócz tego jeszcze renderuje display list.

Wow, dasz jakiś przykład? Bo cuda opowiadasz, ale może i takie pomysły ludzie mieli.

A co to jest "sterowanie polaryzacją"? Polaryzacją czego?

Niektóre wyświetlacze (np: M133B [1], wydłubałem go z kasy fiskalnej) mają dodatkowy sygnał, bodaj M, który co każdą ramkę obrazu należy odwrócić. Jeśli tego nie zrobisz, panel ulegnie elektrolizie. Niestety, jak widzę, datasheet do niego przestał istnieć, przynajmniej w google, więc nie uda mi się pokazać dokładnie przebiegów, ale ogólnie ten panel wymaga pilnowania ramek parzystych i nieparzystaych z perfekcyjnym podziałem czasu 50/50. A to tylko początek jego wad.

[1]

Niczym, jesli wszystko co masz, to program napisany w asm przez brodatego embedowca. Wtedy najzwyczajniej, nie masz wyboru.

Jam masz kod napisany w czymś przenośnym, to Z80 jest gorszy we wszystkim.

Ale zazwyczaj nie masz.

To jest np. powód, dla którego współczesne telefony dalej mają jakiegoś kolna 8051 do obsługi GSM. Za dużo asemblera powoduje uzależnienie.

A są jakieś wyświetlacze z elastyczną ilościa pixeli w lini?

No i jak myślisz, dlaczego wobec tego dalej stosuje się, do dzisiaj, HSYNC w LCD zamiast wstawić tam kilka przerzutników? Ogarnięcie tej garstki tranzystorów powinno kosztować ćwierć centa.

I tutaj dochodzimy do sedna: dlaczego czasami podpina się archaiczne sterowniki do współczesnych wyświetlaczy.

Dlatego, mając na chwilę obecną, jakikolwiek wyświetlacz który *wygląda* na bez pamięci, głowy bym nie dał.

Bo koszt zmiany myslenia, szczególnie w komitetach za zielonym suknem, jest czasami równy zastępowalności pokoleniowej. Tu masz odpowiedź, po co komu iface do LCD przypomianający jak żywo CRT.

Po prostu programatorzy embedded są niereformowalni, wiec nagina się hardware do gównianego software i liczy na zmianę technologiczną wraz z zapełnianiem cmentarzy.

Widziałeś kiedyś jak działa odtwarzacz DVD powiedzmy z 200x roku? Ma super szybkie pixele z MPEG2, ale niewiarygodnie wolne menu, które wygląda jak by przesyłali je szeregowo (i chyba tak dokładnie jest). Refresh ekranu to około 0.5sek.

I wiesz co? Suwerenowi nie przeszkadza.

Tym bardziej operatorowi tokarki.

Jak chcesz miec ethernet, internet, wyswietlacz graficzny, usb, karty pamieci, bzy danych czy dostęp do nich - to duzo gorszyc.

Mówisz? Technologia sie rozwija, trzeba stale i program unowoczesniac.

Wyswietlacze to moze nie, ale narobiło się, ze obslugujemy różne formaty. i "wyswietlacz"/monitor/"ekran" sobie przetwarza..

Nawiasem mówiac - cos sie dzieje, i monitory to gier zdaje się zyskały nieokresloną czestotliwośc pionową ..

Ale oscylujemy w sprzęt embeded? To ekran często jest jaki jest :-)

No ale DVI było troche uniwersalne. Analogowy sygnał też gdzieś tam był.

Ale to jak rozumiem dlatego, ze sterownik wyswietlacza ma sprzetowy dekoder MPEG i pomocniczy kanał OSD. Pomocniczy, wiec może być powolny. Szczególnie, jak komus sie nie chce zrobic w assemblerze, tylko wyciąga jakąs ambitną bibliotekę graficzną :-)

A wmiksowanie własnych tresci w MPEG ... o, to nie jest takie łatwe, a wrecz niemozliwe dla Z80 :-)

No to w czym problem ? Wszyscy sa zadowoleni.

J.

Z przygód kolegi pracującego w firmie robiącej sterowanie: jesli chcesz mieć *jakąkolwiek* zmianę, to soft nadaje się do przepisnia od nowa, tym bardziej, że autor poprzedniej wersji właśnie łowi ryby na emeryturze.

Systemy oparte o Z80 to guano pisane niskopoziomowo. Ich się nie rozwija, tylko łata. I tylko przez chwilę, zanim się rozlecą. To samo z

8051. Dodanie tutaj C niewiele pomaga, bo ludzie piszą w nim jak w asemblerze, często nieprzenośnie.

O najszybszej furmance świata nie słyszałeś?

Agrumentacja, nie pamiętam już gdzie zasłyszana, ale chyba od pracownika firmy, była taka, że "8051 ciągle jest używane w modemach gsm".

Czyli, jesli czytać między wierszami, jakośc tego kodu jest poniżej wszelkich metryk, skoro go jeszcze nie przepisali na cokolwiek innego. Najwidocznie nie da się przepisać, bo sieczkę można co najwyżej zaemulować albo dokładać gigazhertzów.

Innymi słowy, doczekałem czasów, kiedy hardware łata dziadowski software. Nie, żeby nie było też czasem i w drugą stronę.

To nie wyjasnia obecniści HSYNC we współczesnych wyświetlaczach, bo problem rozmiaru jest w takim protokole wyłacznie softwareowy. A jednak produkuje się je na potęgę.

I kto mu bronił być i być generowany innym elementam hardware, innym sterowaniem i w ogóle wszystkim innym?

DVI to taka hybryda, gdzie wartości analogowe zamieniono na cyfrowe, ale "zapomniano" o całej masie innych zbędnych elementów.

To się tylko wyjaśnić brodaczami za zielonym suknem, zmiana myślenia jest możliwa wyłacznie na poziomie zastepowalności pokoleń.

Jak już masz to wejscie cyfrowe i LCD, to po ch... komu blanking? ba, ja bym się nawet zastanowiło po co komu wyścig z VSYNC. Taki iface powinien na spokojnie przyjąc piksel na sekundę, jesli trzeba.

I nikomu, poza mna, nie przeszkadzało. Lduzie mają naprawdę prymitywne potrzeby.

W niczym. Taka moja konkluzja. Bez znaczenia jak żałosne i prymitywne GUI dostarczasz. Przeciętny suweren nie jest w stanie odróznić dobrego od złego. Nie ma potrzeby sterowania wyświetlaczem dla tokarza, czy Krystyny @50Hz. Nie zauważą róznicy.

Nie mówie nie, ale czy "lepsze" rozwiązania sa naprawde lepsze, czy tez co pare lat mamy "najlepiej to byłoby napisac na nowo" :-)

A widzisz. Daje sie poprawic/zmienic :-)

Możliwosci są, jakie są ...

No coz, niewątpliwie: a) ktos chce za to zapłacic, czyli jest zapotrzebowanie, b) lub dostali jakies dofinansowanie :-)

Oni tylko procesor "zrobili". O kodzie nic nie wiadomo.

A wspominajac mistrza Lema "jak powszechnie wiadomo - sprzet i program sie uzupelniają. Mozna uruchamiac prostszy program na lepszym komputerze, lub lepszy program na gorszym komputerze. W granicy - nieskonczony program mógłby działać w ogóle bez komputera" :-)

w HDMI nie ma, w DP nie ma, wiec nie bardzo wiem, o czym piszesz.

O jakis tytulowych RGBTTL, gdzie z założenia jest prosty protokół/interfejs, i HSYNC jest potrzebne?

Akurat IMHO - łaczył dwa interfejsy w jednym złączu. Jedni mogli używać cyfrowe, inni analogowe, a inni sie dziwili, ze nie działa :-)

Kolega podesłał dokumentacje, ale czytac mi się nie chce. Wyswietlacz/sterownik moze zawierac pamięc, i istotnie predkosci dosyłania mu nieistotne, albo nie zawiera, i trzeba spelnic wymagania wyswietlacza.

Albo naprawde działa przyzwoicie szybko ... tylko trzeba program zoptymalizować. Albo sprzęt :-)

Kiedys zauważą i zaczną narzekać. No chyba, ze przyzwyczaisz, i nie będą narzekac.

Np klikam na telefonie (Android) ikonkę fotaparatu ... i mija pare sekund na jego uruchomienie. podobno na iphone szybciej. No ale trzeba pamiec odsmiecic ...

Druga sprawa - na tymze telefonie w youtube chce dopisac komentarz ... i zawiesza mi sie na blisko 10 sekund. Po czym klawiatura sie jakos odblokowuje i jest dobrze.

No co - support mam męczyc, czy ajfona kupic, czy sie na YT obrazić?

J.

No to wg mnie nie będzie świecił, trzeba mu wciąż dosyłać pixele w tempie mniej więcej 9MHz (albo 27MHz, jeśli się chce zamiast 24 linii "danych" mieć tylko 8 - ale nie doczytałem jeszcze, jak trzeba przeprogramować sterownik, żeby w tym trybie dobrze wyświetlał).

"Sterownik" wg mnie jest tylko do odbioru danych i sterowania LCD, pamięci nie ma (oprócz "pamięci" jednej linii).

Choć ma możliwość zmiany pewnych parametrów przez I2C lub SPI. Najbardziej mnie zastanawia, co to może być to "OTP". Napisane, że ma "multi-OTP circuit" i że są "Multi-OTP Adjustable Parameters

- 7-bit for VCOM offset adjustment

- 7-bit ID1/ ID2/ ID3 for user use"

Ale cały internet milczy na temat tego, co to jest.

Aha, ważne - wyświetlacz jest na 3,3V, więc nie podłączaj do 5V!!!

Sam "sterownik" SC7283 - fajny chip, 1628 padów :) Ale też mnie zastanawia to, że piszą, że max rozdzielczość to 480*RGB(H) * 272(V), a w wyjściach jest:

- source outputs: 720 channels

- gate outputs: 544 channels

To 544 gates to jest 272*2 - ale w sumie po co razy 2, choć może ciekły kryształ tak potrzebuje. Ale to 720 sources to dziwne, 480*1,5 - czemu *1,5, a nie *3? Choć "w sumie" to jest *1,5*2=*3 - czyli tyle, ile jest pixeli: 391680=480*3*272=720*544.

Hm, są tam minimalne czestotliwosci i maksymalne okresy, informacja ze steruje SC7283, pdf do niego nic nie pisze, ze RAM ma ... zakładam, ze trzeba stale dosyłać dane.

I jeszcze jakas tajemnicza notka, ze Tvbp=12 i Thbp=43 w sync mode... Ale jest jeszcze DE mode ...

szukaj jakiejs noty aplikacyjnej, bo w pdf nie opisali.

Ale zakładam, ze trzeba wysyłac stale.

J.

Jesli musisz co kilka miesiący pisać na nowo stos TCP w asm, na nastepny, o pół centa tańszy uC, to tak, abstrakcja jest lepsza niż orka. Generuje mniej błedów grubych.

To prawdopodobnie jest wiedza tajemna, sądząc po ilości współczesnych dramatów typu ventor-lockin w embedded.

Tak, zgodnie z zasadą, że wypolerować na błysk można wszystko. Tylko czy trzeba?

O to to.

Tak, świat tonie w gównianym kodzie. Łatwiej (choć nie taniej) jest udawać i łatać hardware, niż dokręcić śrubkę programistom aby nie robili więcej kosztów swoim dziadowskim hackowaniem w asm.

To być może. Startupy czasami mają komfort na działanie->plan a nie odwrotnie.

Zrobili go, bo "jest do tego kod".

Czyli jest do tego tak zły kod, że innego nie będzie i pozostało przez

50 lat utrzymywać 8051 aż biologia zrobi swoje.

O tym nieszczęsnym wyświetlaczu, który po 25 latach produkowania LCD dalej nie ma możliwości dodania licznika i zwolnienia 1 lini.

Nie jest. Ale jest. Jak w 99% wyświetlaczy tego typu na rynku, które opierają się o przedpotopowe scalaki.

Ten intefejs nie jest optymalny, tylko dopasowany do tego co "już raz słyszałem". Mamoń lubi to.

Nie. Lata doświadczenia mi podpowiadają, że np. responsywnośc pilota N-ki (zmiana kanału zawiesza GUI na 1+ sekundę) powoduje irytację tylko u mnie. Resza *NIE* widzi tego problemu. Prawdopodobnie, wliczajac żałosnych programistów którzy to robili. Poprawki na ten problem nie doczekałem się od 15 lat. To ten sam problem co dziadowskie GUI w DVD, docelowy klikacz obcując z takim szajsem nie pojmuje że istnieją alternatywy.

Można to markować. Jednym z elementów tworzenia resposywnego i satysfakcjonującego UI jest markowanie działań. Wystarczy, że przycisk, który klikasz, zmieni kolor i już masz poczucie natychmiastowości, nawet jesli rezultat tego przyjdzie za sekundę. Zamiast aparatu można załadować obrazek aparatu i też powoduje to responsywność. Zamiast pokazać zdekodowany obraz kanału, można po prostu zmienić kanał na nastepny od rau po wciśnięciu przycisku (co śmieszne, CRT z początku wieku był znacząco bardziej responsywne).

Cała sztuka pisania gui to udawanie responsywności.

Ale niestety wielu ludzi nie wyszło jeszcze poza wzorzec projektowy "onClick" i chyba nigdy nie wyjdzie.

Amiga z 7Mhz dawała radę, więc procesor 1000x szybszy też powinien, a nie daje.

Skoro nie daje rady, to świadczy, jak nisko upadliśmy w jakości oprogramowania.

PS. Mam telefon z 4GB RAMu. Wydawał się całkiem spoko, do czasu aż musiałem doinstalować firmowe oprogramowanie (głupi teams i outlook). Teraz zastanawiam się czy 8GB wystarczy, bo 4 na 100% nie.

Zakładam, ze jednak nie piszesz. Szukasz rabatu na swoje procki :-0

A pewnie nigdy nie napisales stosu w assemblerze. Za duża kobyła.

No sam widzisz - albo sie przesiadamy i piszemy wszystko od nowa, tudzież wymieniamy cały sprzęt, albo ktos poprawi ten assembler w godzinę czy kilka :-)

Podejrzewam, ze sie mylisz. Nowy szybki procesor, to jednak nowy projekt, czesto mocno nowy.

Czyli i tak duzo roboty. A "modemy GSM" ... nie straciły racji bytu? Stary GSM TDMA chyba likwidują, teraz jakies LTE, pare innych standardów już było ...

Ale kto chcialby dofinansowac 8051? Na 6502 moze by sie jeszcze paru znalazlo, ale po co - zeby napisac najszybszego tetrisa na swiecie? Dotacja musiałaby byc panstwowa :-)

A tego akurat w artykule nie ma.

Moze i tak ... ale bedzie ten kod chodzil przy tej predkosci?

O linie to Ty sie nie martw - 24 linie na same dane. Tysiace do LCD ...

Widac po prostu tak najlepiej.

A to mi wygląda na w miare nowy scalak. pdf jest z 2018

ma np rozbudowaną korekcje gamma.

I tak mi wychodzi (głownie z domysłów), ze ma trzy tryby pracy

-Sync - DE, na który narzekasz,

-Sync, który nie wymaga "Data Enable",

-DE, ktory nie wymaga hsync/vsync.

Ale to czasem jest zaleta, ze nie musisz nic przeprogramowywać w obsludze wyswietlacza - przyjdzie inny sygnał, a i tak wyswietli.

Te 24 bit RGB istotnie jakos tak mi wygląda. Ale co proponujesz "lepszego" Ale moze LCD TFT wymagają ... tzn wymagaja tysiace linii do sterowania LCD, kto się bedzie przejmował 24 ...

A firma robi całą masę driverów, czemu chcesz uzywac 5-letni ? :-) A prawda, to Mirek chce :-)

Widac sekunda to jeszcze znośnie i nikogo innego nie denerwuje :-)

Ale co byś chciał przez te sekunde robić? Bo zmieniłeś kanał, teraz trzeba poczekac aż odpowiednie dane nadejdą, aby mozna było go wyświetlic. I to trwa około sekundy wlasnie?

No to jakos tam zamarkowali, bo inaczej to bym chyba tez narzekał. Ale ja, k*, czasem, chce szybko aparat działający, a nie markowanie.

A ja chce szybko aparat, a nie tracenie czasu na niepotrzebny obrazek :-P

Cie nie bardzo rozumiem, co znaczy "zmienic kanał". Numerek na ekranie ma się zmienic? Logo pokazac? Zmieniłeś kanał, to widać chcesz obejrzec :-)

Mnie tam raczej wk* te numerki kanałów. I niewielkie mozliwosci zrobienia "ulubionych"/uporządkowania listy. A moze przy setce to sie juz po prostu nie da?

Osobna sprawa, ze takie wzorce są właśnie propagowane.

Ale wlasnie usiłowałem program poprawić, żeby tak bardziej responsywnie chodził ... ciężkie zadanie :-)

Tu sie zawiesza na grube sekundy, to jest cos innego.

No ba. Ale to przecież "postęp" ? Kiedys bym sobie zdefiniował odpowiednią strukture danych, dzis czytam sql do DataTable. Kiedys mialbym numer kolumny w stałej, dziś indeksuje stringiem. Postęp panie. I nawet dość szybko to działa, w koncu od czego ma sie te GHz i rdzenie. Zdaje sie, ze wewnetrznie jakies hashowanie mocno używane.

Czasem nawet cos myslę o optymalizacji, ale mi szybko przechodzi

- przeciez nie po to mam te 4, 8, 16, 32 GB RAM, żeby sie przejmować tym, ze wczytam np milion rekordów :-)

Outlook to gdzies te emaile musi trzymac. Teams to ch* wie, co teraz w sobie ma. Ale czasem patrze na jakies gierki ... kiedys by sie 48kB zmiesciły, dzis 100MB im trzeba.

No ale przeciez narzekasz na asemblerowców, to co się dziwisz :-)

J.

Ja nie. Kolega tak, jak twierdził, dwa razy pisał to samo (TCP), w tej samej fimie, do tego samego produktu, bo procesor na którym można było by skompilować gotowca kosztował o dolara więcej, wiec sprawdzali dwa tańsze. Nie w gołym asm. Takim przeplatanym z C.

Oba wariany idityczne.

Ja proponuję wariant: zmiana -DCPU=XXX na -DCPU=YYY i poprawka w 4 miejscach w HAL.

ALe trzeba było o tym myśleć 20 lat temu.

Niby czemu?

Nie.

Zobacz arduino. Te same bibliteki są na tyle abstrakcyjne, że banglają na prockach od 8 do 32 bitów, od bajtów RAMu do megabajtów.

To się wzieło z dobrej architektury, oddzielającej logikę biznesową od wartwy hardware.

A nie z hackowania w asemblerze.

Niech zgadnę, implementacje LTE9 będzie pogadniać 8051 z zegarem 5Ghz? Nie zdzwiłbym się ani trochę.

Ktoś, kto nie wie, że to furmanka?

Czyli mniej wiecej każdy "inwestor", czyli bankowiec z kredytem, po kierunku tumanistycznym?

Dostać można doinwestowanie wielu bezużytecznych rzeczy. Dlaczego nie "najszybszego procesora na świecie"?

Zabawne, ale Megawin produkuje je do dzisiaj w formie uC ;)

Taką nawet łatwiej wyrwać, dają ją nie tylko tumaniści, ale też jednocześnie idioci.

Jak mówię, zasłyszane od pracownika. Niestety nie mam, po tylu latach, źródła, ale padło w jakimś wywiadzie.

Się doda sleepa.

Ale one mogą lecieć wprost z RAMu. A HSYNC jednak sterował by CPU.

Pfff, bo ja wiem. HDMI nawet. Cokolwiek szeregowego.

Mam tu na tapecie obecnie jakiś wyświetlacz VGA, bodaj 15 bit, z SPI, taki maleńki. To będą grube dziesiątki MHz. Ale jak patrze na cenę Pi Nano, to jakoś mi machanie drutami nawet w setce Mhz nie straszne.

Dokładnie. Dlatego ja mam ochotę wychłostać architekta tego guano, ale

*tylko* ja.

Przejść nastepne 5 kanałów w górę. Na większości CRT to było możliwe.

Nie trzeba. Ja chcę zmienić kanał na nastepny. Tymczasem jestem blokowany aż nadejdzie sygnał, albo dekoder się podda.

Zwyczajowo jedyne co chcesz to natychmiastowego potwierdzenia akcji, a nie samej akcji. Aparat może jest tutaj specyficzny. Swoją drogą miałem nadzieję, że ktoś w końcu zrobi autonomiczny aparat w telefonie, taki z gatunku milisekund od naciśnięcia mechanicznego przycisku, ale znowu: suweren nie potrzebuje, można poczekać sekundkę, dziubek i tak się układa dłużej.

99% przypadków pozostałych operacji na UI nie wymaga akcji, tylko markowania. Coś jak ładowanie prostokątów zamiast obrazków. A już możesz przewijać stronę. Oczywiście twórcy portali do dzisiaj nie potrafią ogarnąc stabilnej geometrii strony, ale tam też dziadstwo na dziadostwie. Powiedzmy, że powinno tak być.

Tak.

Oglądam 11-kę. Chce obejrzeć 13-tkę. Kosztuje mnie to, zamiast 0.5sek na dwa kliknięcia, około 2 sekund, aż zobacze co jest na 12, który mnie nie interesuje, do tego czasu dekoder ignoruje, lub nie, wciskanie klawiszy. Kończysz na powolnym wciskaniu co kanał "up" i czekania za kazdym razem na sygnał.

Wciśnięcie "13" wymaga spojrzenia na pilota i też trwa, bo jeszcze enter.

Zauważyłem, że szybko dostosowuje się do obsługui "cztery w górę" niż do pamiętania cyferek.

Nikt nie twierdzi, że lekkie. Po 17 latach męczenia jako dev komercyjnego UI, coś niby potafię w tym temacie, ale to jeszcze nie jest moment kiedy mogę powiedzieć "wiem jak to zrobić".

Widocznie przeładowuje 7 róznych biblitek obsługi XMLa. Gdzieś widziałem zdekompilowaną jakąś aplikację bankową z takim felerem jako przykład do czego doprowadza oszczędzanie i outsourcing. Każda część pisana przez "kontraktorów", używała innej. Zlepili gumą do żucia. Bank bodaj hiszpański.

Tak, na serwerze.

W obu przypadkach jest inny feler: aby zabezpieczyć prywatne dane, oba programy (outlook i teams) działają - fanfary - w emulatorze androida. Który allokuje sobie solidne GB na starcie. Taka rekurencja.

W przypadku Androida narzekam na obiektowców.

Ja ogólnie narzekam.

Taka narodowość.

na stronie 87 masz rozpisane. Jedna pionowa linia dociera do dwóch pixeli, a dwie poziome linie wybierają co drugi - stąd ten "dual gate". Jakos zrównoważyli ilosc linii sterujących.

J.