Új hozzászólás Aktív témák
-
ddekany
veterán
Videókártya (és driver) kompatibilitás kérdése. 1.7GHz-s mobil Celeron-on S3/G3 IGP, Windows XP-n pl, a youtube és más flash-es videók teljes képernyőn nézhetetlenek, mert szaggatnak és pixelesek (100% CPU használat, a nem-teljes-képernyős 50% helyett). Nyilvánvaló, hogy a szükséges számítási kapacitás bőven megvan ebben a vasban, csak a Flash képtelen azt használni... (Akármelyik natív médialejátszóban sokkal jobb minőségű videók simán szaladgálnak teljes képernyőn, akár a kevésbé megterhelő 720p-s x264-ek is.) Más gépen más videókártyával a CPU foglaltságon nem nagyon változtat, hogy teljes képernyő vagy sem.
-
hohoo
senior tag
szaggat mint az állat a videodon kedves arrakistor, vajon kiki
És ez még nem is hd és nem is egy normális minőségű 480p-s sd.
sok mag pölö nem is számít, mert a fless 1 magot használ max.
van itt a közelben egy 1200-as celeroncs is linuxal, azon is max a 240p nem szaggat, viszont h264-el html5-ben még a 480p is sima... -
"a pixel ráció-t és a kép-rációt meg sem érti"
Hat ebben nincs tul sok racio
Egyebkent meg a youtube video full screenen szanalmasan szaggat, mivel - legalabbis Linux alatt - a YUV-RGB konverziot is szoftverbol szamolja. Amit linkeltel, azt meg nem tudom hova tenni, ott HW gyorsitott UI van, ott a CPU-t az azon futo kis flash terheli osszesen kb.
-
Flesi
csendes tag
A másik szegről-végről szintén idetartozó téma, hogy attól tudok még bepöccenni, mikor az ember az 1900ban felvett homályos börleszk filmet és dokumentumfilmeket megszégyenítő gyatraságú homályt akarja HD felbontásban 1920x1080-ban nézni az amúgy csak 1024x768 ( 4:3 ) -ba váltott, de 16:9 arányú LCD-TV-jén, a pixel ráció-t és a kép-rációt meg sem érti pedig általános iskola 4-ed osztályos tananyag a törtek egymással való maradék nélküli osztása. Persze a képe az lapos (vajon mitől) é csodálkozik, hogy az 1920x1080-as youtube videó szaggat a 3 gigaherces 3 magos gépén (a leggagyibb DIGI kapcsolat mellett)
és ilyenből annyi van, hogy dunát lehetne belőlük rekeszteni...
-
Flesi
csendes tag
Sokan panaszkodnak, hogy így a youtube videók meg úgy a youtube videók, szaggatnak a SOK gigaherces, SOK magos gépükön.
főleg 64 bites rendszereken... nos nekik az egyöntetű válaszom az az hogy néztem én már folyamatosan jútyúb videót 600-as celeronon és a mostani 900-as celeronomon a teljes képernyőt felvevő kepcsör közben is így fut a dolog. (LINUXON !) Akinek ezek után bármi gondja van a flessel az adja vissza az ipart, a gépét meg zúzza szét egy nagybaltával. 
-
tenegri
csendes tag
Te még mindig kevered a generikus adattípust valami mással (úgy tűnik leginkább a típusnélküliséggel és a dinamikus típuskezeléssel), pedig ddekany már felhívta erre a figyelmed. Az sem világos, hogy jön ide a PHP - biztos jó topikba írsz? Generikus típusok használatánál a szigorú típusosság megmarad, nem futásidőben, hanem már fordítási időben eldől, hogy hol milyen típus lesz használva. Eleve nincs is értelme a generikusoknak egy nem szigorúan típusos nyelvnél. Olvasnivaló
-
ArchElf
addikt
Ok, talán egy kicsit pontatlanul fogalmaztam...
De aki a var/Variant-tal kezdi a fejlesztést (vagy php-ban, ahol nincsenek is rendes típusok, csak generikusok, meg osztályok), annak az első sírása itt az lesz, hogy ha beolvas két "számot" a line-in-en, nem érti, miért nem tudja "csak úgy" összeszorozni őket... A generikus adattípus csak kb arra jó, hogy a compiler ne sírjon, aztán a program meghaljon félúton és lehessen debugolni órákig vagy napokig, mire az ember megtalálja, hogy honnan szivárog be egy konvertálatlan/kezeletlen adat.AE
-
hohoo
senior tag
Így sem igazán áll össze a kép.
Na tehát akkor ha h264-et használnak akkor tényleg még sokat dolgozni sem kellett volna rajta, tehát a nemakarás egyérelmű. Ilyen nincs hogy egyik programban tudja ugyanazt, másikban meg nem, csak akkor ha egyszerűen nem akarják hogy tudja.
De ha emulálva is lenne (pedig nincs mint olvasható), akkor is hogy hogy csak a flashnek nem jó az emulált dxva2? -
azbest
félisten
Az hogy a rendszer milyen api-t használ a gyorsításhoz, és hogy milyen a hardver képessége, az bizony két különböző dolog. [link]
"DXVA 1.0 is emulated using DXVA 2.0"
http://msdn.microsoft.com/en-us/library/cc307941%28v=VS.85%29.aspxA youtube hd videói is h264-et használnak.
Talán pontatlanul fogalmaztam, de a lényeg akkor is az, hogy az udv+ képességű hd3000 sorozat sokkal fejletlenebb hd gyorsításban. Amelyik program megköveteli azt a plusz tudást, ami az újabb sorozatokban van, az nem fogja használni a dxva2-t.
-
ddekany
veterán
Én meg nem tudom miről volt itt szó, mert a generikus adattípusokra pont hogy az erősen típusos nyelveknél merül fel az igény. Szóval ActionScript-nél valami mást hívnának úgy, mint amit Java/C++ stb-ben? (Utóbbiakban pl. Map<K, V> és társait hívják így.)
Ami a "megtanulhatnák az erősen típusos nyelvek használatát" dolgot illeti, alap kéne legyen, hogy egy programozó mind a kettőhöz értsen. A nem-erősen-típusosság valódi értelme szvsz ott lenne, mikor meta-programozásra használod ki (azaz lényegében és leegyszerűsítve, futásidőben állítasz össze osztályokat), amúgy leginkább csak önszopatásra jó, na meg mert az elterjedt statikus nyelvek ált. nem túl jól lettek megtervezve. (Hogy konkrétan PHP-ben a meta-programozás mennyire megy, azt őszintén szólva nem tudom...)
-
azbest
félisten
Nem tud. Az IGP-s 3200 fejlettebb, mint a kártyás 3000 sorozat.
Az igp képes killa samplet is lejátszani, a flash video gyorsítás is működik vele. (de ez sem minden dxva2 programmal kompatibilis teljesen). ennek video dekóderét "uvd2 lite"-ként is szokták nevezni.
A kártya viszont nem boldogul killa sampleval és egy dxva2.0 lejátszó sem képes használni, csak olyan programokban kapsz videógyorsítást, amelyek dxva1 kompatibilisek (pl mplayer-hc). A kártyákban csak uvd1+ van.
Onnan tudom, hogy a gépemben van ezekből és többször megerősítették különböző források.
-
azbest
félisten
bocs ha más már irt hasonlót.
Molehill 3D videón látható, hogy nagyobb váltásoknál beszaggat...
Java applet alapú 3d tankos játékot már sok évvel ezelőtt is láttam, az lényegesen gyengébb gépen is jól ment és közel olyan minőségű volt mint a natív játékok olyan stílusban.(#169) nfsu17
a flash10.1 is csak dxva2.0 kompatibilis kártyákon tudott videót gyorsítani, ez pedig monjuk ati kártyák esetén hd4000+ (kakukktojás az integrált hd3200 és rokonai, mert az kicsit újabb video decoder-t kapott, mint a kártyák). Ha újabb kártyával nem megy a gyorsítás ott valami bibi van. -
hohoo
senior tag
-
nfsu17
veterán
Nekem miért nem megy a gpu gyorsítás?
10.1-el se ment, a legújabbal sem megy, a pipa ott van a settingsben, a gpu viszont meg sem mozdul state5-ből, és a cpu is dolgozik. Úgy nagyon nem izgat a dolog, a dxva-t sem használom, csak a miértre lennék kíváncsi max ennyi az egész.
A dxva mpc-hc-val működik, azt ellenőriztem.Firefox 3.6.13
-
julius666
addikt
-
Flesi
csendes tag
A te ismeretségi köröd néhány geek-ból , fan-ból és guru-ból áll, akik ismerik, tudják jól a fless lehetőségeit korlátait. Ezekből viszont nagyon kevés van világszinten. Az átlaglúzereknek halvány fogalma sincsen hogy mit tud a fless, vagy mit nem tud, és mit hogyan tud arról meg aztán végképp nincs fogalmuk, ezért nekem , aki sok átlagemberrel találkozik nap mint nap, pontosan ellenkező a meglátásom :
100 ból 100 ember esténként kényelmesen a gép előtt ülve játszik jóízűen az iwiw-en, a FaceBookon található farm-os , pókeres, de mindenképpen GAGYI fless játékkal, önfeledten és telibeszÓrja nemhogy a 3D videógyorsítást is, de még a youtube-ot is.
-
Mondjuk ha Linuxra írtak volna egy flash-szerű lejátszót, annak az elterjedtsége nem nagyon lenne sehol, még ha jó lenne sem.
Ha viszont az Adobe komolyan gondolja, hogy akkor most platformfügetlen akarna lenni, akkor meg csinálja rendesen. Ha sz@rni kar rá, akkor meg tegye azt.
-
"Az egyik leggyakrabban emlegetett hiányosság, a 64 bites operációs rendszerekhez illesztett Flash lejátszó nem került fel a listára"
Szerintem ez a legnagyobb LOL az egészben, mert mióta is nem tudnak kijönni vele?
Lusta bandaLinuxos flesspléjerekről meg annyit, hogy ha egy ablakban megy, és egy másikra ráfrissítek, akkor vagy leakad, vagy nem. Úgy 80% leakad. Persze egy F5-re visszajön... De ha épp videót néztem, az nem vígasztal.
Mondjuk ha már leakad a flashreklám is, az azért majdnem olyan jó, mint az adblock
-
Varoz
addikt
Sajnos meg kel erősítsem az ellenzők táborát. Már minden böngészőt kipróbáltam, 26 féle flash volt fent a gépemen és egyre sz@rabb. Sima youtube videó is kiakasztja. Persze, ha csak az megy akkor nem. De könyörgöm 2011-ben egy 4 magos gépen lehessen már megnyitni 10 lapnál többet is, még ha az flash alapú is.
-
ddekany
veterán
"Szerintem most is alapvetően két dolgot akarsz egyben megkapni."
Nem hiszem... Tudtommal a dinamikus és a statikus nyelvek futtatásához szükséges VM funkciók elég erősen átfednek. Amennyire én látom, a legtrükkösebb össze nem illés abból adódik, hogy a statikus nyelvek nem szeretik amikor futásidőben változnak az osztályok, ami még nem lenne nagy gond (elvégre lehet kétféle osztályod), csak épp a kétféle nyelv ezeken keresztül kommunikál egymással, tehát mind a kettővel működni kéne mind a kettő módszernek. Ez meg nyelv-tervezési gond, nem VM gond, és azért ott sem a világ vége. Dinamikusból hívni statikusat triviális, fordítva lehet hogy néha kényelmetlen lesz... na bumm, inkább mint hogy csak az egyik legyen. De az állatira nem kunszt, ha pl. a statikus nyelven azt írod, hogy foo->bar foo.bar helyet, akkor az előbbi hash-lookup-ot csinál szóval dinamikus, míg az utóbbi statikus... Fantom-ban van is ilyen amúgy (mellékesen az JVM-en és CLR-en is fut).
Az meg, hogy ez túl sok-e... Mivel most az a duma, hogy ez a jövő, és minden így fog futni, ehhez kb semmilyen alap infrastruktúra nem túl durva. Az hagyományos cuccok is igen komolyan, óriási befektetéssel kidolgozott infrastruktúrán futnak (x86, ilyen-olyan kernek, stb), ez meg most hirtelen kókányon fog? Hááát... szomorú. De talán előbb utóbb alánövesztenek valami összefont VM-et.
"Az egyik oldalról van egy dinamikus nyelvi tábor, a másik oldalon meg a statikus "erősentípusosajó"."
Sajnos, mert táborokba kell verődni azt kötelező... Amúgy az nem-szvsz a statikus nyelvek erősen a statikus nyelvekben rejlő potenciáljuk alatt teljesítettek az eddigi történelem során (egyrészt nem voltunk elég okosak a megtervezésükhöz, másrészt egy igazán jó statikus nyelv kifejlesztése eleve durvább mint egy dinamikusé), és ebből adódon rengeteg alaptalan előítélet él velük szemben. Legtöbb dinamikus párti számára pl. a statikus nyelv az a C/C++ rémkép, Eclipse-t csak messziről láttak, state-of-the-art statikus nyelvet meg soha sem. Ha meg igen, akkor elriasztja őket, hogy ezeket meredekebb megtanulni, pedig azt csak egyszer kellene. Mondjuk ahogy elnézem az átlag olcsó programozót, lehet értelmileg képtelen lenne rá, túl absztrakt neki.
-
floatr
veterán
Szerintem most is alapvetően két dolgot akarsz egyben megkapni. Az egyik oldalról van egy dinamikus nyelvi tábor, a másik oldalon meg a statikus "erősentípusosajó". A dinamikus nyelvekre mint látható egész jó VM-ek húzhatóak, de nagyon más a mechanizmusa, mint pl a JVM-é. Amellett vannak teljesítménybeli különbségek is éppen a felépítésből adódóan. A két tábornál szvsz annyira nagyok az ellentétek, hogy egyikben sem akarják feladni azokat a fő ismérveket, ami miatt azt a nyelvnek/technológiának preferálják.
Emiatt van csak interpreterként jelen java-ban a felsorolt pár script. És emiatt lenne pazarlás ráerőltetni egy JsVM-re egy statikus nyelvről fordított bytekódot. Két VM-et meg senki nem fejleszt, mert néha még az az egy sem igazán megy.
-
ddekany
veterán
"Milyen komoly és általánosabb célú VM-et szeretnél?" Amihez Ada, Forth, Lisp, vagy akár brainfuck alapon is lehet kódot írni? Mert a CLR nem olyan."
Eredendően nem akkora gond ez, hogy ne lehessen sokféle (nem mindenféle) nyelvet rendesen támogatni egy CLR/JVM-szerű VM-ben. Gondolj arra, hogy a JVM-et kizárólag Java-ra tervezték, és még így is van Groovy, Scala, még újragondolt-Lisp is (Cloujre). Sőt, nem JVM-re tervezett nyelvek is, mint a Python (Jython), Ruby (JRubby), és persze JavaScript (Rhino) is. Igen, ezek mind mehetnének szebben/gyorsabban is ha gondoltak volna többféle nyelvre a JVM tervezésekor, de még így utólag is sokat lehetne ezen javítani. A legfájóbb hiányosságot pl. (nincs gyors dinamikus metódushívás utasítás) a Java 7-ben ki is javítják. Szóval ha nem is akármilyen nyelvet, de többféle nyelvet (pl. dinamikusabb VS statikusabb megközelítésű) rendesen támogató VM-et igen is lehet készíteni. Csak hát a piac ezt nem engedi, mert ugyan ki vág bele egy ilyen mega-projectbe, amivel azonnal elbukik, mikor tudja rávenni az összes jelentős böngésző készítőjét, hogy most azonnal integrálja amit ő kitalált... Én ezt felfogom, hogy ez a realitás, Így Jártunk. De azt hagyjuk már, hogy ennek technikai akadálya van, meg hogy az technikailag jó ami van. Nyilván az ember próbálja jól érezni magát abban ami van (JS van és kész, aztán majd így-úgy hozzákókányolják ami nagyon hiányzik belőle), de azért ne az önbecsapásnak is megvan az ésszerű határai.
-
Pont, hogy akkor ülök le flash játszani, mikor a gép a háttérben melózik. Nembaj, ott az a primitív open transport tycoon. Egy kicsivel komolyabb számításokat végez a progi mint bármely flash-es játék, majd azt pörgetem. Tudom nem lehet összehasonlítani a webes felületű játékot egy desktop progival. Bár véleményem szerint ha jó lenne a nyelv amiben meg van írva és jól írnák meg a progit akkor mennie kéne kb ugyanúgy mint egy desktop-osnak. De ezt is már leírták előttem.
Ráadásul, egy fis-fos game miatt miért kell csövön menni egy 2magos 2,8Gh-es procinak?
Lépnijük kellene a hardver gyártóknak, ideje volna már kiadni a 10000magos 8millió tera hertzes procikat. (ez a marharépa Firefox aláhúzogatja a tera szócskát) -
ddekany
veterán
"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?"
Hát pont ebből ered a vita, hogy egyre inkább mint mindenre-jó nyelvet próbálják erőltetni a JavaScrip-et. Ennek egyik példája pedig a cikk tárgya, a Flash, ami kinőtte magát alkalmazásfejlesztő platformmá (Flex). Mondjuk én ezt nem vitának szántam, csak jelezem, hogy elég gáz, hogy ez így alakult, de van aki szerint meg ez így jó...
-
floatr
veterán
Milyen komoly és általánosabb célú VM-et szeretnél? Amihez Ada, Forth, Lisp, vagy akár brainfuck alapon is lehet kódot írni? Mert a CLR nem olyan. Egy platformhoz/nyelvhez/technológiához igazították, majd a többi kapcsolt nyelvet megoldották úgy, hogy mindegyikben lehet ugyanazt csinálni. Mint a GTK, vagy QT binding-jai csak itt egy kicsit más alapokon.
-
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...
-
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.
-
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 -
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. -
-
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++.
-
"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.
-
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...
-
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!
-
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.
-
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.
-
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.
-
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 -
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.
-
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
-
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.
-
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...
![;]](//cdn.rios.hu/dl/s/v1.gif)
vissza a tervezőasztalhoz... -
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.
-
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.
-
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.
-
#122
Winner_hun
félisten
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á?
-
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?
-
nyogo83
senior tag
Pl. Nalam ez produkalt 45 es 55 kozotti terhelest, de a ket jatek kozott van kulonbseg ugy erzem. Q1
Vagy ez 15 es 25 kozott Doom/Heretic/Hexxen
Ezek gyakorlatilag az eredeti C/C++ forraskodbol AS bajtkodda forditott jatekok.
-
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... -
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
-
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 -
"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.
-
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 anyaznakha 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
-
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.
-
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.
-
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.
-
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
"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. -
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 -
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.
-
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 -
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...
-
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.
-
floatr
veterán
Mióta része az ogl/es a flash runtime-nak?
(#99) julius666 az adobe meg tudta csinálni szabványosítási cécó nélkül, amit az ES4 munkacsoport nem, aztán azért olyan amilyen. Amúgy natúr ES3.1-ben és ES5-ben is -- ha nem is tökéletesen -- de kisebb engedményekkel egész jól lehet szimulálni az OOP-t. Bár ettől se jobb se szarabb nem lesz, max elméleti szoftverfejlesztők szemében
-
julius666
addikt
Nem igazan tudom mit ertesz az alatt hogy generlat kod.
Hogy a kód nagy részét nem te írod hanem egyszerűen összekattintgatod a GUI-ban és így tudnak a már más által említett OKJ-s "webdesignerek" is benne könnyen alkotni.
#87 Quentin:
Amúgy az actionscript ECMAScript alapokra épül, ugyanarra mint a javascript (sőt, maga az ECMAScript a javascriptből "nőtte ki magát"), szóval az adobe itt sem szart spanyolviaszt.
Megjegyzem sima C után ugyanúgy ráizgultál volna a kolléga által már említett Java-ra és C#-ra. Habár az említett két nyelv és az ECMAScript között nagyon is nagy különbségek vannak (és még mindig sokan tévesen azt hiszik a Java-ból nőtte ki magát a Javascript közben semmi közük egymáshoz), pl. ECMAScript-ben nincsenek osztályok, hanem objektum-alapú öröklődés van. -
doc
nagyúr
attol meg, hogy bytekod, meg lehetne csinalni hatekonyan es normalisan
nezd meg pl. az Androidos jatekokat: a default felbontas 480x320, de most mar elterjedt lett a 800x480 is, ami boven tobb mint egy atlagos flash jatek. full 3D (pl. NFS Shift), es a nyamvadt kis Xperia X8-on a maga 600MHz-es procijaval is tokeletesen fut, JIT NELKUL is!
pedig az is bytekod, csak nem AS VM hanem Dalvik VM van alatta.
a kulonbseg az, hogy azt normalisan megirtak -
#96
doc
nagyúr
Sweet Lou 6
#88
doc
nagyúr
válasz
Sweet Lou 6
#88
üzenetére
Gondolom ha kompatibilis lenne a Flash-el, akkor ugyanolyan lassú lenne. Nálam Windowson sokkal kevésbé erőforrásigényes a Silverlight, de régebben még lemértem, még Ubuntu alatt is (!) folyamatosabb volt a Moonlight, mint a Linuxos Flash.
a ket mondatod tokeletes ellentetben van egymassal
mivel a sajat tapasztalatod alapjan a Silverlight ugyanazt meg tudja oldani mint a Flash, csak gyorsabban, igy nyilvan lehetseges, vagyis ha a MS ujabb sajat haziszabvany gyartasa helyett sajat Flash playert csinalt volna, akkor most lenne egy egyre gyorsabb es gyorsabb Flashunk, ahogy az Adobe is nekiall optimalizalni a hulladekat (az, hogy a MS-fele flash player garantaltan inkompatibilis lett volna, mas kerdes, most pusztan az ongerjeszto folyamatrol beszelek) -
nyogo83
senior tag
A linkelt Audiotool cucc jo peladja annak hogy mennyire komplex dolgot is letre lehet hozni flashel, viszont ez eroforrasigenyes.
"Javareszt nem a flash hibaztathato, hanem 90%-ban a fejleszto."
Igen, ehhez meg azt is akkor hozzatennem, hogy sok alkalmazasra nem megfeleloen valasztjak meg ezt a plattformot, illetve pont a lehetosegei miat akarnak baromi szamitasigenyes dolgokat csinalni benne.Legutobb volt egy melom amit vissza is dobtam, mert egy repulo szimulator jatekot szerettek volna leprogramoztatni. "Csak" X tizezer pixel alapteruletu varos, 3d-s modellekkel es texturaval, kornyezeti effektekkel + valosagos fizikaval es egyeb nyalanksagokkal.
Megcsinalni meglehet, de ez mar kozel sem olyan erofarrasigenyu mint ha szimplan egy desktop jatekkent irnam meg nem flashben. (AS bajtkod -> AS virtual machine+ JIT fordito = nativ gepi kod)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.
Bar igaz, ha mashonnan nezzuk, egy atlag user pont leszarja, szoval neki ugyanugy a flash lesz a hibas hogy fogja a gepet... -
doc
nagyúr
teny hogy az AS3 nem egy agyonbonyolitott nyelv, de rengeteg, ennyire vagy meg konnyebben tanulhato nyelv letezik amik nagyon jol hasznalhatoak jatekfejlesztesre, megsem gyullad ki a proci egy 400x300-as jatektol (mittomen, GLBasic, DarkBasic, Fenix, BGD hogy igy hirtelen peldakat mondjak)
a texturas peldad meg NAGYON rossz. 1000x1000-es texturat nem csak flashben, hanem lenyegeben barmi masban is rahuzhatsz a 100x100-as kocka oldalara. ez megis csak flashben jelentene orult nagy problemat?
eleg sok nyelvvel/platformmal foglalkozom, tobbek kozott 600MHz-es ARM procikra is keszitek jatekokat, es azon siman, 50-60 FPS-sel elfutnak olyasmik, amik flash-ben mar egy asztali gepen is fullra porgetnek az egyik magot es akadoznanak. jo, az teny hogy egy binarisra forditott C++ program nyilvan gyorsabb lesz mint az a koztes kod amit a flash csinal, de ekkora kulonbsegnek akkor sem kene lennie (ennel meg a Java is ezerszer gyorsabb, pedig elegge hasonlo elven mukodik) -
floatr
veterá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. Voltak köztük elég durvák is, legalábbis akkori szemmel nézve. Amiatt megemlítem, az az h akkor is tudni kellett optimalizálni a hw gyengeségei miatt, bár akkor keményen kötött volt minden. Mostanában egy flash "fejlesztő" megkap egy gépet, és szarik a terhelésre, optimalizálásra, a platform gyengeségeire, és rögtön az első pillanatban, amikor úgy hiszi h valamennyire megy a dolog, késznek nyilvánítja. Ez mondjuk sok más platformra is igaz, de erre különösképpen.Ez az egyetlen "hibája" az adobe-nak, hogy nem kényszeríti a fejlesztőket optimalizálásra. A flash amúgy nem lenne szar, de azzá teszik. Ugyanezt meg fogod tapasztalni "html5"-ben is. Jön a sok önjelölt guru, aztán egy cpu terhelésmérőt is képtelenek beállítani, ha egyáltalán tesztelnek bármit, meg amúgy is egy fullextrás i7esen tolják, így esélyed sincsen egy jóval gyengébb gépen használni.
-
"Javareszt nem a flash hibaztathato, hanem 90%-ban a fejleszto."
Szerintem ez nagyon optimista becslés. Persze, egy gyenge fejlesztő simán képes a szükségesnél egy nagyságrenddel több CPU-időt zabáló flasht készíteni, viszont a maradék két-három nagyságrendnyi lassulás a flash hibája. Nézd csak meg a linkelt Andre Michelle cuccokat, azok is eszik a processzort szépen, pedig ő a jelek szerint képben van.
-
#88
Sweet Lou 6
addikt
doc
#51
Sweet Lou 6
addikt
-
Quent1n
senior tag
A nyelvezete egyszerűbb, könnyebb átlátni és nem utolsó sorban gyorsan, látványos dolgokat lehet vele csinálni amihez a keretprogram remek társ. Szerintem.
Én C-t tanultam anno és annál az AS százszor könnyebben megragadt bennem, hozzáteszem én nem vagyok programozó beállítottságú. Plusz ugye pár sor kóddal már kész az egyszerű animáció.
-
hohoo
senior tag
"csakis és kizárólag azért csinálták, hogy nehogy a Java -t kelljen használni... véletlenül sem azért ugye mert, hogy az ms megoldása úgy nagyságrendekkel jobb ?"
Pontosan! Megpróbálkoztak először az MS java-val mint saját szabványtalanított szabvány (mint az ie6 html-je) csak a sun letiltotta. Így copy paste és az lett a .net néhány win only kiegészítéssel, nehogy multiplatform lehessen. Nagyságrendekkel meg csak 1 valamiben más a .net, a runtime betöltődése az igen nagyságrendekkel tovább tart mint a java-é.
-
#84
Brutális eb
addikt
Brutális eb
addikt
Amióta win7-et használok egy alkalommal sem lassúlt be a gépem vagy fagyott ki a flash használata közben.(Gondolom a ramot meg a procit nem disznek vette bárki is ha már van dolgozzon is)
Régebben valóban voltak gondok.
És nem csak a mostani konfigommal de az apám E5200,1 giga ram alaplapi vgás cuccával sem volt gond.Egy ilyen konfig meg manapság fillérek és alap is bármennyire kiakaszt pár emberkét eme kicsit pökhendi hsz. -
Quent1n
senior tag
Tökéletesen egyetértek! Bár nem komolyabb szinten de foglalkozok flashel. A lényege, hogy nem kell hozzá komolyabb programozói tudás (bannerekhez, menükhöz stb.) ezért minden sarki webes le tudja őket gyártani. Viszont egy bannerből is lehet olyat tákolni ami erősen húzza a gépet. Egy ilyen lapon 2-3 flash cucc elég is, hogy hazavágja a sebességet.
Plusz az AS3 viszonylagos egyszerűségéből adódik, hogy ezt a fajta programozást nem egyetemeken hanem OKJn oktaták, illetve home-made sajátítja el mindenki. Ebből egyenes következik a flash programozók "minősége", 10 flashes emberből ha 2 komoly szinten űzi és optimalizál az már lehet, hogy nagy szám.
A flash gyengesége az egyszerűsége. Mivel mindenki meg tudja tanulni gyorsan kezelni és használni (ne feledjük el, hogy kb. 0 AS tudással is lehet benne alkotni!) így a legtöbben nem fordítanak kellő figyelmet a flashben legyártott cuccok minőségére. Sokszor már az importált cuccok is feleslegesen nagy méretűek stb.
Tehát nem elsősorban magával a flashel van a baj, mert ahhoz képest, hogy szinte csak Adobe tolja komolyabban, leginkább nem rossz sőt! Egyszerűen túl sok a figyelmetlen/gyenge/stb. flashes. Állítom, hogy az 5-10 éves AS programozói múlttal rendelkező programozók simán összeraknak olyan dolgokat flashben amik megfelelően optimalizáltak. Persze az Adobe is fejleszthetné jobban stb., de szerintem sem velük van a fő gond. Az embereknek kéne jobban odafigyelni a kezük közül kikerülő munkákra, és az elvárásokat kéne olyan szintre hozni, hogy az ipar kivesse magából a nem megfelelő minőségű munkát végző flashel dolgozó embereket.
Egyébként meg weben kívül is bőven van létjogosultsága. Pl. bemutató anyagok, oktatás stb. Ott még a jó öreg Director is hasznos.
Úgy hogy szerintem felesleges ennyire ostorozni a flasht, a megszűnését kívánni meg pláne butaság. SZERINTEM.
Én inkább azt kívánom, hogy az Adobe továbbra is álljon mögé és másokkal kiegészülve fejlesszék tovább, hogy könnyebb legyen rá jól optimalizált játékokat csinálni amik nem zabálják le a gépet.
-
nyogo83
senior tag
válasz
julius666
#78
üzenetére
Nem igazan tudom mit ertesz az alatt hogy generlat kod. Szin tiszta actionscript kodbol allo jatek, amibol a fordito keszit egy a flash player szamara "futtathato" swf filet.
A problemat egyebkent csak abban latom, hogy aranylag egy konnyen tanulhato nyelv(Ami nem hatrany) Viszont... pont emiatt akinek egy kis erzese is van a programozashoz, a rengeteg meglevo fizikai/grafikai lib-el vagy anelkul aranylag egyszeruen tud latvanyos dolgokat csinalni.
Egy egyszeru pelda: adott egy kocka, amit meg kell 3D-ben forgatni. 100x100px az oldallapjainak merete. Ra lehet huzni egy 1000x1000 px-es texturat is..ugyanugy fog kinezni mint a 100x100-as, csak forgatas kozben plusz terheles...es maris meguszta a "lusta" fejleszto hogy atmeretezze/vagja a texturat fajlt, mert igy is megy. Es meg sok ilyen "ugyes" megoldas van
Sajnos a legnagyobb problema, hogy mostmar a legtobb fejleszto nem veszi a faradtsagot hogy esetleg letesztelje egy fokkal gyengebb hardveren is a muvet. Lehet hogy a sajat gepen teljesen siman, nem egy nagy terhelessel megy a cucc, viszont mashol meg beakasztja az egesz rendszert.
-
#79
julius666
addikt
WonderCSabo
#74
julius666
addikt
válasz
WonderCSabo
#74
üzenetére
A Flashplayer által lejátszott file-t próbáltad lejátszani DShowban is?
-
-
nyogo83
senior tag
Lassan 10 eves flash fejlesztoi melom soran sokat lattam. Fejlesztettem online jatekon at full flash siteokon keresztul mindent. Mint hozzaerto, fogom a fejem mikor egy ket melot kapok es esetleg mas kodjaban kell turkalnom. Egy egy site/jatek optimalizalas utan 90%-os terhelesrol 10-20%-ra esik vissza.
Javareszt nem a flash hibaztathato, hanem 90%-ban a fejleszto. Gyatran optimalizalt kod, grafika, hanyagsag. Ezert is allok ertetlenul a kulonbozo "tunjon le a flash", "ez egy szar" tipusu hozzaszolasok elott, mivel ez "csak" a platform(esetek nagy reszeben nem ez a felelos)
Ha pl egy jatek rohadtul nincs optimalizalva, szaggat, esetleg igenytelen vagy idegesito, akkor az MS kellene szidni?
Mind1. Regota mar csak read only modban vagyok az ilyen temaju topikoknal, mert masok sokkal tapasztaltabbak, illetve jobban tudjak(olvastak) hogy mi hogyan miert ugy van.
-
nLali
őstag
Dehogy, nem írtam én semmit. Nagyon láma linux használó vagyok. Évente kiválasztok egy szimpatikus linuxot és használom néhány napig/hétig. Most Kubuntura esett a választás.( 2.6.35-25-generic; KDE 4.6.00 ) 5750 volt a gépemben. Vmi zárt aTi meghajtóval.Most Intel GMA X4500 van és minden akad.720p youtube már sok neki..
-
julius666
addikt
nem lehet, hogy egyszerűen csak tele van a net szánalmas szintű honlapépítők átal generált, Flash tartalmú mocsokkal?
Biztosan ez is benne van a pakliban, ettől viszont még az Adobe sara marad a dolog, mert ezek szerint szar fejlesztői eszközöket ad ki hozzá. De ettől függetlenül is amit a flash néha produkálni tud (amikor pl. tele van nyomva egy oldal - amúgy vér egyszerű semmi extra, szóval nehezen elszabható - flash bannerekkel és alig lehet görgetni) az röhej.
A többszálúság hiányának annyira nem kellene problémának lenni, miután a flash csak animációs dolgokra lenne hivatott (arról aki flashben számoltat valami komolyabb számításigényes dolgot hagy ne kelljen véleményt mondanom - illetve ha a jövőben valóban komoly 3D-s platformként is indítani akarják, na oda már kellhet a több mag) ahol is a számítások legjava a GPU dolga lenne, az hogy mégis csontra/közel csontra lezabál egy teljes magot az elég szomorú. Biztosan jobb lenne ha 4 magot zabálna el ugyanúgy...
A flashnek baromi nagy szerencséje a W3C "lassúsága" illetve a piaci szereplők töketlenkedése (lásd a H264 vs. VP8 párharcot ami a HTML5 video tag elterjedését kb. évekkel veti vissza), amúgy boldogan felejtette volna már el mindenki rég a búsba.
Apropó, ez az új flash plugin amire Abu már jópár topikban annyira ráizgult?
-
Zolli77
csendes tag
A Flash tényleg egy hasznos technológia de csak mint különálló alkalmazások.
Pl. minden web-el foglakozó ember rémálma amikor meglát egy Flash-el megvalósított navigációt, üdvözlőképernyőt amin ott van a tovább gomb. Most ezzel az a baj hogy a keresők nem indexelik a flash tartalmat meg ha véletlenül nincs a user-nek flash player-e (mert céges környezet stb...) akkor már barangol is arrébb.Ezen javíthatnának valamit, hogy esetleg a keresők követhessék a rajtuk lévő tartalmat
De én most a flash-nek kétségkívül a asztali alkalmazásfejlesztésben látom a jövőjét (AIR).
-
doc
nagyúr
amúgymeg az általad említett valódi crossplatformságot próbálná megcélozni a mono projekt (silverlight párjaként a moonlight), és azért látszik hogy az ms törődik ezekkel a platformokkal
epp ellenkezoleg, az latszik hogy a MS korulbelul nagy ivben leszarja a mas platformokat. Silverlightbol az OSX-es, hivatalos verzio egesz jol all, a Linuxos durvan le van maradva, a mono meg kb. semmire nem jo (egyetlen, windowsra irt .NET programot sem sikerult vele futtatni amit szerettem volna, pedig egyik sem volt nagy igenyu) -
PuMbA
titán
"Ha a procin múlna, akkor biztosan akadna."
Ezt honnan tudod? Linuxon a YT videók csak NVIDIA kártyával gyorsítottak, netán megírtad az ATI-n működő VAAPI változatot?Egyébként Linuxon nekem sokat javult a teljesítmény valami miatt. Eddig a 480p is alig ment fullscreenbe (mindkét mag kihasználtsága az egekbe volt és akadozott a Flash Player GUIja) most meg a 720p is simán megy teljes képernyőn egy 1,6Ghz-es sima Core Duo-val, ami asztali viszonylatban egy nagyon gyenge proci - ráadásul ősrégi.
-
#68
Depression
veterán
Depression
veterán
Sokan itt csak a videókkal foglalkoznak, pedig a játék része legalább annyira fontos lenne.
Rengeteg flash játékkal játszom, a legidegesítőbb az egészben, hogy minden folyamatosan akad, szinte nincs is olyan komolyabb játék, ami nem szaggatna.
Egyrészt eszméletlenül boldog lennék, ha ezek normálisan működnének, de tartok attól, hogy azt a kismillió játékot úgysem írnák meg semmilyen más nyelven újra.
Azaz reménytelen a flash elbukása. Szerintem.
Van egyáltalán olyan facebook (azért írtam ezt, mert itt több tíz millió játékos van) vagy komolyabb böngészős játék, ami nem flash-sel működik? -
#67
fordfairlane
veterán
cousin333
#48
-
oO7
őstag
azért a silverlight és a javascipt más tészta... a javascriptre pár évvel ezelőttig - amikoris elkezdett lángolni ez a HTML5 mánia - senki nem gondolt úgy, hogy annak majd tényleg komoly mennyiségű számítást kellene végeznie... és igazából még a mostani agyonoptimalizált motorokkal is bőséges lemaradásban vannak a javascripttel akár a flash akár a silverlight (egy rendes java vagy .net, netántán natív kód futási sebességétől...
oké most fellángolt de nem fogják tudni ezt az iramot tartani, sőt...a másik oldalról pedig mondjuk ottvan a silverlight aminek szintén minden verziójánál több 10% -os sebességnövekedést meg betöltődési idő gyorsulást produkálnak...
(mostmár a 4-essel egészen jól megközelítik a .net sebességét ami meg egésze jól megközelíti a natív kód futkározásának sebességét... )amúgymeg az általad említett valódi crossplatformságot próbálná megcélozni a mono projekt (silverlight párjaként a moonlight), és azért látszik hogy az ms törődik ezekkel a platformokkal mert teljesítmény/stabilitás terén nem igazán tudják a "referencia értékeket" produkálni a mono -s megoldások...
-
doc
nagyúr
ugyanaz a gondolatmenet huzhato ra a flashre is
te pl. nem orulnel annak, ha amit megcsinalsz most Silverlightban, az a vilag osszes olyan gepen futna, ami tud flasht futtatni? megfelelo, nyilt szabvanyokkal ez siman mukodne, es nem azt kerdezne az eCCeri user Kovacs Joska a raktarbol hogy 'szilverlajt? azmegmi, sosem hallottam?'
-
Én legszívesebb a kukában látnám a flasht, ha végre minden böngésző támogatni fogja a HTML5-t, és a hardveres gyorsítást. Anno csak is azért jöhetett be a böngészőkbe a flash, java, meg még isten tudja mennyi 3rd party szoftver, mert a HTML kb 2000 (!) óta nem fejlődött az égvilágon semmit. Viszont most itt a HTML5 + HW gyorsítás, szerintem már semmi értelme a 3rd party embedded cuccoknak.
-
doc
nagyúr
latom baromira nem vagy kepben, ami alapvetoen nem baj, csak akkor ne tamadd le a masikat, ha nem erted mirol beszel...
itt a gyorsaságot az adott javascript motor implementáció adja és nem az, hogy a javascript mint olyan nyílt
es szerinted ha a JS zart lenne, es egyetlen ceg egyetlen pluginje lenne kepes futtatni, akkor ugyanilyen gyors lenne? megnyugtatlak, hogy tavolrol sem, sot, pont olyan fos lenne mint a flash. azert nagyon gyors a JS a bongeszokben, mert NYILT, ezert minden gyarto sajat JS engine-t rak ala (mint ahogy azt te magad is eszrevetted), igy kialakul a verseny, ami pedig gerjeszti az egyre jobb es jobb termeket (ha meg igy sem vilagos, probalj esetleg egy alapszintu kozgazdasag-konyvet olvasgatni, ott sok tekintetben hasonlo folyamatokrol van szo)mint ahogy a .NET -et is csakis és kizárólag azért csinálták, hogy nehogy a Java -t kelljen használni...
ismet nem nagyon vagy kepben...
a MS valoban a Java lenyomasara talalta ki a sajat kis haziszabvanyat (pont errol beszeltem az elobb), ami a .NET plusz a hozzapasszintott nyelveket allitja szembe a Javaval. a ketto kozel sem 100%-ban feleltetheto meg egymasnak, bar teny hogy eleg nagy az atfedesvéletlenül sem azért ugye mert, hogy az ms megoldása úgy nagyságrendekkel jobb ?
van 'szerencsem' C++/C#/.Net-ben es Javaban (bar ez utobbi gyakorlatilag csak Android) fejleszteni, es allithatom, hogy a .Net NEM nagysagrendekkel jobb. mondjuk en szemely szerint egyiket sem szeretem tulzottan, bar maga a nyelv (marmint a C#) az orbitalis Java-nyulas, 'majkroszoftositva', szoval tulajdonkeppen ez egy nyelv, amit nem szeretek a .NETtol meg a hajamat tudom tepni, foleg miutan volt szerencsem (es ez most tenyleg az) a profi modon megtervezett, remekul atgondolt, elsorangu dokumentacioval ellatott Qt-t megismernide ez mar baromira mas tema, de ha mar felhoztad, legyen:
ott is megtehette volna a MS hogy letrehoz egy, a Sun Java-eval teljesen bytekod-kompatibilis VM-et, es nem nevezi el a Javat C#-nak, hanem meghagyja
de a Flash-sel szemben a Java (barmennyire is ruhellem) azert kozel sem olyan otvar iszonyat, mint a Flash, raadasul arra, amire kitalaltak, a mai napig a legjobb: teljesen platformfuggetlen alkalmazasok keszithetok vele (az, hogy sokan eleg balfaszok ahhoz, hogy nem hogy sok, de meg egy-ket platformon is alig menjen, mar mas kerdes). nem veletlenul lett pl. a mobiltelefonokon mindenhol teljesen altalanos. ha olyan kvazi hasznalhatatlan lenne, mint a Flash, ez eselytelen lenne. nezd csak meg mi megy most a mobiloknal: a legerosebb vasakon mar megyeget a flash, irtozatos CPU/akksizabalo modon, a Javas programoknal sokkal-sokkal kevesebbet nyujtva -
DMG
senior tag
Most próbáltam ki egy igényes Tower Defense Flash játékot, két magom van, mind a kettőt ugyan annyira használta, max 60%-al, szóval hacsak játék mellett nem csinálok mást, akkor mért fekszik meg tőle a gép? Persze ha vannak a terepen hatvanezren, akkor nyílván megfogja, de ezt a "csak egy procit használ" dolgot akkor sem értem?
-
#58
Badman 4ever
őstag
_Orbi_
#43
Badman 4ever
őstag
(2600XT-vel megtámogatva határesetes...)
Azt meg hogy a csodába? A Flash HD gyorsításához UVD 2.0 kell, azt meg csak a HD 4000/HD 5000/HD 6000 széria és az integrált kártyák tudják (UVD 2.0 Lite - HD 3200/HD 3300/HD 4200, UVD 3.0 - Brazos). Nekem a HD 3650 AGP malmozik Flash alatt, 480p-n teljes képernyős módban meg is hal a Tualatin, viszont Media Player Classic-kal a letöltött 1080p-s Flash videót is visz a gép, mint állat, mert dolgozik a VGA, de Flash alatt ugyanez nem működik. -
oO7
őstag
oooohhohoh !!! te el is hiszed amit mondassz ?
"ebbol is latszik hogy a nyilt megoldasok ossze sem hasonlithatoak a zartakkal hatekonysagban, nyilvan az elobbiek javara"
ezt nem tudom értelmezni... itt a gyorsaságot az adott javascript motor implementáció adja és nem az, hogy a javascript mint olyan nyílt... a motorokat meg mindenki maga csinálgatja (kivéve aki mégsem, de az meg akkor csak ráépít valakinek a motorjára a böngészőjét és nem módosítja/fejleszti a motort, csak használja)...az meg, hogy "a flasht az menthette volna meg, ha a Microsoft szakit a hisztis ovodas hozzaallasaval hogy neki mindig mindenbol sajat haziszabvany kell"... hát megintcsak a WTF kategória... mint ahogy a .NET -et is csakis és kizárólag azért csinálták, hogy nehogy a Java -t kelljen használni... véletlenül sem azért ugye mert, hogy az ms megoldása úgy nagyságrendekkel jobb ? (akár a java akár a flash esetén)...
(#53) Morden24: a tabok külön processként kezelése még nem feltétlenül garantálja, hogy külön szálra kerüljenek a tabok... bár valószínűleg azért törekszik rá... de ettől függetlenül nagyon sok terület van ahol azért magának a programnak a több szálon történő futtatása nagyon sokat tudna lendíteni a gyorsaságon, reszponzivitáson (mi ez rendes magyar szóval ? )
-
doc
nagyúr
nem lehet, hogy egyszerűen csak tele van a net szánalmas szintű honlapépítők átal generált, Flash tartalmú mocsokkal?
dehogynem, szerintem itt a topicban ezt senki nem is vonja ketsegbea flash nem attol szar, hogy ne lehetne 'szep' es 'igenyes' dolgokat csinalni benne. lehet. sot, maga a nyelv, az ActionScript3 nem is olyan rossz, baromi egyszeruen lehet benne olyasmit csinalni, amire a flasht kitalaltak (tehat mindenfele interaktiv bigyot pl)
a problema az, hogy embertelenul zabalja a vasat. nezz meg egy atlagos minosegu/kidolgozottsagu Flash jatekot ami mondjuk a kepernyo egytizedet foglalja el - ahogy pl. a Kongregate-en akarok jatszani valamit, kapasbol felzug a procihuto venti a notebookban. es ezek nem valami high-end jatekok, 10 evvel ezelott sima, asztali jatekkent mar teljesen eselytelenek lettek volna... (attol maga a jatek meg lehet nagyon jo persze, de a HW-igeny es a nyujtott grafika baromira nincsenek egymassal epeszu viszonyban)
-
Morden24
nagyúr
Bár nem mondom, hogy szeretem alapvetően a Flash-t, és ritka igénytelen dolgok tudnak szembejönni ám a neten, sőt - a magam WM-es, Operás idejében a Flash Lite lepusztítása az első dolog volt a PDA-ról, mert a hiánya konkrétan javította a böngészési élményt... DE!
Csak nagyon halkan, hozzá nem igazán értőként teszek fel egy kérdést: nem lehet, hogy egyszerűen csak tele van a net szánalmas szintű honlapépítők átal generált, Flash tartalmú mocsokkal?
Mindezt csupán azért kérdezem, mert én is sokszor futok szarba, de nem általános: azaz látok szép, igényes és normálisan kivitelezett honlapokat is. Innentől fogva, ha lehet azt a vésőt normálisan is használni, akkor a szobrász hibája, ha fekáliát generál.A zártsággal, fejlődéssel stb. egyetértek (tudom, meglepő módon), a technikai hátteret meg nem ismerem (az tényleg száni, hogy nincsen többszálú futás, bár lehet hülyeséget kérdezek: a tabok külön processként kezelése ezt a gondot nem teszi relatíve irrelevánssá?), viszont egyszerű webet használó egyénként kb. ez a véleményem.
-
doc
nagyúr
válasz
cousin333
#48
üzenetére
A böngészőgyártók gyilkos tempóban fejlesztenek, a JS ugye 1-2 év alatt vagy 15-20-szorosára gyorsult, és küszöbön a HW gyorsított böngészők kora
ebbol is latszik hogy a nyilt megoldasok ossze sem hasonlithatoak a zartakkal hatekonysagban, nyilvan az elobbiek javara
a flash plugint egyedul az Adobe fejleszti, nincs mogotte mas penzes nagyvallalat - meg is latszik... a flasht az menthette volna meg, ha a Microsoft szakit a hisztis ovodas hozzaallasaval hogy neki mindig mindenbol sajat haziszabvany kell, es nekiall a sajat flash playeret (ami nyilvan teljesen kompatibilis az Adobe-eval!) megcsinalni, mostanra lenne fasza gyors, HW-gyorsitott flashunk amivel nem zabalja fel a paksi atomeromuvet is a legujabb tower defense
bar tartok tole, hogy az Adobe ezt nem hagyta volna csak ugy (azt sem tudom, mennyire nyilt maga az swf) -
DMG
senior tag
Tud valaki linkelni egy olyan flash tartalmat ami megfekteti a procit, mert én most hírtelen nem találtam, pedig csak egy kétmagos intel csücsül a gépemben. Tényleg érdekelne.
Amúgy most tanulom a flasht (jobban mondva frissítem a tudást, mert már rég volt), és tényleg érdekelne, hog ymi lesz a jövője, én bízom benne, hogy azért van hova fejlődnie, és úgy gondolom, hog yjelen helyzetben is lehet használni, a legtöbb böngésző alapú játék, még mindig flash amennyire én tudom. Ez a 3D meg jó jó, de minek? Mi az előnye azon kívül, hogy nem foglalja a helyet a gépen a játék?
A böngészős játékoknak amúgy is megvan az a retró hangulata, ami azért nem hiszem, hog yvalaha is kihalna, arra meg jó a flash. Rengeteg ember szereti lefoglalni magát egy 2D-s böngészős játékkal amiube ösz visz egy gombot kell csak használni, és még sorohatnám, ahol nem a grafika, hanem a játékélmény a lényeg. Én szomorú lennék, ha a böngészős játékok is átesnének a ló túl oldalára, jó grafika, semmi játékélmény.
-
hohoo
senior tag
flashblockot kell használni (minden böngészőre van), szépen a flash helyén egy gomb van amivel meg lehet nyitni még is, de fehérlistázni is lehet (pl youtube). Ha blokkolva vannak a flash reklámok, előbb utóbb rájönnek hogy nincs értelme
olyan trójait kéne készíteni ami flashblockot telepít, és ie6-ot frissít
-
cousin333
addikt
Nekem nincs különösebb bajom a Flash-el, bár feltűnő, hogy csak azután kezdték el látványosan fejleszteni, hogy egyre többen szólaltak fel ellene, és már nem csak az átlag felhasználók.
Szóval fejlesszenek Flash alkalmazásokat, nem bánom - de ne a böngészőbe (honlapokba)! A beépülők úgy általában egyfajta zárványt képeznek a böngészőben, több kárt okoznak, mint hasznot.
Most már lesz jónéhány technológia amivel bűvészkedni lehet (pl. HTML5 és csatolt részei), amik teljesen nyílt alapokon állnak. A böngészőgyártók gyilkos tempóban fejlesztenek, a JS ugye 1-2 év alatt vagy 15-20-szorosára gyorsult, és küszöbön a HW gyorsított böngészők kora. Szóval szerintem ha honlap, akkor alkalmazzák ezeket, ha meg valami nem megy, akkor találjanak hasonló megoldásokat (pl. HTML6), vagy ne is erőltessék a dolgot.
-
A Flash ipari méretekben hulladék. Ronda, állandóan fogja a CPU-t, jónéhány esetben biztonsági problémák is voltak vele. Manapság meg mintha muszáj lenne, olyan mértékben terjed a weblapokon, így egy oldal betöltése nem villámgyors, de legalább lassú. Felőlem elmehet a fészkes fenébe a gyártójával együtt...
Teljes mértékben egyetértek dabadabbal.
-
Nálam a megfektetés az, hogy hosszú-hosszú tizenmásodpercig csak néz ki a fejéből.
(#44) rt06: Amikor belefutok megint egybe ígérem átküldöm PÜ-ben.
MOD: ha olvasol logoutot biztos megvan az az élmény amikor kint volt az aqua banner....
MOD2: amikor még fent volt az MSN simán produkálta a beépített reklámmal is....
-
-
#51736960
törölt tag
-
-
#36
bitblueduck
senior tag
A flash-re ugy tekintek, mint valami nem tul jo nem tul rossz dologra. A html szerintem katasztrofa, exploit halmaz. hyper text markup aztan 3D grafikara hasznaljak, meg a firefox ala vagnak, hogy egyesek a video taget nem szabad codec-el kepzelik el... Az ilyen tartalmakhoz inkabb illik flash, de bele kellene huzniuk, es mindig lesz egy kis keseru ize szamomra az actionscript 2 meg egyeb katasztrofak emlekei miatt.
Fejlesztoi szempontbol meg azt mondom Silverlight, remelem MS is igy gondolja majd a jovoben, usernek meg windowson mindegy, mas rendszeren meg nem szivhat sokkal jobban, mint flash-el. -
Engem sokkal inkább az érdekel, hogy mikor szűnik már meg végre...
-
hohoo
senior tag
-
"Linux currently lacks a developed standard API that supports H.264 hardware video decoding"
Igen, ezt én is olvastam, csak az volt a vicces, hogy akkor, amikor ezt írta, már jó ideje futott az ionos, linuxos HTPC-imen a full HW-gyorsított h.264 lejátszás (magába az mplayerbe 2008 végén került bele, de az XBMC-be is ott volt már 2009 nyarán), illetve már azelőtt egy évvel ott volt mind a tökszabványos VA-API, mind a nvidia háziszabványa, a VDPAU.
Ezért voltam olyan bátor inkompetensnek nevezni a t. fejlesztőt. -
Jé , tényleg, a 10.2 bétában már ott van, ami tulajdonképpen nagy előrelépés ahhoz képest, hogy egy éve még ott tartott, hogy ez konkrétan lehetetlen
Mondjuk a VDPAU a VA-API helyett azért elég izé választás, de hát úgy látszik, tényleg csak ennyire telik... -
doc
nagyúr
a google tobb phoronixos cikket is talalt, pl: [link]
egyebkent teljesen egyetertek azzal, hogy a flash (amellett hogy tenyleg gyors fejlesztest tesz lehetove) borzalmasan lemaradt sok tekintetben. irtozatos modon lassu, a HW-gyartok hiaba jonnek ki ujabbnal ujabb, gyorsabbnal gyorsabb procikkal, nem tudnak lepest tartani a flash lassusagaval (hogy kis kepzavarral eljek
). remelhetoleg a vegre-valahara megszuleto HW gyorsitas segit majddolgoztam anno PaperVision3D-vel, mikor a megrendelo 3D-s scene-t szeretett volna a weboldalara, volt valami 6-8 db modell, mindegyik 30-40 haromszogbol maximum, es brutalisan megfogott meg egy erosnek szamito gepet is (legalabbis szerintem, a megrendelo elegedett volt a 10-20 FPS-sel...)
-
moonman
titán
"Milyen hardveres gyorsítás"
"Take advantage of hardware accelerated graphics in Internet Explorer 9 with Flash Player, utilizing hardware rendering surfaces to improve graphics performance and enable seamless composition."
és hogy miért IE?
"In Flash Player, H.264 hardware acceleration is not supported under either Linux or Mac OS X. Linux currently lacks a developed standard API that supports H.264 hardware video decoding, and Mac OS X does not expose access to the required APIs."
persze tudom, a Linux megválogatja a barátait.
-
_Orbi_
aktív tag
Én annak örülök kifejezetten, hogy a Firefox-hoz létezik flash blokkoló kiegészítő. Nincs az a sok csicsa mozgó hülye reklám és a többiek. A gépem meg nyugodtan van és nem kicsit spórol az árammal. Engem idegesítenek a "flessek"
Amúgy tényleg szép és részletes írás. Elismerésem!
-
Őszintén szólva teljesen értetlenül állok a cikkíró lelkesedése előtt.
A Flash grafika terén ott tart, ahol a PC-k a kilencvenes évek elején tartottak. Az majdnem húsz éve volt. Nagyon-nagyon régen. Most tényleg annak kell örülni, hogy a pixeleket egyenként meg lehet címezni?... Mióta vannak pixelek, ez kb. azóta így van, helló, hatvanas évek.
A hardveres videógyorsítás szinte teljes hiánya egyszerre röhejes és abszolút érthetetlen. Azt a döntést meg, hogy a pixelbender GLSL-jét szoftveresen számolják... hát, komolyan, összesen annyit tudok mondani rá, hogy nekem is küldjenek abból, amit szívnak, mert nagyon ütős anyag lehet
Azt meg ezek után már említeni is alig érdemes, hogy a linuxos portot egy jobb képességű csimpánz is sikeresebben gondozná, mint a jelenlegi adobe-os ember, akinek leginkább csak nem sikerül implementálnia a dolgokat, Linuxon jelenleg sincs semmilyen HW-s gyorsítás, videóra se. Azt meg szint magától értetődő, hogy az olyan teljesen felesleges és abszolút egzotikus igények, mint a többszálú futás meg a 64 bites mód támogatása, csak néhány elszállt kockának jut eszébe, az Adobe-nál senkinek sem.Ezek után szerintem elég nyilvánvaló, hogy minél előbb kipusztul a Flash, annál jobb az egész világnak.
-
#2
oO7
őstag
Neil Watts
#1
oO7
őstag
válasz
Neil Watts
#1
üzenetére
+1
jó kis írás, grat hozzá -
#1
Neil Watts
veterán
Nagyon jo es reszletes iras!
Gratulalok!
![;]](http://cdn.rios.hu/dl/s/v1.gif)
vissza a tervezőasztalhoz...
Bár a Java-nak lenne ilyen sebessége..."
Új hozzászólás Aktív témák
- Samsung Galaxy S23 Ultra 8/256GB Megkímélt,Kártyafüggetlen 1cm karc a kijelzőn. 1 Év garanciával!
- Apple iPhone 13 128GB 100% Akku Újszerű,Kártyafüggetlen,Dobozos,Tartozékaival. 1 Év garanciával!
- Apple iPhone 15 Pro 100% Akku Újszerű,Kártyafüggetlen,Dobozos. 1 Év Garanciával!
- Asus TUF Gaming A17 - 17.3"FHD IPS 144Hz - Ryzen 7 6800H - 16GB - 512GB - Win11 - RTX 3050 Ti - HUN
- Apple iPhone 15 Pro Max 256GB 100% Akku Újszerű Kártyafüggetlen,Dobozos,Tartozékaival. 1 Év Garanciá
- GYÖNYÖRŰ iPhone 14 Pro 256GB Deep Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3352
- HIBÁTLAN iPhone 12 mini 128GB Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3392, 94% Akkumulátor
- Bomba ár! Dell Latitude 5300 - i5-8GEN I 8GB I 256SSD I 13,3" HD I HDMI I Cam I W11 I Gari!
- Eredeti, új Lenovo 330W töltők - ADL330SDC3A
- GYÖNYÖRŰ iPhone 13 Pro 256GB Graphite -1 ÉV GARANCIA - Kártyafüggetlen, MS3074, 100% Akkumulátor
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest