-
PROHARDVER!
JavaScript != Java (A JavaScript nem összekeverendő a Javával, két különböző programozási nyelvről van szó!)
Új hozzászólás Aktív témák
-
martonx
veterán
A javascript egy nyelv, ami futhat kb. bármin. Azaz windows-on .exe-ként. Viszont rohadtul nem mindegy, hogy milyen kontextusban fut, milyen API-khoz fér hozzá.
Azaz legtöbb mindenhez akkor fér hozzá, ha win32-n fut (.exe vagy pl. Electron app, Nodejs mint szerver, vagy bármibe csomagolhatod, ami neked megfelel és az OS api-jaihoz hozzáférést ad).
Szintén elég sok mindenhez hozzáfér, de azért már valamivel korlátozottabban, ha Chrome kiegészítőként fut a böngészőben (lásd a linkelt példád).
És szinte semmihez nem fér hozzá, ha tisztán böngészőben egy html oldal részeként fut (kivéve a fentebb linkelt webusb preview api-t).Remélem ezzel rávilágítottam a kontextusok közötti különbségre. És előre is bocsánat, ha a válaszom bármilyen pontatlanságot tartalmaz.
-
martonx
veterán
"és hátha valóban ez a jó megoldás" - nem hátha, hanem ez az egyetlen jó megoldás. Ez egy publikus topik, amellett hogy segítünk, én legalábbis arra is próbálok odafigyelni, hogy ne szerepeljenek hülyeségek, tévutak, másokat ne vigyenek félre hülyeségek, még ha valakinek éppen nagyon be is csípődött a saját ötlete (ami önmagában elvi szinten nem is lenne hülyeség, csak épp megvalósításkor minden elvi előnye el is úszna).
CDN-re nem kell sokat találgatni, valamelyik nagy felhő providernél be kell regelni, és elkezdeni használni. AWS, Azure, Google Cloud mindegyik tud CDN-t, és ezek mindegyike sokáig velünk lesz még szerintem. És ahogy mondtam a te szinteden ingyenesek, majd ha lesz napi több ezer látogatója az oldaladnak, akkor elkezdhetsz fizetni havi 1-2EUR-t nekik a CDN-ért. Regisztráció után X ingyenes keretet szoktak adni 1 évig, szóval nyugodtan próbáld ki, első hónap után látni fogod, hogy normál esetben mennyit kellene fizetned (tippre a te felhasználásoddal csak CDN esetben nullát).
-
martonx
veterán
Erre való az image srcset How to Use HTML5 “picture”, “srcset”, and “sizes” for Responsive Images (tutsplus.com)
Felejtsd már el a hálózati sebességet, lényegtelen. Valahogy nálad ez csípődött be, könyörgök felejtsd el!
Egy dologra kell figyelj, hogy a képernyő felbontásának megfelelő méretű képet add oda, és akkor mindenki boldog lesz.
Ha kicsi a képernyő (értsd mobil), akkor annak egy kicsi kép fog menni, ha nagy a képernyő, mert desktopon nézed, akkor annak egy nagy kép fog menni.
Egyébként is, attól, hogy valakinek lassabb a netje, még nem fogsz minden képet 32X32 pixelesen küldeni, hogy is nézne már ki. Meg ő tudja is magáról, hogy szar a netje és türelmesen kivárja
A linkelt példa szerintem egész jól bemutatja, elmagyarázza.
-
martonx
veterán
Továbbra is azon a véleményen vagyok, hogy maximálisan értelmetlen sebességet mérned, pláne ha ezzel a célod a betöltés gyorsítása
mivel a pagespeed a plusz js szüttyögés miatt még le is fog pontozni, miközben a probléma az, hogy ha meg akarsz jeleníteni egy 460X230-as képet, akkor nem egy 2Mbyte-os 4K-s képet kellene lerángatni netről, hanem egy 20kbyte-os pontosan 460X230-asat.
És ezen nem fog semmit segíteni, hogy te page initnél pár másodpercig hálózati sebességet méricskélsz, hogy eldöntsd majd hogy, mekkora képet szolgálj ki.
-
martonx
veterán
Jól érted, pont ezt kell csinálnod. Szerver oldalon (ami most esetedben PHP) letöltöd, de nem tárolod, csak kiszolgálod a kicsire átméretezett képet.
És itt jön a történetben a csavar, hogy a rendszered fölé teszel egy CDN-t, ami egyébként kb. ingyenes, legalábbis ahhoz egész nagy terhelésednek kell lennie, hogy elérd a havi 1EUR-os fizetendő díját.
Azaz ez benne trükk, hogy te ezt tényleg nem fogod tárolni, ezt megoldja helyetted a CDN -
martonx
veterán
Az teljesen mindegy, hogy a képek sajátok-e, és te tárolod-e őket
A link alapján le tudod szedni, át tudod méretezni, és vissza tudod adni a megfelelő méretben.
A böngészőnek küldött html-ben nem az lesz, hogy<a href="https://kulsodomain.com/ezegykulsokep.jpg">hanem az hogy<a href="https://azenoldalam.hu/kepatmeretező?width=460&heigh=230&source=https://kulsodomain.com/ezegykulsokep.jpg"> -
martonx
veterán
Rosszul közelíted meg. Mindig éppen akkora képet adj vissza, amekkora kell, semmivel se nagyobbat. És igen, ehhez kelleni fog némi backend, amivel ezt megoldod, hogy mindig tökéletesre méretezett, optimálisan tömörített képet tudj szerezni.
Semmi értelme nincs tesztelgetni a kliens sávszélességét. -
#8356
martonx
veterán
Prog-Szerv
#8355
martonx
veterán
válasz
Prog-Szerv
#8355
üzenetére
Mert ez az agGrid.simpleHttpRequest csak egy segédlet. Azaz simán le tudod ehelyett fetch-el kérni az adatokat, aminek úgy adsz át paramétereket, ahogy akarsz
-
#8354
martonx
veterán
Prog-Szerv
#8352
martonx
veterán
válasz
Prog-Szerv
#8352
üzenetére
client side, és minden ajaxot használ a mai világban
-
#8350
martonx
veterán
Prog-Szerv
#8349
martonx
veterán
válasz
Prog-Szerv
#8349
üzenetére
Pont ott van a javaslatom az ag-grid, amit immár évek óta elégedetten használok. Bár ez meg néha már egy kicsit overkill
még az ingyenes verziója is félelmetes tudású. -
#8348
martonx
veterán
Prog-Szerv
#8347
martonx
veterán
válasz
Prog-Szerv
#8347
üzenetére
Hopsz, ezt benéztem, ez aktív fejlesztés alatt van. Ettől függetlenül számomra, amihez jquery kell, az "no way" kategória
Pl. ott van az ag-grid, legutóbb, amikor jquery nélküli datagrid-et kerestem (2017-ben, ez se most volt, de ez a DataTables már akkor se jöhetett szóba ), akkor botlottam bele, szvsz egész komoly tudású. -
#8346
martonx
veterán
Prog-Szerv
#8345
martonx
veterán
válasz
Prog-Szerv
#8345
üzenetére
Szia!
Biztos, hogy egy ezer éve nem használt datatables megoldásra akarsz átállni?
-
martonx
veterán
válasz
nevemfel
#8343
üzenetére
Én már elengedtem, mindenkinek nyugodtabb, ha elengedjük. Ő meg majd átgondolja, és rájön, hogy az egészet koncepcionálisan rontotta el / végső kínjában csak csinál egy jsfiddle példát, amin keresztül aztán 5 perc alatt megoldjuk a problémáját, több napos, mindenki idegeit tépő vergődés helyett
-
martonx
veterán
válasz
lanszelot
#8329
üzenetére
OK, akkor röviden, tömören: ezt így nem lehet megcsinálni
, bár végülis szegről-végről ez már elhangzott párszor, csak nem vagy hajlandó elfogadni.De aztán ne legyen az, hogy 3 nap múlva kiszenvedsz valamit, és az orrunk alá dörgölöd, hogy márpedig meg lehetett csinálni, miközben amit kiszenvedtél, nem is arra vonatkozott, amit kérdeztél
-
-
-
martonx
veterán
"Ha behúzzak egy keretet abból esetleg 9-et csinálni, 9-et nyertem, de a keret +30, hogyan jön ki a matek?"
Elképesztő magabiztossággal tudsz butaságokat írni még mindig
Szórakoztatsz
A matek úgy jön ki, hogy jó szokásod szerint megint nem néztél utána, hogy miről beszélek. Webpack, Rollup: ezek nem js libek, hanem js task runnerek, ezeket nem behúzni kell, hanem ezeken át kell futtatni a kódod, és csinálnak neked js bundle-t, minifikálva.
De mindegy is, te úgyis jobban tudod, hogy mit hogyan csinálsz -
martonx
veterán
Ahogy látom a JSCompress Uglify3-at használ maga alatt, ami ES5-re fordít. Ha te ES5 felett írtad a kódodat, akkor belefordíthat egy csomó polyfil-t. Használj normális webpack, rollup akármilyen js task runnert, amiknek van beépített js bundle - minifikátora is. Azok valószínűleg valamivel kisebb js-t fognak tudni csinálni, bár csodák nincsenek, a 41kbyte-ból sosem lesz mondjuk 5kbyte
-
martonx
veterán
Ez esetben a GDPR-nek semmi dolga nincs a localstorage-el, hiszen te saját magad nem tárolsz semmilyen adatot. A user saját gépén tárolódik a saját geolokációs adata, aminek engedélyezéshez kap is a böngészőtől felugró ablakot, szóval nyugi.
Akkor lenne mindez érdekes a GDPR szemszögéből nézve, ha ezt az adatot magadhoz továbbítanád, és mondjuk a saját adatbázisodban minden egyes userhez letárolnád.
Nem kell ezt túllihegni. -
martonx
veterán
válasz
kw3v865
#8218
üzenetére
ES6 module syntax-al kell megírnod a javascriptedet, és valamilyen csomagolóval compile-olni a kimenet javascriptet a cégén. PL. webpack erre a legelterjedtebb.
Elsőre zavarónak hathat, hogy compile-olni kell a javascriptet, de ha belejössz, akkor már tök természetes lesz, miközben van egy csomó előnye ennek a megközelítésnek. -
-
#8114
martonx
veterán
BigBlackDog
#8113
martonx
veterán
válasz
BigBlackDog
#8113
üzenetére
Pure Js-ben is van class, és öröklés. Interfész, és erős típusok nincsenek. Kb. ennyi a különbség TS és JS között.
-
#8109
martonx
veterán
BigBlackDog
#8108
martonx
veterán
válasz
BigBlackDog
#8108
üzenetére
Ez rajtad múlik. Simán elég lehet egy sima tsc fordítás, de simán lehet, hogy webpack fog kelleni.
-
martonx
veterán
The Wasm stack machine is designed to be encoded in a size- and load-time-efficient binary format. WebAssembly aims to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms.
Jobban utána olvasva, nem a js engine-en fut. Ugyan nem ismerem a konkrét implementációt, de gondolom, akkor tud natív sebességgel futni, ha valahol mélyen fut, minél közelebb a vashoz.
-
martonx
veterán
Konkrétan pl. így működik: https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
Megírod C#-ban a kódot, ami webassembly-re fordul, amit viszont az újabb böngészők pont ugyanúgy tudnak futtatni, mint pl. a javascriptet (igaziból jobban is futtatják, mert ez assembly, azaz mélyebben fut, több optimalizációt tartalmaz a befordított kód). Böngészőben futó erőforrásigényes 3D-s játokoktól indult ez el, mostanra meg ott tartunk, hogy csomó esetben ki lehet váltani vele a javascriptet (talán egyedül SEO kritikus webalkalmazások az egyetlen eset, ahol eszembe se jutna több megás dll-eket a böngészővel letöltetni, futtatni).
-
#8032
martonx
veterán
instantwater
#8031
martonx
veterán
válasz
instantwater
#8031
üzenetére
Szerintem meg semmivel nincs összemarketingelve, történelmi beágyazottsága van. Az angular 1.X volt az első komolyan vehető js mvvm framework, még ha szar is volt, mint a bűn. Ez jutott el a tömegekhez, márpedig a nagyvállalatok nem egykönnyen váltanak. 2.X-től kezdve meg typescript alapokra váltott, ami nyilván az erősen típusos C#, Java fejlesztőknek lehet szimpi (legyünk őszinték, sok helyen ugyanaz az ember írja a backendet és a frontendet, és egy C#/Java backend mellé gyakran elég erős váltás egy típustalan JS), még ha szvsz az angular továbbra sem jó, vagy legalábbis vannak jobb alternatívák nála (mint a feljebb említett vuejs, de a react is teljesen élhető az utóbbi időben).
-
#7999
martonx
veterán
instantwater
#7996
martonx
veterán
válasz
instantwater
#7996
üzenetére
Én ezt mind megértem (első kézből tapasztaltam is), de elfogadni sose fogom. Ezért is hagytam ott a pénzügyi szektort, és nyergeltem át a startup szektorra. Majd 60 éves koromban ráérek visszamenni valami szakmai elfekvőbe, ahol nyugdíjba menetelemig ímmel-ámmal eltaszigálom a régi szarokat, mindenbe magasról szarva.
-
martonx
veterán
Pedig hidd el, valahogy azt a rengeteg webáruházas vásárlást el kell tudniuk juttatni az áruházaknak a megrendelőkhöz, és napi több százas megrendelés számoknál már senki nem adminisztrátorokkal viteti fel a csomagokat a futár cégek rendszereibe. A GLS-t épp csak azért hoztam fel példának, mert rohadtuk büszkék az annyira új, hogy még csak teszt fázisban lévő, szerintük, hiper-szuper modern API-jukra
ó, most ezt így megint leírtam, megint össze kell kaparnom magam, hogy folytatni tudjam. Vitázhatunk mi itt GraphQL-ről, hogy csak pici előrelépés és az is csak marginális esetekben, vagy evolúciós lépés, és nélküle már API-t írni sem érdemes, miközben a világ 99%-ban a GLS-hez hasonló cégekből áll, akik simán 15-25 év lemaradásban vannak minden téren. GLS most épp az új rendszerével a 25 éves lemaradását dolgozza le csak 15 éves lemaradásra.Egészen elképesztő, amit európa legnagyobb csomagküldő szolgálata, API, meg úgy általában IT részen művel.
A csomagpontos térkép integrációjuk is megér egy misét, ES5-ös jquerystől, meg global namespace-estől... Komolyan ennél még az is jobb lenne, ha iframe-et adnának, és leírnák, hogy mi az az egy postmessage event, amire fel kell íratkozni a csomagpont kiválasztásához.
Én konkrétan úgy integráltam a csomagpontjukat, hogy néhol bizony bele kellett nyúlnom a forráskódjukba, és mi magunk hostoljuk a kódot, pedig ez így nem túl szabályos, ahogy arról se értesülünk, ha közben kiadnának új verziót (mondjuk tekintve, hogy ránézésre 10 éve nem nyúltak a js-ükhöz, ettől félek a legkevésbé). -
#7992
martonx
veterán
instantwater
#7991
martonx
veterán
válasz
instantwater
#7991
üzenetére
Félreértettél, nem a kliens implementációról beszélek (azt majd intézi mindenki magának), hanem a szerver implementációról. Én azon röhögök / sírok, hogy .Net fejlesztőként simán látom, meg tudom ítélni, hogy milyen .Net verziót használnak (elég megnézni az Endpoint url szintaktikájukat például, vagy látni, hogy olyan json serializációs hibák vannak a rendszerükben, amik még az ősi .Net Framework 4.5-nél voltak). Pont ugyanezen elvek mentén pedig csukott szemmel is ráismerek a 90-es évekbeli vb scriptes classic ASP-s SOAP endpointokra.
Nyilván bárki bármilyen nyelven kapcsolódhat hozzájuk, nem erről van szó, se nem érdekel a kiadott példa kódok, példa kliensek nyelve.
Arról van szó, hogy egy vadiúj fejlesztésnek hogy lehet .Net 4.5-tel és WCF-el nekiállni manapság, és ráadásul az elkészült produktumot hogy lehet legkorszerűbb eszközöknek hazudni. -
#7990
martonx
veterán
instantwater
#7988
martonx
veterán
válasz
instantwater
#7988
üzenetére
"Lehet, hogy az alkalmazásodnak az adott lekérdezésből mindössze 2-3 mező kell, de az adattípus 10-20 mezőt tartalmaz, esetenként még néhány mező tartalmaz további elemeket (tömb/objektum).
Ez egy nagy eredménylistánál sok adatot jelent, amivel nem terheled a lassú 3/4G hálózatot.
Valamint a GraphQL támogatja több lekérdezés összefűzését, így egy roundtrip latencyvel megúszod ami hagyományos REST APInál 2-3-4 lekérdezés lenne 2-3-4x roundtrip latencyvel, és a felhasználónak minden századmásodperc számít."Ez így elméletben tök jól hangzik, gyakorlatilag, amikor saját SPA alá REST API-kat írunk, eddig se küldtünk ki minden szemetet, csakis azt, ami kellett. Más kérdés, hogy 3rd party API-knál ennek lenne létjogosultsága, viszont 99%-ban pont ők azok, akiktől FTP-n csv-ben tudod leszedni az adatot...
A több lekérdezés összefűzése elméletben faszán hangzik, gyakorlatban meg plusz js komponenseket kell használni, hogy az ember megspóroljon pár (lehet, hogy épp semennyi) roundtrip latency-t.. Miközben a plusz js letöltésének, feldolgozásának is van ideje.
No mindegy, mondom a koncepciót értem, azt az őrült nagy hozadékát nem érzem, mint anno amikor egy full fos, senki senkivel nem kompatibilis SOAP-ot, vagy FTP-s csv API-kat, leváltotta a Rest API.
Sajnos viszont a gyakorlat nálam is azt mutatja, hogy például a GLS most szuper büszke az újonnan elkészült új API-jára idézem: legkorszerűbb eszközök alkalmazásával jobb felhasználói élményt biztosítunk.
Na ez az új interfészük ősi .Net Framework 4.5.2-vel készült, WCF technológiával, ami olyan 2005 táján volt menő. Jó, mondjuk ahhoz képest, hogy az előző (mármint a jelenleg használt) API-juk meg VB scriptes classic ASP-s volt, ahhoz képest végülis ugrottak az időben 10 évet előre. -
martonx
veterán
Nincs sok (sőt igaziból minimális) tapasztalatom a GraphQL-el. Felhasználóként egyszer kellett integrálódnom GraphQL API-hoz. Hangsúlyozom felhasználóként semmi előnyét nem éreztem, sőt macera volt plusz libeket behúzni a GraphQL miatt, miközben pont ugyanúgy adatot kellett belőle kinyerni, mint bármilyen REST API-ból.
Ugyanakkor értem a koncepcióját, egy a GraphQL API-val szorosan integrálódó frontendnél lehetnek előnyei, így viszont ahogy nekünk kiajánlották, és sima GET-tel leszippantottuk az adatot, teljesen felesleges bonyolításnak tűnik.
Hogy fejlesztői oldalról nézve milyen előnyei lehetnek a GraphQL-nek, arról abszolút nem tudok nyilatkozni.
Mindenesetre a fenti tapasztalat alapján nem éreztem azt, hogy hú rohanok a REST API-jaimat lecserélni GraphQL-re mint pl. a 2000-es évek elején, amikor a borzalmas gané SOAP-ot (meg FTP-s csv-ktől kezdve már nem is emlékszem mi minden szart) végre le lehetett váltani rendes Json Rest API-kkal. -
-
martonx
veterán
Nem kétlem, hogy valamicske időt belefektettél a kódok innen-onnan összegubrincsolásába. Viszont szerintem te is látod, hogy ez nem egy olyan egyszerű dolog, mint megtanulni fát vágni. A kérdésekkel semmi baj nincs, amint azok egy fórum keretein belül pár mondattal, pár sornyi példa kóddal megválaszolhatóak.
Esetedben viszont nem ez a helyzet. X órát elszórakoztál netről innen onnan leszedett cuccokkal, és most ezeket mutogatva várod, hogy valaki csinálja meg (mert azok a kódok simán kukázhatóak, nem 1-2 sorral van bennük baj, hanem koncepcionálisan), magyarázza el, tanítson meg téged. Ez így nem fog menni.
Mindenesetre ha utána nézel a Fetch API-nak, async, await-nek, Promise-nak, akkor meg fogod tudni oldani amit szeretnél.
-
martonx
veterán
Nyilván, csak amit látok, hogy még az időt se fekteted bele. Majd amikor jól felkészült összeszedett, működő jsfiddle, codepen, bánomisén milyen példákkal jössz, akkor lesz értelme az akár hülyének is tűnő kérdésekkel foglalkozni. Gyanítom mire megcsinálnál egy ilyen működő példát, közben utána olvasnál kényszerűségből ennek annak, hirtelen tárgytalan lenne a kérdésed is. Mert ez így csak időpocsékolás, hogy hirtelen kell neked valami, de olyan hirtelen, hogy értelmesen még kérdezni sincs időd. Ráadásul olyan ez mintha egy atomfizika topikban elkezdenéd kérdezgetni, hogy na és akkor hallottam, azokról az atomokról, erőművet szeretnék építeni, írjátok már le pár sorban gyorsan, hogy mit és hogy, 5 percem van rá, lehetőleg ne kelljen semmin módosítanom, csak átemelem a leírást, és máris termelje az áramot.
Az meg, hogy ki mit csinál főállásában, és kinek mire van ideje, abszolút nem tartozik ide. Ha nincs időd ezzel foglalkozni, akkor ne foglalkozz
-
martonx
veterán
Szerintem egy fórumnak nem feladata (nem is lehet ilyen formában) nulláról megtanítani valakit programozni, aki ráadásul szemlátomást megoldást akar, nem tanulni. Hiszem, hogy a kérdéseid helyett, ha elvégeznél egy udemy javascript kurzust, vagy vennél egy minimális fáradtságot, és végigcsinálnál pár netes tutorialt, máris magadtól meglelnéd a válaszokat.
Vagy ha ennyire nem akarsz foglalkozni a témával, akkor fizessetek valakinek aki megcsinálja nektek amit szeretnétek.
-
martonx
veterán
Az remélem megvan, hogy a javascript a böngészőben fut, a PHP meg a szerveren
És ezek HTTP-n keresztül kommunikálnak egymással. Ergo semmi nem akadályoz meg téged abban, hogy Javascriptből adatot küldj a PHP-nak HTTP-n keresztül, és azt az adatot PHP oldalon Json-ként lementsd. -
-
-
martonx
veterán
"Datasetet? Úgy tudom azt én nem is használtam az első verziós kódban. Vagy de?"
Hát éppen ez az, hogy nem használtad, de nagyon kellett volnaES6-7-2020-nak nézz utána, mert ez a jelen, az ES5 a rég múlt, ami a jquery-vel együtt elmúlt.
Elhiszem, hogy nem te találtad ki a myfunction nevet, de ha ez egy open popup-ot csinál, akkor illene e szerint elnevezni, ahogy fura módon a close popup egész értelmes név volt. -
martonx
veterán
Jim-Y is összeszedett párat, amin alapból kiakadtam, hogy jsfiddle-nek a html részébe erőltetted bele a javascriptet
Aztán a js-ben dataset-et nem használtad jól. Meg klasszikus es5 js volt, ami így 2020-ban, nem borzalmas, csak nem jó látni. Béna metódus elnevezés (MyFunction WTF?), meg igaziból kb. minden sornál meg lehetett volna állni, és kifejteni, hogy mi miért nem jó úgy ahogy van.
Ettől függetlenül persze működött, és tudjuk: "A működő kód, jó kód". -
-
martonx
veterán
Nagyon dícséretes! És miért utálod a jsfiddle-t? Amúgy meg ott van a codepen.io mint alternatíva, ha az jobban bejön
Én totál leszarom, hogy mit használsz, de lássuk be rengeteg eset van, amikor működő, más által is módosítható kódot kell mutatni a segítség kéréshez, márpedig erre nem tudok jobb alternatívát ezeknél.
A kódod egyébként borzalmas, de legalább működik, és jquery mentes.
JQuery-t 2020-ban használni emberiség ellenes bűntett -
martonx
veterán
válasz
K1nG HuNp
#7789
üzenetére
"es volt valami elegancia abban hogy felpakolsz egy php filet ftpre es fut es atom gyors 123kB js nelkul is" - a PHP előnyei kb. itt meg is állnak
Amúgy meg a server side rendering mindig is nagyságrendekkel gyorsabb volt, nem véletlenül erőltetik majdnem mindenhol az SSR-t. -
martonx
veterán
válasz
Tomi_78
#7772
üzenetére
Két dolog:
1. tanuljuk már meg végre, hogy mi a különbség a let és const között
ez a halálom, amikor valaki a legalapabb dolgot is fogalmatlanul használja.
2. nekem ez a megoldás sokkal szimpatikusabb: https://stackoverflow.com/questions/19764018/controlling-fps-with-requestanimationframe minden olyan megoldástól a hideg kiráz, ami animációval kapcsolatos és settimeout / setinterval van benne. Ezt a megoldás még kombinálnám annyival, hogy magát az animációt kiszervezném egy külön worker thread-be, mert ezekben az esetekben az a gond, hogy ha komplex az animáció / nagyon gyenge a futtató vas, akkor lehet, hogy több frame-et is át fogsz lépni, mint eredetileg tervezted. -
-
martonx
veterán
válasz
Tomi_78
#7741
üzenetére
a requestAnimation frame a képernyőfrissítéshez igazodik, nem a gép sebességéhez. Simán lehet, hogy a te gyengébb gépednek 120Hz-es kijelzője van, a másik erősebb gépnek meg 60Hz-es. Ebben az esetben nálad 120fps-t fog eredményezni a requestAnimationFrame, a másik gépen meg 60fps-t.
A SetInterval felejtős, teljesen megbízhatatlan.
requestAnimationframe-nél így tudod fixálni az fps-t, hogy mindenhol azonos sebességet adjon: https://stackoverflow.com/questions/19764018/controlling-fps-with-requestanimationframe
Nyilván fixálni csak lefelé tudod, azaz 60fps-től lefelé. -
#7686
martonx
veterán
hiperFizikus
#7685
martonx
veterán
válasz
hiperFizikus
#7685
üzenetére
Most igen, aztán ha 5 évig nem látod a kódocskádat, és 5 év múlva előveszed, hogy beleírj plusz egy funkciót, verni fogod a fejed a falba.
-
#7675
martonx
veterán
instantwater
#7674
martonx
veterán
válasz
instantwater
#7674
üzenetére
Hogy is szólt a híres tanács: "Sose nyomd fullba a kretént!"
Sajna mindig van, aki nem fogadja meg a tanácsokat -
#7622
martonx
veterán
hiperFizikus
#7621
martonx
veterán
válasz
hiperFizikus
#7621
üzenetére
paint.net?
-
#7600
martonx
veterán
hiperFizikus
#7597
martonx
veterán
válasz
hiperFizikus
#7597
üzenetére
7595-öt sikerül-e értelmezni? Hangot lehet js-el adni, hogy real time szabályozni is lehet-e, még sose próbáltam, én is csak ráguglizni tudnék.
-
#7591
martonx
veterán
Nagyzoli27
#7589
martonx
veterán
válasz
Nagyzoli27
#7589
üzenetére
Mert ez egy NodeCollection-t ad vissza, amit egy foreach-el be kellene járnod.
-
#7586
martonx
veterán
hiperFizikus
#7582
martonx
veterán
válasz
hiperFizikus
#7582
üzenetére
Tessék: https://jsfiddle.net/esf84dch/ remélem a megváltó könyvbe belekerülünk, mint angyalok
-
-
#7551
martonx
veterán
Nagyzoli27
#7550
martonx
veterán
válasz
Nagyzoli27
#7550
üzenetére
Array.from
-
![;]](http://cdn.rios.hu/dl/s/v1.gif)
pont erre való
Én totál leszarom, hogy mit használsz, de lássuk be rengeteg eset van, amikor működő, más által is módosítható kódot kell mutatni a segítség kéréshez, márpedig erre nem tudok jobb alternatívát ezeknél.
Új hozzászólás Aktív témák
Hirdetés
- Óvodások homokozója
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Milyen processzort vegyek?
- Milyen videókártyát?
- ldave: New Game Blitz - 2025
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Vicces képek
- Napelem
- OFF TOPIC 44 - Te mondd, hogy offtopic, a te hangod mélyebb!
- További aktív témák...
- LG 65C4 - 65" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - 1000 Nits
- 35" ASUS ROG Swift PG35VQ curved GAMER monitor
- LG 32GS95UE - 32" OLED / UHD 4K / 240Hz - 480Hz & 0.03ms / 1300 Nits / NVIDIA G-Sync / AMD FreeSync
- Bomba ár! Fujitsu LifeBook E754 - i5-4GEN I 8GB I 256SSD I 15,6" HD I HDMI I W10 I Garancia!
- ÁRGARANCIA! Épített KomPhone Ryzen 5 4500 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest