Szomorú, de igaz...

Forrás: https://9gag.com/gag/apmvj4M

De az igazán szomorú dolgok a komment szekcióban kezdődnek....

( fastlemon | 2018. 11. 14., sze – 23:11 )

Már megint ez a régen minden jobb volt.... és egyébként van ami igen, de ezt ugye az nem érti aki nem találkozott vele, nem ebbe született, hanem ahogy hajbazer mondaná: tapicskoló Tamások. És persze lehet ezt támadni, hogy mindez hülyeség, aztán majd meglátjuk kit igazol az idő.

( anr | 2018. 11. 15., cs – 07:26 )

amíg a kijelzők nem érik el az emberi érzékelés határát, addig folytatódni fog ez a trend, mert az az érv, hogy az "én oldalamon/játékomban szebbek a képek" könnyen bizonyítható lesz, és sokan ugy érzik, hogy akkor az a "jobb"

--
Live free, or I f'ing kill you.

( SzBlackY | 2018. 11. 15., cs – 07:33 )

Pedig tényleg "csak" megváltoztak az igányek (lásd: vesd össze az eredeti NES HW-t mondjuk egy Wii-u-val).

Egyébként meg ajánlom az AGDQ TASBlock szekcióit, ha meg akarod nézni, hogy még ma is mi mindent ki lehet hozni NES-ekből/SNES-ekből (spoiler alert: két NES és egy SNES már 10 fps-el sztereó hangú videót tud lejátszani (szigúran 256 szín mellett, persze), ha elég gyorsan böködöd az azt hiszem összesen nyolc kontrollert :) [kontroller portokon adod nekik a két hangsávot és a videó feedet], kis scripteléssel és plusz egy géppel még Skypeolni is lehet róla)

Egyébként sok ilyen egyszerű gazdasági döntés, értsd: jóval drágább lenne máshogy csinálni. Valamelyik AGDQ TASBlock videóban mondja dwangoAC, hogy az NES Classic gyakorlatilag egy Linuxos gép, rajta egy open source emulátorral - a kontroller bemenethez meg XBox kontrollernek megfelelő inputot adnak neki, amit utána az emulátor alakít vissza NES inputra. Valszeg azért, mert ilyen vezérlőt levettek a polcról, NES kompatibilist viszont (mivel gyakorlatilag nincs rá piaci igény) maguknak kellett volna építeniük... És akkor: melyik lenne a jobb, ha még pár mérnökhónapot beleölnek, hogy legyen egy saját kontroller chipjük, hozzá szoftverük stb. és megnövelik a gyártási költségeket (még egy "csak erre lesz jó" alkatrész), vagy az, hogy taknyolnak egy kicsit szoftveresen pár ezer utasítás árán?

Szerk.: AGDQ 2017 TASBlock a Skype

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( cherockee v | 2018. 11. 15., cs – 07:50 )

webesként mondom, amit egyesek javascript-ben megvalósítanak, attól sírok, amikor gyakorlatilag egy híroldalt látok, de felzúg a ventillátor, akkor tudhatom, hogy vagy bitcoint bányászok én, vagy a programozók gyöngye épp a szemem színét is elmenti, vagy csak annyi rohadt reklámot kezel az oldal, hogy ...

szóval az a röhej, hogy hülyeségekre megy el a kapacitás, mint a flash-nél volt az agyatlan animálás.

A reklámok katasztrofálisak, és ez ráadásul legtöbbször nem az adott fejlesztő hibája. Nekem is van olyan projektem, ahol ügyfél leszerződött az egyik legnagyobb reklámcéggel, küldték a JS-t, hogy rakjuk be.
Megtettem, az oldalbetöltés nagyságrendekkel lassabb lett, plusz a mérete is a többszöröse lett. Egy animált banner pl. van, hogy több száz kis PNG-ből van összelegózva, külön-külön kéréssel betöltve.

( muszike | 2018. 11. 15., cs – 08:41 )

Lehet gyorsan is böngészni.
Pl. Emacs , browse-url
Garantáltan nincs Javascript. Van szöveg, kép.
Villámgyors! :)

( barii | 2018. 11. 15., cs – 09:09 )

poennak jo, de a valosag az, hogy azert nincs penge optimalizalas, mert nincs ra szukseg, ami jo

Elvileg egy mai fordító vagy akár egy futtatórendszer, mint a JVM is elég sokat tudna optimalizálni. Igazából, amire ma használjuk a gépeket, az már 2000-ben is megvolt. Nőttek ugyan a felbontások, gyorsabb lett a hálózat, de azért tényleg röhejes, hogy mennyire vergődik néha egy mai gép is ugyanazokkal a feladatokkal, amire 20 éve is már használtuk. A mai programok többségének SSD nélkül is be kellene villannia, nem pedig a homokkört nézegetni fél percig.

PS: Ok, hogy nagyobbak lettek az igények, de olyan oprendszert miért adnak ki, amin még mindig be tud fagyni a kezelőfelület? Miért nincs valami normális QoS féle, ami rendesen elsőbbséget tud adni a kezelőfelületnek és a programok indításának? Trükköznek kompozitorral, mindenféle super/hyperfeccsel, itt van már az NVMe is, de néha még ezek is kevésnek bizonyulnak.

"Miért nincs valami normális QoS féle, ami rendesen elsőbbséget tud adni a kezelőfelületnek és a programok indításának?"

Mert multithread UI-t írni olyan feladat, amire jellemzően nem vállalkozott senki. Taskok async végrehajtása viszont implementációs kérdés.

Egyébként nem értem a sok picsogást. Emlékszem még az MSVC6 1-2 perces indulására. Vagy amikor 20 éve 1 percet vártam a Word, Excel indulására. Most egy VS2017 nekem 4 mp alatt indul az Excel meg 2 alatt.

De web is: azért emlékszem még, milyen volt softmodemmel netezni, amikor mindenre kurva sokat kellett várni. Amikor 3 hétig töltöttem egy 87 megás SDK-t és mikor 92%-nál jártam kezdhettem előröl az egészet, mert leszedték annak apropóján, hogy kijött az egyel újabb. Ésatöbbi.

Szóval hagyjuk már ezt a régen minden jobb volt picsogást mert szimplán hazugság. Igen, van pár szarul optimalizált honlap. De hogy minden jobb lett volna? MUHAHAHAHAHAaaaaaaa.... Egy nagy büdös lópikulát.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem csak a renderelésből áll egy UI kirajzolása. De egyébként adatvizualizáció esetén már jönnek az érdekesebbnél érdekesebb dolgok, főleg, ha hozzáveszed, hogy nem csak megjeleníteni kell, hanem mondjuk picit komplexebb layout kezelés és interaktívitás is kell.

Ne abból indulj ki, hogy egy játék egy célfeladatban egy célhardver sebességével mit tud megoldani év(tized)nyi fejlesztés után.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Van bármi fogalmad arról, hogy hogyan néz ki manapság bármelyik UI library? Tudod, amelyik komponensekből pakolássza össze a dolgokat, vannak neki eseménykezelői, meg stb. stb. stb.

Egyébként hiába teszed ki egy külön threadba, attól nem lesz reszponzívabb az UI. Mert ugyanúgy vársz rá, hogy rajzoljon valamit.

Meg egyébként is, amikor UI-t rajzolsz, nincsenek neked FPS-ek meg 16 ms-eid, hanem az UI-dnak egy aktuális állapota van. Eleve nem is rajzolod újra addig, ameddig nem kell.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Bevallom őszintén legutóbb winforms-al csináltam UI-t. Akkor már volt az xaml alapú izé is, de nem éreztem rá késztetést hogy az adott feladat miatt megtanuljam.

"Egyébként hiába teszed ki egy külön threadba, attól nem lesz reszponzívabb az UI. Mert ugyanúgy vársz rá, hogy rajzoljon valamit."

Pont hogy nem. Amíg nincs kész a thread, addig repaint-kor az előző bitmapet mutatom, így reszponziv marad.

"addig repaint-kor az előző bitmapet mutatom, így reszponziv marad."

Igen, valószínűleg kurva reszponzívan fog hatni az, hogy ha arrébb akarsz húzni egy jó nagy gráfban egy elemet, akkor hosszú-hosszú másodpercekre elmegy egy háttérszál rajzolni egy jó nagy bitmapet ;) Hiába mutatod az előző statikus bitmapot, ha azon aztán baromira nem fog semmi se reszponzíven válaszolni neked.

Egyébként a mindenféle vakvilágba indított thread helyett .NET-ben már ott vannak a Taskok vagy méginkább az async azóta. Sokkal lightweightebb és az utóbbi a callback hell és kézi dispatcheolás helyett elég olvasható kódot is eredményez.

XAML szintén elég nagy előrelépés a deklaratív UI-jával, binding rendszerével meg azzal, hogy többmindent tol át GPU-ra, mint a régi WF.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A fordító nem tud lényegében optimalizálni, hanem csak annak a végrehajtását tudja kicsit alakítani, ami le van írva. Tehát ha valami algoritmikusan rosszul skálázódik, azzal a fordító semmit sem tud csinálni.

Például mostanában találtam egy olyat, hogy egy fa elemeit úgy frissítettem be, hogy minden egyes frissítésre újralayoutolt a teljes GUI. Ha nem mér a fejlesztő, akkor kb 200 faelemig (lehet, hogy csak 50, a lényeg, hogy sok) észre sem vesz ezt a problémát. Felette viszont elkezd a négyzetes lassulás érezhetővé válni. Ilyen jellegű hibákat nagyon könnyű véteni - annál könnyebb, mennél több layer van alattunk. Aztán ha nincs igény és pénz, akkor sosem lesznek ezek javítva, és szívnak a userek. Például ezt sosem lehet fordító szinten optimalizálni, mert a programnak azt kell csinálnia, ami le van írva, az meg az, hogy magában számolgasson mindent újra 10000szer :-).

Egyébként a legtöbb feladat ma tényleg olyan, hogy ha csak egyszer hajtanánk végre, akkor valóban beleférne 16ms-ba :-).

( HalfDemon v | 2018. 11. 15., cs – 10:44 )

Tudom persze, hogy csak okoskodás, és tényleg régen minden jobb volt, de azért a felbontás is számít...

--
"Biztos én vagyok a béna, de csak azt sikerül elérnem, hogy kikapcsol a monitor."

( Gyuszk v | 2018. 11. 15., cs – 11:21 )

A web tényleg fos (véleményem szerint a szakma szégyene), de jó dolgokra is lehet ám használni ezt a hardveres kapacitást.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

( Honkydoo v | 2018. 11. 15., cs – 16:07 )

Van benne igazság ez kétségtelen.
De azért az is tény, hogy nem pont úgy használjuk a webet ma, mint 1990-ben használták.
Az igények is nőttek. (És itt nem az egyes oldalak színvonalára gondolok most) Nagyobb felbontás -> nagyobb képek -> videó és hang a weboldalon (egyszerűen lejátszható módon) -> és amit még kihagytam

Persze ettől még lehetne optimalizálni jobban. (gondolom én, mert már nem fejlesztek webet jó ideje) De érdemes belegondolni abba is, hogy a "mérleg másik serpenyőjében" is van valami.

( nan | 2018. 11. 19., h – 16:23 )

Oké, de...
sokkal körülményesebb volt az adatszolgáltatás az NSA, FSZB, Black Cube vagy bárki másnak.