Új hozzászólás Aktív témák
-
floatr
veterán
Csakhogy most felhoztál egy olyan dolgot hasonlatnak, ami szvsz elég gyenge.
Ha már annyira "tesztelni" akarod a két VM hatékonyságát (mondjuk az elég nehéz lesz), akkor írj egy AS3/4-alapú és egy Java tesztalkalmazást, aztán mérjed ki őket. De akkor is hullafelesleges, mert még mindig nem ez a gond, hanem a sok okostojás, aki még időjárásmodellt is flashben szimulálna, vizualizálna.
[ Szerkesztve ]
-
ddekany
veterán
Nekem az fáj a flash és a HTML5 esetén is, hogy mindkettő alapvetően egy script nyelvre épít (JavaScript, ActionScript), amiket ráadásul nem is komolyabb méretű alkalmazások készítésére terveztek (ez utóbbira nem térek ki, mert a sebesség a téma, nem a karbantarthatóság). És hiába is gyorsítják orba-szájba őket, én nem hiszem hogy ezek valaha akár csak közel olyan gyorsak lehetnek, mint egy C/C++/Java vagy C#. Hiszen ott van a többi hasonlóan dinamikus script nyelv, amiket viszont eleve komolyabb méretű alkalmazások írására (is) terveztek, mint a Python, Ruby, stb, és hát ezek a mai napig lassúak a C vagy Java-hoz képest ha valami komolyabban CPU-t terhelő feladatról van szó. Egyszerűen a nyelvből adódóan több dolga van a CPU-nak ezek futtatásánál, bármilyen csodásra is írják meg a futtató környezetet. És a bosszantó az, hogy erre az egész problémakörre ezer éve van megoldás, mint a Java (JVM) és #C (CLR) esetén megmutatták: egy nyelv független rendes komoly virtuális gép. Pl. JVM esetén ha nyers számítási erőre van szükséget (és/vagy statikusságra) akkor ott a Java nyelv (vagy ha valaki valami modernebbet/innovatívabbat szeretnél, ott a Scala nyelv), ha inkább dinamikusságra, akkor ott a Groovy vagy a Clojure, stb. Ja, és a többszálúság támogatása, a normális memória kezelés (garbage collection) ezeknél mind természetes. De neeem... vegyük a JavaScript-et, és heroikus erőfeszítéssel toldozzuk-foldozzuk, amíg viszonylag használható nem lesz, és az akkor már "elég jó". Na, hát ilyen a piac... szép mi? Mert a grafika/hang hw gyorsítása az biztos menni fog hosszú távon, de hogy ezzel mit fognak kezdeni...
-
doc
nagyúr
miert lenne gyenge? adott ket (egymashoz raadasul hasonlo) nyelv, amibol bytekod fordul, ami egy VM-en fut, es eloszeretettel hasznaljak viszonylag kis felbontasu casual game-ek fejlesztesere. szerintem teljesen jogos az osszehasonlitas
hogy a DalvikVM-ben van HW gyorsitas a grafikahoz? a Flashnek ki tiltja meg hogy legyen? sot, a cikk reszben, es ez a topic eleg nagy reszben pont errol szola gond ... a sok okostojás, aki még időjárásmodellt is flashben szimulálna, vizualizálna.
ebben teljesen egyetertunk -
floatr
veterán
A múltkori topikot ezek szerint kihagytad, amikor a crakshaft-et mókoltam meg egy kicsit. Nem lassú Bár a Java-nak lenne ilyen sebessége...
(#104) doc amennyire én olvastam, inkább arról szólt, hogy VM-fika alapjaiban. Épp hogy nem a runtime illesztési hiányosságait nyilvánította mindenki fájdalmasnak, hanem magát a runtime-ot egy köpedelemnek. Tény, hogy mondjuk egy ogl binding hiányzik néha, meg hasonló okosságok, de az a nyomorult VM egyáltalán nem gáz.
[ Szerkesztve ]
-
doc
nagyúr
baromira nem arrol szol az egesz, hogy milyen szintaktikaval irsz le valamit. raadasul a JS es mondjuk a C# olyan orulten nagyon nem is kulonbozik egymastol (sokkal nagyobb a kulonbseg pl. az altalad emlitett Rubyval osszehasonlitva)
a VM nem az ActionScript 'nyelvet' futtatja, ill. a browser JS-motorja is leforditja a forrast. a HTML5 is hasznalhatna akar Perlt is, nem ez a lenyeg, hanem az hogy az engine hogyan valositja meg azt amit a kivalasztott nyelvvel elmagyarazol neki -
ddekany
veterán
"baromira nem arrol szol az egesz, hogy milyen szintaktikaval irsz le valamit"
Baromira nem is mondtam ilyet... Arról szól az egész, hogy egy ilyen virtuális gép többféle megközelítésű nyelvet tud támogatni, pl. statikus és dinamikus megközelítésű nyelveket is. A felsorolt nyelvek közt sem a szintaktika a lényeges különbség, hanem a megközelítésük más, máshogy támadod bennük a megoldandó problémát. Ebből adódik az is, hogy némelyik igenis gyorsabb lesz, hasonló minőségű megvalósítást feltételezve. Fejre is állhat akár mindenki, ez a belátható időn belül nem fog megváltozni. (Mert pl. hogyan eliminálod a futás idejű típus ellenőrzéseket vagy akár hash lookup-okat egy dinamikus nyelvben? Néha tudod statikus analízissel, de közel sem mindig.) És főleg, az hogy az ember a neki megfelelő nyelvet választhatja, szerintem igen sokat jelent. Nehogy már ennyi év után oda jussunk, hogy nem választhatok olyan nyelvet, ami adott problémára jónak látok, amikor webre programozok kliens oldalra... El lettem kényeztetve desktop és szerver oldalon mi? És persze, akár egy JVM-et is meg lehet valósítani tisztán JavaScript-ben, sőt szalagos turing-gépen is... de hát ne vicceljünk már.
[ Szerkesztve ]
-
doc
nagyúr
ok, igy mar ertem mire gondolsz, az elozo postbol ez nekem nem jott le
a nyelv problemahoz illo megvalasztasa teljesen jogos es nyilvanvalo igeny, de a web sok szempontbol specialis terulet, es egyre inkabb arra halad, hogy 1-2 kivalasztott nyelv letezzen. ott van a sokak altal agyonszidott es fikazott PHP, ami szinte egyeduralkodo lett a maga teruleten, kliensoldalra ott a JS. desktopon ezzel szemben meg ezrevel valogathatsz a nyelvek kozott
-
ddekany
veterán
"A múltkori topikot ezek szerint kihagytad, amikor a crakshaft-et mókoltam meg egy kicsit. Nem lassú Bár a Java-nak lenne ilyen sebessége..."
Na ne, na ne... azért ekkora csodákban nem hiszek. Miért lenne a JavaScript jobban optimalizálható, mint az összes többi dinamikus nyelv, főleg hogy ez egy durván dinamikus nyelv még azok közt is? A többinek nem sikerült (nem meglepő módon) elérni kb a C sebességét, most hirtelen sikerül? Állatira nem triviális az egyenértékű "statikus"/fixen-összedrótoztt kódot megtalálni egy script-hez... Java nyelv esetén viszont az, hiszen majdnem olyan merev, mint a C.
-
Sanya
nagyúr
a flash nem való semmire.
A bortól bolondokat gondol az ember, DE A PÁLINKÁTÓL MEG IS CSINÁLJA!!!
-
ddekany
veterán
"ott van a sokak altal agyonszidott es fikazott PHP, ami szinte egyeduralkodo lett a maga teruleten"
A sokak által jogosan agyonszidott... Ismét egy jó példa, hogy mennyire nem működik a szelekció ezen a területen (sem). Technikai érdem(telenség) nem számít, mert anno jókor volt jó helyen... és ezért sok olcsó munkaerő van hozzá, olcsó hoszting, meg sok Google találat ha valami gond van (aztán hogy milyen az átlagos szakmai színvonal...), és a kör bezárult. Ennyi. Ez most már örökké így maradt. Kész. Ezt kell szeretni, szigorúan fanatikusan (PHP legjobb, fúj C# meg a többi is szarforlassú meg minekaz), nehogy rontsd a munkamorált.
[ Szerkesztve ]
-
floatr
veterán
Próbázzad meg te is. Amit összemókuskodtam, az nagyjából partiban volt egy cpp/c#(mono) alkalmazással a legújabb v8 alatt.
Amúgy meg az architektúrával kapcsolatban meg annyi, hogy egy ideje extjs-t használunk, és annak a metodikáját használva elég összetett alkalmazásokat is lehet hegeszteni gányolás nélkül, de a node.js modulos mechanizmusa sem annyira szar.
[ Szerkesztve ]
-
doc
nagyúr
azert irtam 'sokak'rol, mert nekem nem volt sok dolgom PHP-val, egyszer kivancsisagbol raneztem, osszehoztam egy SQL elotet oldalt, orultem hogy mukodik, aztan reszemrol ennyi csak ismerosoktol hallom hogy folyton anyaznak
ha jol emlekszem, Tildy alairasaban lattam regebben: "A php az önbizalomhiányos programozók nyelve, már alapból kérdőjellel kezdődik a kód"
olcso, szar munkaero meg kb mindenhez van, eleg sokat latom masok (ilyen-olyan nyelvu) kodjat, es neha nem tudom hogy sirjak, rohogjek, es/vagy postoljam DailyWTF-ra
-
dabadab
titán
"Elmondom neked, hogy talán már nem emlékszel de C64-re is készültek alkalmazások/játékok, és nem szaggattak."
Talán már nem emlékszel, de ami tényleg durva volt, az tudott szaggatni, időnként nagyon durván (Freescape játékok (Driller, Castle Master, stb) bőven 1 fps alatt tudtak teljesíteni, ahogy a Fighter Bomber is, de akár hozhatnám a Commandot, ami tele volt spritebugokkal, mert időnként kifutottak a nyolc sprite-os határból, a Last Ninjáknak is évekbe telt, mire kirajzolták egy pályát, stb).
"Mostanában egy flash "fejlesztő" megkap egy gépet, és szarik a terhelésre, optimalizálásra, a platform gyengeségeire"
Én játszottam flash fejlesztéssel, megpróbáltam optimalizálni, utánaolvastam, minden - aztán mégis katasztófális volt a teljesítménye. Persze, biztos vannak egy csomóan, akik még annál is rosszabb teljesítményt tudtak volna kicsiholni belőle, de ez nem változtat azon, hogy szarból nem lehet várat építeni.
(#95) nyogo83: "Nemtudom, lehet csak nekem trivialis hogy pl egy bongeszoben/playerben futo ilyen osszetett webes alkalmazastol/jatektol/stb ne varjam el ugyanazt az eroforrasigenyt mint egy sima desktop alkalmazastol."
Nekem egyáltalán nem triviális. Nézd meg pl. a Minecraftet: böngésző, Java, baromi messze van ettől a Flash.
(#94) doc: "teny hogy az AS3 nem egy agyonbonyolitott nyelv, de rengeteg, ennyire vagy meg konnyebben tanulhato nyelv letezik amik nagyon jol hasznalhatoak jatekfejlesztesre"
Nem a nyelv a lényeges (van pl Haxe-hez is flash backend), hanem a VM, az az, ami nagyon rossz.
[ Szerkesztve ]
DRM is theft
-
doc
nagyúr
Nem a nyelv a lényeges (van pl Haxe-hez is flash backend), hanem a VM, az az, ami nagyon rossz.
pont ezt mondom en is amugy ahonnan az idezetet kimasoltad, ott arrol volt szo, hogy azert lennenek olyan szarok a Flash jatekok, mert az AS3 konnyen tanulhato, igy sok hozza nem erto is tudja hasznalni, erre irtam hogy ez nagyon nem ettol fugg
egyebkent a Haxe-szel probalkoztam anno, maga a nyelv elegge hasonlit az AS3-ra, de miutan rajottem hogy az Adobenak van ingyenes Flex compilere, amivel lehet kozonseges swf-et krealni, eszembe sem jutott a Haxe tobbe -
floatr
veterán
Ja, meg az elite. De tudhatod te is, hogy egy ekkora teljesítményű processzoron nem volt igazán értelme érdemben ilyen szintű koordinátageometriát erőltetni, még a legegyszerűbb háromtagú közelítő függvényekkel sem. De ugyanígy ma sincsen értelme erőltetni a papervision-jellegű megoldásokat brutálisabb modelleknél/textúráknál. Ismerni kell a korlátokat
-
nyogo83
senior tag
Nézd meg pl. a Minecraftet: böngésző, Java, baromi messze van ettől a Flash.
Ugyanazt nezzuk?
Mert leccsekoltam es ez a max 16x16px-es texturakat hasznalo pixeltenger 60%-os prociterhelessel es ventillator felporgessel fogadott. Ettol tenyleg messze van a flash, de hagyjuk inkabb. De lehet a gepemmel van a baj... -
ddekany
veterán
Szerintem ez mondjuk nem védhető... Mert ahogy elnézem lwjgl-t használ, ami gyakorlatilag átterheli az összes 3D-s számítást OpenGL-re, szóval nem tudom miért ilyen CPU gyilkos ez, hiszen fizikai számítások vagy ilyesmi nincsenek ebben a free verzióban, szinte csak megjelenítés az egész. Másfelől ez semmi esetre sem a Java nyelv vagy a JVM hibája... valamiért nem megy az OpenGL hw gyorsítós része talán?
[ Szerkesztve ]
-
Winner_hun
félisten
Grafika, hang:
Not found!
Sorry, no posts matched your criteria.!!
Kép hullámoztatása shaderrel - rádiuszt levéve igencsak érdekes lesz a kép, kicsit bugos még
Amúgy a hardveres rásegítésnél csak átsiklottam felette vagy tényleg nincs beleírva hogy mi a minimum ami kell hozzá?
[ Szerkesztve ]
► "Kicsit olyan webcaritas" ◄ ヅ
-
ddekany
veterán
"egy ideje extjs-t használunk, és annak a metodikáját használva elég összetett alkalmazásokat is lehet hegeszteni gányolás nélkül"
Én elhiszem hogy jobb híján és a sötét múltba visszatekintve ezek csodálatosak, de ha hátra lépsz pár lépést, akkor látod abszolút értékben ez az egész szánalmas. Ilyenek örülünk, hogy sikerült már majdnem olyan használható GUI-it összehozni, ami kb már 20 éve is természetes volt böngészőn kívül. Kicsit lassabb, meg vannak vele gondok (pl. Ext JS demó oldalin a listákban nem múködik a Page down/Page up/Home/End: a scroll bart mozgatja, a szelekciót nem, ellenben a föl/le nyíllal, ami rendesen mozgatja a szelekciót), de höjj, ezt böngészőben sikerült. Ezzel a megkötéssel ez (sajnos) nem kis teljesítmény, csak hát ez olyan, mint amikor annak örül valaki, hogy sikerült kézen állva lefutnia egy maratont. Persze ez ilyen "ez van, ennek kell örülni" kategória, csak legalább munkahelyen kívül ne fényezzük már a szituációt.
-
floatr
veterán
Komplexitást szerettél volna, tessék. Ennyi lett volna az apropója, nem pedig az implementációs bugok. Nyilván ennek is vannak hibái, de amiket említesz, azok nem alapötletbeli problémák, vagy a js VM önmagában csődöl be, hanem kisebb szépséghibák, amiket mind lehet orvosolni. Ilyenek flexben is vannak bőven, de a swing sem mentes.
"Kicsit lassabb" -- erre mondanám azt h mivel nézed Nekem chrome alatt reszponzívabb, mint egy hasonszőrű swing UI, pedig mindkettő használ 2d gyorsítást, és háttérfunkcionalitást tekintve néha az az érzésem, hogy a swing elnagyolt.Amúgy ha már ennél a frameworknél ilyen szinten leragadtál, akkor hadd említsem már meg, hogy komponens-architekúra alapon elég sok dolgot próbáltam belevinni, és nem jelentett olyan őrületesen nagy problémát sohasem.
-
Petya25
addikt
Ez a verzió vajon fut már IE-ben Win7 64biten?
A korábbiak nem mentek nekem.Antonio Coimbra de la Coronilla y Azevedo, bizony!
-
HAUG
csendes tag
Köszönöm az észrevételeket és a hozzászólásokat a cikkhez! Pár felmerült dologra röviden reagálnék:
1) #6 hohoo (2011-02-09 17:49:41): "kár hogy ebből az alternativa3d-ből csak videos prerenderelt ps-elt videokat látni"
Az Alternativa3D-vel éles alkalmazások is léteznek régóta, hisz a motor maga jó ideje létezik és folyamatosan fejlődik - a cikkben illusztrációként is szereplő Tanki Online játék is ilyen (ott is a link a videó alatt). Azért csak videót tettem be róla, mert így egy kattintással megnézhető. Amiből még valóban csak videót látni, az a Molehill 3D technológia - ezt is támogatni fogja az Alternativa3D (a demó is ezzel készült), de ez a változat még nem publikus.2) #71 Zoli77 (2011-02-09 22:37:55): "az a baj hogy a keresők nem indexelik a flash tartalmat"
Ez így nem teljesen igaz. A keresők (legalábbis a Google) indexeli a Flash mozikban levő tartalmat, s ezt valójában már évek óta megteszi. De nem is ezzel van itt a baj. A baj az, hogy ez a gyakorlatban tkp. nem sokat jelent, mert jellemzően nincs a Flash moziba "beégetve" a megjelenített tartalom, hanem az futásidőben tölti be kívülről, a felhasználó tevékenységére reagálva - ez az, amit a keresők már nem tudnak lekövetni. Viszont kár ezt a Flash hibájának felróni, ugyanis ez az adatkezelés és megjelenítés rendszeréből következik, nem a Flashből. A keresők az "egy kattintás = egy oldalletöltés" módszert képesek hatékonyan kezelni, erre vannak kihegyezve. A teljes oldalújratöltés nélküli tartalomváltozásokkal pedig nem tudnak mit kezdeni, így a jellemzően ezt használó technológiákkal sem - nem csak a Flashsel, hanem a Silverlighttal, a Java applettel, de az AJAX-os JS/HTML oldalakkal sem. Én itt leginkább a keresők hiányosságát látom, hogy ezzel az egyre terjedő megközelítési móddal nem igazán akarnak foglalkozni. Nem annyira követik a keresendő tartalom változását, mint inkább elvárják, hogy a tartalomkészítők alkalmazkodjanak a keresők kényelméhez. Mindazonáltal kis többletmunkával megoldható a Flashsel és a többi említett technológiával megjelenített tartalmak kereshetősége is, csak rá kell szánni azt a kis energiát.3) #71 Zoli77 (2011-02-09 22:37:55): "én most a flash-nek kétségkívül a asztali alkalmazásfejlesztésben látom a jövőjét "
Én is hasonlóan látom. Nekem úgy tűnik, hogy egyre inkább háttérbe szorulhatnak a böngészők és a böngészőben futó alkalmazások, a hagyományos honlapok az önálló internetes alkalmazásokkal szemben. Kb. hasonló irányt látok kibontakozni, mint amit pl. az okostelefonokon, tableteken látni, azaz nem annyira a böngészőben nézeget honlapokat a felhasználó, hanem alkalmazásokat tölt le, amiknél voltaképp számára már mindegy milyen technológiával is készültek. Az alkalmazásokat így nem korlátozzák a böngészők HTML-re kihegyezett dolgai (pl. eleve felesleges, hogy egy teljesen Flashben vagy Silverlighttal készült honlaphoz kell egy beágyazó HTML, s a böngésző HTML oldalként is kezeli ezeket - minek...), hatékonyabban is működhetnek. Ebbe az irányba mutat már az AIR megjelenése is, de a Silverlight out-of-browser funkciója is.4) Felmerült a Flash alkalmazások teljesítménye és CPU-zabálása. Ezzel kapcsolatban én osztom többek véleményét, akik ezt leginkább a hanyag és képzetlen fejlesztők számlájára írják. A Flash eredendően egy grafikusoknak, designereknek kitalált eszköz volt, kiegészítve egy kis scriptelési lehetőséggel. Ezáltal tkp. bárki képes volt rövid idő alatt alkotni Flashben, s ez nagyon nagy mértékben hozzájárult az elterjedéséhez, (ugyanakkor a sokak általi táplált ellenérzésekhez is) . Noha azóta már jócskán kinőtte magát, s a profi programozók igényeinek kielégítésére hajt elsősorban az Adobe, megmaradtak a másik irányból érkezett, programozásban meglehetősen képzetlen fejlesztők is (őket is támogatják persze, lásd pl. a Flash Professional és a Flex termékvonal kettéválása), s leginkább tőlük származnak a problémás alkalmazások. Jellemzően ilyenek csinálják pl. a bannereket, amikkel a legtöbben és leggyakrabban találkoznak. Ilyen eseteknél alapvető programozási módszerek, optimalizációs technikák hiányoznak. Más eszközöknél, pl.a Javánál és a Silverlightnál eleve másként indult az egész: ott nem a grafikusok és animátorok voltak a kezdeti célcsoport, hanem a professzionális programozók (ha egy amatőr kezébe adod a Flash Professionalt, akkor elég jól elboldogulhat rövid idő alatt, míg egy Visual Studioval, Eclipse-szel, Netbeansszel nem nagyon fog tudni csinálni semmit, de a Flash Builderrel sem), s csak az utóbbi időben próbálkoznak a programozási szempontból lájtosabb célcsoportok megcélzásával (lásd pl. Java applet helyett JavaFX, vagy a Microsoft Expression szoftverei). Ami a HTML5 vonalat illeti (amit mondjuk én több okból sem látok különösebb konkurenciának a Flash számára), véleményem szerint ugyanaz lesz a helyzet, mint a Flash esetén: alacsony a belépési küszöb, így sok "kókler" is megjelenik, s tömegével lesznek CPU-zabáló, kezelhetetlen, idegesítő alkalmazások a jóval kevesebb valóban profi mellett.
-
ddekany
veterán
Én meg kb azt akartam kifejezni, hogy mennyire ez az alapfilozófia "ha nagyon igyekszünk nem is olyan szar ez... látod, ilyet is lehet!". Ja. Kellő kitartással remekül lehet kézen állva futni. Máj majdnem annyira, mint lábon, és akkor lehet mutatni, hogy "Na ugye!". Csak hol tartanánk ugyan ennyi befektetéssel ha inkább lábon próbáljuk, és főleg, hol lenne úgy a határ amíg elmehetünk. De hát ilyen az élet, szóval...
A Java meg desktop-on nem nagyon volt jó szvsz. De az sem azért volt, mert az alapokkal (JVM, vagy akár a Java) lenne a gond, mint ahogy valóban jelen gond sem JS-specifikus. De hogy Ext JS-ben az említett bug miért van... talán nem azért mert az Ext JS fejlesztők benézték (mert elég égő is lenne ilyen alap dolog kapcsán ennyi idő után), hanem mert gondolom annyira nyakatekert ezeket megvalósítani a HTML/CSS/stb alapokon, hogy ilyem kompromisszumot kellett kötniük. Ez azért nem mindegy a böngésző mint platform kapcsán. Persze webes területen kliens oldalon mi nem kókány... egy iszonyú tolakodós kapkodás ez egész kialakulása. A világ ura lennék, betiltanám az egészt... vissza a tervezőasztalhoz...
-
dabadab
titán
Valószínűleg a framelimiter lesz a hibás, alapból ki van kapcsolva (esc-kel jön elő a menü). Bekapcsolt limiterrel (kb 100 fps-sel), far viewing distance-nél nálam az X2 250-en 800 MHz-en kb az egyik magon 50%-os terhelést csinált. Meg mondjuk valószínűleg a kód sincs agyonoptimalizálva, ez inkább amolyan proof of concept, pre-alpha állapota a kódnak - és még így is bőven ver bármit, amit flashben láttam.
DRM is theft
-
daninet
veterán
Sokan kerestek megfektetős flash cuccot. Framville-ben fejlesszétek fel a telketeket nagyméretűre (akinek a nője már megtette az előnyben van), ültessétek tele növényekkel és rakjatok rá sok épületet. Nekem többször összeszakadt a böngésző tőle, proci 100-on megy, otthon i7-en is ugyanez a helyzet
Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>
-
HAUG
csendes tag
5) Felmerült még a nyílt vs nem nyílt viszonya. Én személyesen nem gondolom, hogy különösebben a nyílt forráskódon múlna egy szoftver minősége, ugyanis - a legegyszerűbb szoftverektől eltekintve - a jó eredményhez abszolút profi fejlesztők kellenek, akik főállásban foglalkoznak az adott szoftver fejlesztésével, s nem önkéntes belekukkantgatás, hozzáfarigcsálás szintjén. Ezeket az embereket össze kell gyűjteni, meg kell fizetni. Innentől viszont tkp. mindegy, hogy nyílt-e egy szoftver forráskódja, hiszen egy mögötte álló pénzforrás és szakértelem nélkül úgysem tud senki érdemben hozzányúlni egy teljesen nyílt forrású szoftverhez sem. Az ismert nyílt szoftvereket (Linux, Firefox, stb.) is jól fizetett profi programozók fejlesztik főállásban, nagyon is profitorientált cégek által finanszírozva (közvetve vagy közvetlenül). Ami az Adobe nyíltságát illeti: az SWF formátum nyílt szabvány, s nagy hangsúlyt fektetnek nyílt forrású fejlesztésekre. A Flash 9 megjelenésekor a bájtkódfuttató motort Tamarin néven nyílt forrással továbbadták a Mozillának, hogy a JS fejlesztésekhez haszunálhassa. Teljes Flex SDK nyílt forrású, s nyílt projektjeinek külön honlapot tart fenn az Adobe: opensource.adobe.com. Megtalálható itt az Open Source Media Framework, a Flex Framework és több más nyílt projekt is. A Flex Buildert is a nyílt forrású Eclipse-re építve készítik. Kétségtelen, hogy pár dolog üzleti megfontolásokból megmaradt zártnak: ilyen a Flash lejátszó vagy a Flash fejleszőkörnyezet, illetve pl. az RTMFP protokol. Én nem tartanám jó ötletnek, ha a több forrásból származó Flash lejátszó is forgalomba kerülne, hisz ez óhatatlanul is inkompatibilitásokkal járna, márpedig a Flash egyik legnagyobb előnye az egységesség. A böngészők a Flashnél jóval kevésbé összetett HTML és CSS egyforma működését sem tudták maradéktalanul megoldani sok-sok év alatt, nem várhatnánk sok jót a különféle Flash lejátszóktól sem.
-
doc
nagyúr
nem nyilt forrasrol volt szo, hanem a szabvanyokrol. a mar emlitett pelda ugye a JS-t hozta fel, ami egyre gyorsabb es gyorsabb, a browserek versenyeznek a minel gyorsabb JS motor kifejlesztesevel
mivel a Flash playert egyetlen ceg fejleszti, nem kell versenyeznie, ezert megteheti hogy otvar lassu legyen. ha ugyanugy minden bongeszogyarto sajat maga csinalna a Flash plugint, az is sokkal gyorsabb lenne
inkompatibilitas meg addig van, amig nincs egyseges szabvany. a HTML ott kurvult el mar a legelejen, hogy egyreszt baromi lassan keszult el a szabvany, es addigra a gyartok elkezdtek a sajat megoldasaikat hasznalni, masreszt bizonyos szines zaszlocskas gyartok leszartak a letezo szabvanyokat
ha tobb gyarto nekiallna sajat Flash playert fejleszteni ugy, hogy van egy mindenre kiterjedo, reszletes, nyilt szabvany, akkor gyors, jol mukodo, kompatibilis lejatszoink lennenek
persze ez nem fog megtortenni, tekintve hogy a browser-gyartok inkabb a HTML5-re szavaznak, ami a Flash borzalmas teljesitmenyet latva azert ertheto
mindenesetre a HTML5 es a Flash eleg sokmindenben kulonbozik ahhoz, hogy ne egymas kozvetlen vetelytarsai legyenek, meg ha eleg nyilvanvaloan meg is van az erdekellentet -
floatr
veterán
Őszintén szólva egyre kevésbé értem, hogy mire akarsz kilyukadni ezzel. Ha a nyelvvel van a problémád -- mintha rémlene ilyesmi -- akkor az egyéni személyiségzavar Ha a VM-el, akkor biztosíthatlak, hogy semmivel sem gázabb a többihez képest, nyilván összetettebb módszerek kellettek hozzá, hogy egy ennyire szabadon mozgó célpontot eltaláljanak jól. Ha a grafikai alapok nem tetszenek, akkor hadd említsem meg, hogy nagyonsok évvel ezelőtt hegesztettem magamnak vesa alapokon egy ablakozós rendszert, és beszarás h mennyit kell gányolni, hogy emészthető eredmény legyen, és akkor még egy általános interfészt használtam, igaz asm/C alapokon. Persze közben meresztgettem a szememet az utóbbi időkben a jelenlegi ablakozós rendszerekre is, de azt kell mondjam, hogy iszonyat üdítő ilyen egyszerű eszközzel építkezni, mint ez. Szóval nem értem a kifogások alapját.
A bugokat illetően meg én azt látom, hogy a komponensek fejlesztőinek a fejében inkább a kattintós júzer képe járt. De legyen ez a legnagyobb problémánk, hogy nem teljesen úgy működik minden bitre, ahogy mondjuk egy éppen aktuális comctl32 library-ban összetákolt cuccok.
-
HAUG
csendes tag
A konkurencia úgy általában jót tesz a fejlődésnek, ez kétségtelen. A Flash esetén pl. leginkább a Silverlight belengetése volt ilyen. Ugyanakkor továbbra sem tartom jó ötletnek az eltérő Flash Player implementációkat. Az esetleges inkompatibilitásokkal többet lehet veszíteni, mint nyerni a teljesítménnyel, s ha a különböző változatok egyes részterületeken jelentősen eltérő teljesítményt nyújtanak, az is csak gondot okoz.
-
hohoo
senior tag
drawcall. Keress rá mit jelent. Annyit leírok hogy minél több ojjektum van a látótérben annál nagyobb cpu terhelést jelent, márpedig egy ilyen játékban rohadt sok van, és nem biztos hogy meg van csinálva ez a kitakartat ne renderelje dolog, mert az még rendes játékokban is sokszor kimarad.
T-home extra csomag monopolterületen 6500 ft/hó, versenyterületen ahol Digi vagy UPC is van pedig 2990 ft/hó. Köszönjük!
-
hohoo
senior tag
gondolom 4 magos procid van azért csinált max 25%-os terhelést a doom a 25% azt jelenti, hogy 1 mag 100%-on pörög, a többi semmit nem csinál.
Így a javanál látszik is, hogy több magot használ, míg a flash nem.A doom futási sebessége nem is mindig kielégítő, de ajánlom hogy nézd meg a jake2-t (javas quake2) gondolom nem kell magyarázni a különbségeket a quake2 grafja és a doom grafja között, márpedig az előbbi ha hagyják több száz fps-el fut, átlagban a natív kód 80%-val!
T-home extra csomag monopolterületen 6500 ft/hó, versenyterületen ahol Digi vagy UPC is van pedig 2990 ft/hó. Köszönjük!
-
moli.hu
őstag
remelem, hogy az abraval ellentetben a kliensek nem kuldik el annak az adatot, akinek mar megvan/aki mar kapja........
-
ddekany
veterán
Sok mindennel van baj (ezek egy részét, mint pl. hogy alap GUI funkciók rendszeresen köhögnek, majd néhány évtized alatt csak kinőjük), de akkor leegyszerűsítem és az eredi mondanivalóm csak ez volt: Nincs az egész mögött egy komoly általánosabb célú VM. Valami olyasmi mint a JVM vagy CLR. Az, hogy egy VM legmélyebb publikus/szabványos rétege JavaScript, az egyszerűen olyan szintű szakmai ostobaság, hogy nem is érdemes róla beszélni. Főleg mert nem is szakmai döntések miatt van így. Hosszú távon elvileg ki lehet persze ebből mászni úgy, hogy bevetnek egy nem-specializált VM-et, ami nyílt szabvány lesz és elvárás, és azon fog futni a JS, meg amilyen nyelvet (akár statikusat) még használni akarsz. Flash-nek megvan ugyan ez a gondja, ha nem tévedek. Az értelmesebb megközelítésre példának meg lásd Silverlight-ot (ami CLR-re épít).
"Ha a nyelvvel van a problémád -- mintha rémlene ilyesmi -- akkor az egyéni személyiségzavar "
Mert hogy a JS tök jó kb minden célra. No comment...
[ Szerkesztve ]
-
rt06
veterán
-
dabadab
titán
"Felmerült a Flash alkalmazások teljesítménye és CPU-zabálása. Ezzel kapcsolatban én osztom többek véleményét, akik ezt leginkább a hanyag és képzetlen fejlesztők számlájára írják."
Valami azt súgja, hogy itt nem az Adobe fejlesztőire gondolsz, pedig az a helyzet, hogy ha lenne normális grafikus gyorsítás a flashben, akkor vidáman vinné azokat a lehetetlenül elrontott dolgokat is, amik most megizzasztanak bármit.
DRM is theft
-
zoltanz
nagyúr
Ebben csak az a ciki, hogy amiket én nézek a youtube -on azok általában 480p -sek max.
Manapság egy előnye van ha nem vagy szegény, színvonalasabb ellenségeid lehetnek
-
x007
tag
Csináltam néhány nagyon egyszerű CLR vs V8 tesztet. Azért a v8 még jócskán elmarad, de azért szerintem jóval gyorsabb annál, mint sokan gondolnák. Abban az említett topikban közölt teszttel az volt a baj, hogy ott a számításigényes műveletek a trig függvények voltak, amik nyilván nem jsben vannak implementálva. De ha jól tudom pl .NET-ben sem CIL implementáció van .
Üres ciklus:
CLR
for(int i = 1; i< 1e9; i++)
{
}Time: 2341 ms
V8
for(var i = 1; i< 1e9; i++) {
}Time: 5829 ms
Számtani sor összeadás nem kis Gauss módra
CLR
long sum = 0;
for(int i = 1; i< 1e9; i++)
{
sum += i;
}Time: 2860 ms
V8
var sum = 0;
for(var i = 1; i< 1e9; i++) {
sum += i;
}Time: 14692 ms
Lebegőpontos összevissza számolás
CLR
double x = 0;
for (double i = 1; i < 1e5; i+=1.312312)
{
for (double j = 0; j < 1e4; j+=1.432423)
{
x = 423423.421342314423142314123423 * i + i * j - 42342.423423;
}
}Time: 2028 ms
V8
var x = 0;
for (var i = 1; i < 1e5; i+=1.312312) {
for (var j = 0; j < 1e4; j+=1.432423) {
x = 423423.421342314423142314123423 * i + i * j - 42342.423423;
}
}Time: 18028 ms
OOP
CLR
public class Person
{
public Person(string firstName, string lastName)
{
this.FirstName = firstName;
this.LastName = lastName;
}
public string FirstName { get; set; }
public string LastName { get; set; }
public string FullName
{
get
{
return this.FirstName + " " + this.LastName;
}
}
}
for(int i = 1; i< 1e7; i++)
{
Person person = new Person("John", "Doe");
string name = person.FullName;
}Time: 950 ms
V8
var Person = function(firstName, lastName) {
this.firstName = firstName;
this.lastName = lastName;
};
Person.prototype = {
getFullName : function() {
return this.firstName + " " + this.lastName;
}
}
var start = new Date();
for(var i = 1; i< 1e7; i++) {
var person = new Person("John", "Doe");
var name = person.getFullName();
}Time: 4119 ms
Ennél az utolsónál az a baj, hogy a js marhára nem OO, annak ellenére, hogy van aki annak veszi. A prototype tudásra a struct és a class között valami, de közelebb áll a structhoz sztem . prototype.js libbel lehet belőle OO nyelvet "csinálni", de azzal tízszer lassabb lett, amikor utoljára mértem, szóval inkább erről nem is csinálok tesztet .
aki nem érti mire gondolok:
Personból származtatni egy Men-t, felülírni a FullNamet valami ilyesmire: return "Mr. " + base.FullName. Na ilyet tudomásom szerint jsben nem lehet.Persze a tesztek milyensége megkérdőjelezhető, de azért az látszik benne, hogy a V8 nem számításigényes feladatokra van kihegyezve, ami annyira nem is baj, mert nem is erre való. Leginkább csak különböző API-t hívunk vele (pl. DOM, XHR), aminek az implementációja valszeg nem js alapú, hanem valami szarráoptimalizált c++.
-
DMG
senior tag
Hát megnéztem, az bizony a flash ami két magot használ.
Bár valahol azt olvastam, hogy ha flash akkor Windows 7, nekem az van, és semmi akadás egy mozinál, egy játéknál sem.
Bár annyira nem érdekel senkit a posztom, gondoltam azért megosztom.
Amit ma megtehetsz, azt tegnap kellett volna.
-
Suker10
aktív tag
Nem értem ezt az egész vitát. Azt sem, hogy miért kell a webes nyelvekhez keverni az általános nyelveket. Hogy lehet a JavaScriptet a C#-al összehasonlítani? Még olyat sem láttam, hogy az egyik nyelv megszűnt volna a másik javára. A C#-nak részben a Java volt az alapja, de két nagyon eltérő nyelv.
Ha teljesítmény-igényes alkalmazásokat akarsz fejleszteni, akkora egy adott ponton szinte mindegy a választott nyelv. Volt olyan, hogy sem C#-ban, sem Javában nem olyan sebességgel futott az alkalmazás, ahogy elvártam, cserébe viszont adott mást. Én nem szidom a PHP-t sem. Mindegyiknek megvan a maga helye. Ha a Flash nem olyan lenne, amilyen, akkor nem így hívnák.Müzli 38% gyümölccsel: "Száraz, hűvös helyen tárolandó. Az elemzés értékeit a természetes termékek biológiai variáció. Hiszen ebben a gabonafélék természetes termék tartalmazhat nukleáris alkatrészek, részek és kő shell alkatrészek is." De legalább természetes.
-
oO7
őstag
az ezzel a baj, hogy a szerver oldali webmotoroknak (php, asp) az oldalgeneráló részét most akarják a kliensre költöztetni, hogy majd js -ből megoldják az oldal különböző részeinek legenerálását és a szervertől csak a raw data -t kapja és nem egy fullos elkészített HTML kódot...
ennél a feladatnál azért szerintem a javascript több nagyságrenddel alul fog maradni a többiekkel szemben -
addikt
Nálam is két mag van használat alatt. A 10.1.xxx-el is annyi volt és a mostani 10.2.xxx-el is. De az új player segítségével a 60%os cpu terhelés (800mhz-en, athlon x240) leesett 10% körülire 1080p-s video lejátszásnál. Ennek ellenére a flash játékok ugyanúgy zabálják a CPU-t.
Mos mé, hánem? De! Vagy nem...
-
-
Flesi
csendes tag
"Ezek után szerintem elég nyilvánvaló, hogy minél előbb kipusztul a Flash, annál jobb az egész világnak."
Ezt azért jó lenne előtte közölni azzal a potom 99.99% Flash felhasználóval is akik világszerte platformfüggetlenül telepítik, és használják örömmel tele a Flasht hardveres gyorsítás NÉLKÜL is...
Új hozzászólás Aktív témák
- Fejhallgató erősítő és DAC topik
- World of Tanks - MMO
- gban: Ingyen kellene, de tegnapra
- Motoros topic
- Otthonfelújítási program (2024.)
- Mobil flották
- Anglia - élmények, tapasztalatok
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Synology routerek
- Macska topik
- További aktív témák...
- Bontatlan Seagate & Western Digital HDD-k 3TB - 12TB -ig - Számla + Garancia, Ár alatt! BeszámítOK!
- DJI Mini 4 pro FMC drón - 3 akku, RC2 táv, 2 táska, Filterek, 2025. decemberig garancia, DJI Care
- HP EliteBook 840 G6 i5-8365U 16GB RAM 256GB SSD világító MAGYAR billentyűzet
- Eizo Flexscan EV2450 IPS HDMI 2Év Garanciával MONITORCENTER
- 4070 Ti Aorus Master //KERESEM!!//