Programatori ze na zakaznika utoci nizkou cenou? Ale to preci neni pravda. Utoci se bezvyznamnymi featurami...nebo na nas MS utoci cenou? Tomu se fakt musim smat.
Printable View
Programatori ze na zakaznika utoci nizkou cenou? Ale to preci neni pravda. Utoci se bezvyznamnymi featurami...nebo na nas MS utoci cenou? Tomu se fakt musim smat.
preco generalizujes programatorov na M$?
ja myslim ze neboli vyvratene. Staci mi pustit dva programy naraz a uz to vyuzivam. Nemusi byt ani jeden z nich optimalizovany pre DC.Citace:
Původně odeslal PiT
nepravda. mp3 skodujem bez straty kvality 2x efektivnejsie na DC - staci skladbu rozdelit na 2 casti. Je ale pravda ze na DC bude vysledny subor asi o promile vacsi.Citace:
Původně odeslal PiT
DivX/Xvid skodujem bez straty kvality 2x efektivnejsie na DC - staci video rozdelit na 2 casti. Opat bude vysledny subor trocha vacsi.
Winrarom spakujem SO ZISKOM KVALITY v porovnani so SC rychlejsie - viz. fox murderov priklad na program files.
Vo vacsine pripadov je zvacsenie vyslednych suborov minimalne. Otazne je teda, ci budete lpiet na usetreni tych par byteov, alebo vam to pojde 2x rychlejsie.
Iba? ale ved sme si tu ukazali mnoho inych pouziti, kde DC vyznam ma.Citace:
Dnes a rovnako aj v minulosti mal DC vyznam *IBA* v CAD/CAM systemoch a specializovanych systemoch na strih videa obecne. (vynechajme servery, vojenske, technicke simulacie a pod.)
driver uz mas multithreaded a uz tu niekto daval link na tomshw fora so zoznamom hier ktore podporuju dc.Citace:
Dnes z toho tazi iba Doom3 po patchi resp. Q4. Ostatne hry ani popel. V buducnosti je nastastie velka pravedpodobnost, ze to bude inak - ak to tak bude - bude DC vyhodne kupit. Dnes to tak nie je.
a niekto tu spominal winamp... bol som prekvapeny, ale winamp s pustenymi AVS dokazal vytazit HT p4 na 80%, t.j. 60% vykonu druheho "jadra" vedel vyuzit.
Asi by to chcelo pekne spisat vsetky argumenty proti a vsetky argumenty za. Celkovo mi DC pride omnoho uzitocnejsie ako sse8.
podobne si to precitaj ty, mohol by som sa obdobne smiat, bolo tu ukazanych zopar pripadov kedy sa to vyuziva prave teraz....Citace:
Původně odeslal PiT
pre DC zoptimalizujes kompilator a ficis. Skutocne optimalizacie na SSE a SSE2, take ktore mali razantny prinos vykonu, sa robili rucne.
A co sa tyka toho programovania, myslim ze programovat viacvlaknove aplikacie nie je az o tolko tazsie ako jednovlakna.
me se zda ze tady panove ac tomu zajiste rozumi vic nez ja, tak proste nahlizi na vec stylem, ze kdyz ja pro linux a programovani nepotrebuju DC tak musi byt nahov*o.
Ale pro uz ted pro bezne uzivatele neni! Ve windows ktery vetsina lidi pouziva je prechod na DC dost znat v beznem uzivani i se SC aplikacemi stejne tak dekodovani videa je rychlejsi (o tom ze bych ztracel kvalitu slysim teda prvne) a proto Vase argumenty jsou mozna technicky spravne - ale v praxi a na nejpouzivanejsim OS je to jinak.
To ze programatori budou mit vic prace s optimalizaci je smutne ale pokud budou chtit obstat v konkurenci budou muset optimalizovat at chteji nebo ne.
OMG, kolikrat se to tu resilo - jak psal Pit, doporucuji ti si opravdu precist tento thread (pripadne nam ukazat jak rozdelujes a pak spojujes MP3)Citace:
Původně odeslal THX
ha, to bolo popisane v jednom linku ktory tu tusim dal eagle ako priklad ze sa to nedaCitace:
Původně odeslal Caleb
Ako to teda rozdelim? Nezkodovany subor bez problemov rozdelim na dve casti. Ako spojim mp3ku? Jednoducho spojim dva skodovane mp3 zasebou a upravim hlavicku. A ak by som bol drsnak, tak ani neupravim tu hlavicku a pojde to prehrat, akurat nebude to asi ukazovat spravnu dlzku a niektore playere s tym mozu mat rozne mensie problemy.
A ze budes mit uprostred lupanec (v dusledku nedelitelnosti frame) to ti moc nevadi, ze? A to ze ti samotne rozdelovani a spojovani zabere vice casu nez kdyby si to enkodoval na SC (neni mi znam zadny nastroj ktery by tuto cinnost automatizoval) ti take nevadi?
Jiste existuje DC-optimalizovany Lame (s horsi kvalitou nez SC), muzes enkodovat vice WAVu najednou, ale tebou popsany postup je imho nesmyslny. Nebo si to snad zkousel?
Praveze lupanec tam nebude, pretoze sa vytvori novy frame a to je tiez dovod, preco bude vysledny subor trocha vacsi. Rozdelovanie a spajanie ak mi ma zabrat vela castu v porovnani s enkodingom znamena, ze enkodujem kratke skladby - ak su to napr. pesnicky albumu, mozem ich enkodovat paralelne, ak je to jedna dlha hodinova skladba, tak potom mi delenie a spajanie prinesie usporu.Citace:
Původně odeslal Caleb
(tento link sem dal eagle) http://forum.doom9.org/showthread.php?t=115822
Teda, nie neviem o programe ktory by to robil automatizovane, ani som ho nerobil, ale vravim ze to nebude zlozite a ze tento program bude robit:Citace:
Původně odeslal omion
1. rozdeli neenkodovany subor na dva casti
2. pusti paralelne enkodovanie oboch casti
3. pospaja vysledne subory (a to sice tak, ze z nich povyhadzuje hlavicky a vezme iba data)
4. vytvori novu hlavicku kde nastavi spravne informacie o dlzke atd.
Tuto novu hlavicku moze vytvorit modifikovanim hlavicky 1. vysledneho mp3 suboru kde zmeni informacie na skutocne po pospajani odpovedajuce.
V bode 2 predpokladam enkodovanie s rovnakymi nastaveniami enkodera.
Kdybych ti dal priklad z aplikacnich serveru nebo z IDE, tak nevis o cem mluvim ;-)Citace:
Původně odeslal tomase
Muzes nejak dokazat, ze to lze? Pomoci kterych nastroju by si to vytvoril (tj. nastaveni enkoderu Lame aby nevytvarel na zacatku a konci MP3ky mezery) a pomoci ceho by si to spojoval? To ze je neco teoreticky mozne (coz ale imho neni tento pripad) neznamena ze to je prakticky realizovatelne (se softwarovymi nastroji ktere jsou k dispozici). Mam neustale pocit, ze varis z vody - nebo si snad myslis ze vyvojari Multi-threading LAME sou tak hloupi, ze by neprisli na to, ze (podle tebe) staci vstupni soubor rozsekat na kousicky, paralelne enkodovat a pak pospojovat a misto toho resi nejakou DC optimalizovanou verzi co enkoduje stejne sekvencne. Chci dukaz misto slibu :pCitace:
Původně odeslal THX
novy frame tam vznikne, pretoze na zaciatku kazdej jednotlivej casti samozrejme bude novy frame. Ake nastavenia lame pouzit neviem - nepouzivam lame. V podstate si uz ani nepamatam kedy som naposledy enkodoval. Ale predpokladam ze existuje nejake nastavenie lame, ktore do enkodovanej skladby nepridava na zaciatku ani na konci ziadne medzery, fadeouty atd. a ze len enkoduje presne to co dostane nekomprimovane na vstupe.Citace:
Původně odeslal Caleb
Mam dojem, ze vyvojari multithreaded lame sa vybrali inou cestou ako delenie suborov a teda tam robia ten multihreading uplne inac (tak, aby mohli spracovat subor sekvencne).
Program ktory by delil skladby a potom ich spajal potrebuje od enkodera v podstate iba vytvorenie frameov. Ak ma lame nejaky option, nech nepridava na zaciatok (ani koniec) id3 tagy, tak by malo stacit appendnut tie dva subory. Potom by to chcelo este k vyslednemu suboru pridat tie id3 tagy...
Preco potom vsetci, ktorych poznam, pouzivaju ACAD a Cinemu, ked je tak vela CADovych programov pre linux?Citace:
Původně odeslal Petrik
O rastrovych programoch by som rad vedel, pretoze to je to jedine, co ma momentalne drzi pri Windoozoch.
Ktore velke firmy konkretne?
Ktore?Citace:
Původně odeslal Petrik
Pre bezneho pouzivatela iba multimedia a pakovanie programov.
Multimedia - bolo tu toho dost. So sucasnymi kodekmi nepohnes bez straty kvality. Ako to vymyslia u novych, uvidime.
Pakovanie - tiez to tu bolo - bez straty kvality (velkosti) v sucasnosti nepohnes, uvidime o par mesiacov.
http://forums.macrumors.com/showthread.php?t=245733Citace:
Původně odeslal Petrik
"As far I know, neither of these apps are built to exploit multi-processor machines."
M$ ma na desktopovom trhu bohuzial prakticky monopol...Citace:
Původně odeslal mraky
Omyl, dva programy, ktore dokopy zatazuju jeden procesor na viac ako 100%.Citace:
Původně odeslal THX
Inak nie. A aj to za predpokladu, ze ti dementny windows scheduler nebude ich vykon nahodne prehadzovat z jadra na jadro.
Zacal som debatu o tom v tomto threade podobne ako ty. Selskym rozumom su multimedia totizto jedna z mala spolahlivo paralelizovatelnych veci.Citace:
Původně odeslal THX
U LAMEu a navrhu MP3 ako takom je to vdaka bit reservoir a samotnej specifikacii MP3 s 3ma typmi blokov nerealizovatelne bez straty kvality (bud lupanec v strede alebo v strede znizena/zvysena kvalita => vysledny subor iny)
Vysledny subor bude bud mensi alebo vacsi... Kvalita rovnaka nebude. Zhodli sme sa tu na tom, ze prvy pass je lahko paralelizovatelny (aspon u XviDu), pretoze tam ide kodek na maximalnu velkost... Druhy uz ma opat problem podobny ako u MP3, no v x264 kodeku to uz nejako vyvojari tusim okaslali.Citace:
Původně odeslal THX
Vysledna velkost suboru je vacsia. Je to teda ZISK kvality alebo STRATA kvality?Citace:
Původně odeslal THX
Zasadna otazka pre mna je ale ta, ze dostanem uplne iny subor... Proste spustim tu istu vec na roznych pocitacoch a dostanem iny vysledok. To je na pozastavenie sa.
Asi by chcelo.Citace:
Původně odeslal THX
Asi by to chcelo poriadne otestovat vsetko mozne na nejakom C2D a na tom istom akurat s disablovanym jednym core.
Programoval si niekedy?Citace:
Původně odeslal THX
Linux ma prave MC riesene podstatne lepsie ako WindowsCitace:
Původně odeslal Poofy
Bavili sme sa o kodovani videa, nie dekodovani. Ak dekodovanie pouziva obe jadra, stracas vyhodu multitaskingu.Citace:
Původně odeslal Poofy
To je to, na co Eagle poukazuje v podlednych postoch. M$ nic nenuti to robit, lebo ma dominantne postavenie. Beznych programatorov nic nenuti to robit, lebo im to nikto nezaplati. A programatori, ktorym to niekto zaplati, to uz davno spravili/robia :)Citace:
Původně odeslal Poofy
A myslim ze u pocitu to zustane - je to problem samotneho navrhu formatu MP3.Citace:
Původně odeslal THX
Presne tak, jeden spojovaci frame by kvalitu asi moc neovlivnil, ale pri prechodu na multicore by techto framu bylo v souboru cim dal tim vice a kvalita by byla o necem jinem.Citace:
Původně odeslal PiT
2THX - nejde o to, ze by idea rozdeleni souboru a enkodovani byla spatna, pouze je konkretne u MP3 formatu nerealizovatelna - imho by se s timto muselo pocitat uz pri navrhu samotneho formatu (jak zde psal Pit) a je dost dobre mozne, ze diky teto vlastnosti by mel ve vysledku horsi pomer velikost/kvalita.
ja tvrdim zvysena kvalita, lebo novy keyframe a preto aj vacsi vysledny suborCitace:
Původně odeslal PiT
OK, vysledna kvalita, ani subor rovnaky nebude. Ja tvrdim ze sa to bude lisit zanedbatelne, naproti comu sa rychlost enkodovania bude lisit vyrazne a teda mi to za tu malu zmenu stoji. Tak ci tak - je to stratova kompresia, takze ma vobec nezaujima ci na dvoch pocitacoch bude ten subor presne rovnaky.Citace:
Původně odeslal PiT
Citace:
Vysledna velkost suboru je vacsia. Je to teda ZISK kvality alebo STRATA kvality?
Podla mna je 851 150 viac ako 702 859 a teda mutithreaded verzia okrem toho ze bola rychlejsia, v tomto pripade este aj lepsie spakovala. Ale opat opakujem - tie rozdiely su tak male, ze su (podla mna) zanedbatelne.Citace:
Původně odeslal Fox!MURDER
to je ako keby si si pustil dva rozne verzie wordu a napisal tam presne uplne rovnaky text a saveol to a vadilo by ti ze to ma roznu velkost. Aj ked je to korektne ulozene a korektne precitatelne. Co ti vadi na tom ze multithreaded winrar produkuje ine vysledky ako single threaded? Preco by to malo byt zle? Co ak ma problem viacero spravnych rieseni a nie len jedno?Citace:
Zasadna otazka pre mna je ale ta, ze dostanem uplne iny subor... Proste spustim tu istu vec na roznych pocitacoch a dostanem iny vysledok. To je na pozastavenie sa.
anoCitace:
Programoval si niekedy?
To zalezi od toho, ako to vide. Ak vide dobre, kvalitu toho frejmu zvysi, ak zle, znizi :)Citace:
Původně odeslal THX
Ak to bude nepostrehnutelne, tak je to v podstate jedno. V sucasnej dobe to ale bud nejde alebo to postrehnutelne je (lupanec). Uvidime u buducich kodekov.Citace:
Původně odeslal THX
Foxov test: Na nete je zasa presny opak :) Co uz.
Word: Nezmyselny argument.
WinRAR: Pokial budu mutlithreaded vysledky vzdy lepsie, tak nic :)
Programovanie: A programoval si aj pre viacprocesorove systemy resp. vies ako funguje linker a kompilator, ked si myslis, ze kompilatorom to vyriesis?
kompilatorom sa to v niektorych pripadoch moze ciastocne zlepsit - optimalizovat pre instrukcie je samozrejme jednoduchsie. Intel teraz chysta nejaky novy optimalizovany kompiler pre DC. Chcel som tym len povedat to, ze skutocne optimalizacie, ci uz na SSE alebo DC sa nakoniec robia tak ci tak "rucne" a automatickymi optimalizaciami kompilatora mozno dosiahnut ciastocne uspechy, ale velmi to zavisi na tom, co sa kompiluje.Citace:
Původně odeslal PiT
Ad. foxov test - ide len o to, ze ktosi tu tvrdil ze to bude VZDY horsie a to sice takym sposobom, ze nestoji za to to vyuzivat.
Ty by sis koupil antivir kvůli rychlosti detekce? Já teda kvůli co nejvyšší pravděpodobnosti odhalení virů a kvůli nejlepší podpoře. Pak mi taky musí sednout jeho ovládání. Rychlost je až někde na konci, protože si scan pustím v době, kdy bude počítač málo vytížen.Citace:
Původně odeslal THX
Tady tě asi překvapím - end-usera absolutně nezajímá, jaké instrukce procesor má. Jeho dokonce ani nezajímá, jestli je to z transistorů, laserů nebo čehosi. Jemu jde v zásadě jen o jedno - aby pro něj měl odpovídající hodnotu. Ta se povětšinou měří spolehlivostí (lidi chápou PC jako služku, ne něco, čemu budou sloužit oni) a výkonem v jimi oblíbených aplikacích.Citace:
Původně odeslal THX
Takže podle tebe třeba Grisoft tě může ovlivnit na jeho antivir tím, že bude tvrdit, že poběží o 10 % rychleji na dual-core (víc asi sotva - limitace diskem)? Tak to nevím, co by jim na to zákazníci řekli - viz moje odpověď na první citaci.Citace:
Původně odeslal THX
A já tvrdím, že až na specifické úkoly orientované především do oblasti serverů a pracovních stanic (kde si za příslušný software náležitě zaplatíš) a na některé typy multimédií to pro lidi momentálně význam nemá. Možná v budoucnu, ale do té doby klidně ušetřím.Citace:
Původně odeslal THX
Tak to je super. A kvůli takovéhle kravině poběží můj oblíbený program pomaleji? Děkuji, nemám zájem.Citace:
Původně odeslal THX
My jsme tu především dokázali, že to je podstatně dražší! Dneska se všichni na všechno dívají přes peněženku, se podívej na prodeje hardware, co frčí. A prostě málokdo bude ochoten zaplatit dvojnásobek. Podívej se třeba tady na propagátora Petrika - jede na ušmudlaném přetaktovaném Sempronu. Proč? Protože prostě nechtěl dát do počítače víc peněz. Bude je chtít dát do software?Citace:
Původně odeslal Fox!MURDER
Tohle není věc, která se nabízí. Vnímáš to lehce zkresleně. Pomineme-li to, že pro výrobce procesorů je podstatně levnější vymýšlet jednoduchá jádra než investovat zisky do R&D a zlepšovat paralelismus / frekvenci (i to se dá), pak máš dvě situace:Citace:
Původně odeslal Fox!MURDER
1) Jedno jádro (případně málo jader) na vyšší frekvenci.
2) Hodně jader s nízkou frekvencí.
Nic mezi tím neexistuje. Protože aplikace většinou další jádra nedokázou využít (a nebo si za ně sakra dobře zaplatíš!), jsem pro první řešení. Nehodlám obětovat 20 % výkonu ve většině aplikací tomu, aby mi pár aplikací běželo o řádově 40 % rychleji.
Takže sám uznáváš, že "profi CAD/CAM". Kolik že tyhle programy stojí a pro koho že jsou určeny?Citace:
Původně odeslal Petrik
Jistě. Za cenu toho, že náklady na vývoj hry budou vyšší, a tedy se to buďto projeví na prodejní ceně nebo bude nutné, aby z trhu někteří hráči zmizeli (pokud se trh nebude rozšiřovat). A už tady IMHO zaznělo, že hry zas tak ideálně paralelizovatelné nejsou a že především jsou většinou limitovány výkonem grafické karty a nikoli výkonem procesoru.Citace:
Původně odeslal Petrik
Kolik z toho dělá:Citace:
Původně odeslal Petrik
1) Novější architektura se spekulací a lepším paralelismem?
2) Velká rychlá L2 cache?
Jinak opět operuješ se slovem "profesionalne". To asi není úplně typické, že?
Tak to jsem zvědav, jak ke změně přesvědčíš BFU ;-). To je podobné jak s Microsoftem - udělal výborný support pro školy, a tak si vychovává základnu uživatelů. Přeškolit lidi je mnohem dražší než koupit jejich software.Citace:
Původně odeslal Fox!MURDER
To je sice pravda, ale když ušetřené peníze vrazíš do grafické karty, získáš mnohem víc. Jakmile jsi totiž limitován grafikou (a to jsi v 90 % případů), pak je rozdíl mezi různými CPU téměř zanedbatelný.Citace:
Původně odeslal Petrik
1) Kdo tohle přepisování zaplatí? Ty? Pokud ano, tak si DC taky koupím.Citace:
Původně odeslal Petrik
2) Kolik že výkonu navíc WinRAR přinese? Dělaly se tu nějaké testy a z nich vyplynulo, že v průměru tak 10-15 %. Jaké že je snížení frekvence kvůli druhému jádru? Není to takhle náhodou taky tak těch 20 % ? :-)
NetBurst: 3800 MHz SC vs. 3200 MHz DC
A64: 3000 MHz SC vs. 2800 MHz DC
Přičemž DC má v obou případech vyšší spotřebu.
Který kompilátor? Já žádný takový neznám.Citace:
Původně odeslal THX
V některých případech pomáhal na SSE i kompilátor. Pro určité typy struktur (zejména loopy) se to dá automatizovat a výsledky nejsou tak špatné. Optimalizace tohoto charakteru je podstatně jednodušší než pro DC.Citace:
Původně odeslal THX
Jeden myslel a vymyslel trakař. Pokud si tím nejsi jistý (nic jsi nenaprogramoval nebo o tom nemáš aspoň zcela jasnou představu), tak to nekomentuj.Citace:
Původně odeslal THX
Já jsem si žádného razantního rozdílu nevšimnul. Mnohem víc vidím více paměti a rychlý disk (Raptor). Jediný znatelný efekt z DC je při více zátěžových aplikacích spuštěných současně, přičemž:Citace:
Původně odeslal Poofy
1) se to dá na SC vyřešit prioritami
2) ti na to DC z dlouhodobého hlediska nepomůže, neboť multithreadová aplikace obsadí obě jádra a odezva půjde opět do kytek (schválně si zkus spustit dva zátěžové programy naráz, tak to bude vypadat, až budeš mít jeden optimalizovaný).
Věci jako MP3 standard jsou nezávislé na použitém OS, a proto je lhostejné, kde to spouštíš. Optimalizovat bez ztráty kvality to prostě nejde, i kdyby ses na hlavu stavěl.Citace:
Původně odeslal Poofy
Oni ti to samozřejmě naúčtují, toho se neboj. Dvojnásobek práce by nikdo za stejné peníze nedělal. A ano, ladění multithreaded programů do fáze spolehlivosti může znamenat klidně i takové zatížení navíc.Citace:
Původně odeslal Poofy
Další keyframe je vyšší kvalita? :-O Takže nejvyšší kvalita je nekomprimované video o velikosti pár set GB na hodinu? A to i když bude vizuálně stejné jako komprimované bez keyframes?Citace:
Původně odeslal THX
Provedl jsem testy na víc adresářích / souborech a to i s různým počtem vláken (pomocí command-line přepínače). Výsledný soubor byl při více vláknech vždy (!) větší. BTW, co ten bug ve WinRARu 3.60, který u multithreaded komprese mohl způsobit poškození dat?Citace:
Původně odeslal THX
Správné řešení je takové, kde je nejlepší kompresní poměr. A z onoho slova "nejlepší" zjevně plyne, že pravděpodobnost, že takových řešení bude víc, je poměrně malá.Citace:
Původně odeslal THX
Tahle vlastnost už je v jejich kompilátoru tak asi dva roky. Přínosy jsou prakticky nula.Citace:
Původně odeslal THX
Takže nepopíráš, že optimalizace na DC bude drahá a budeš jí muset jakožto koncový uživatel zaplatit? Dále budeš muset zaplatit dražší DC CPU (víc křemíku = vyšší cena). Takže ve výsledku to bude vše třeba 3x tak drahé, přičemž ti to přinese možná 50 % výkonu navíc (když budu optimista).Citace:
Původně odeslal THX
vsetci sa tu opierate o argumenty, ktore zavazia pri rozhodovani mozno 1% uzivatelov. Ostatnych 99% da aj tak na marketing a svoj subjektivny pocit (pripadne kamarata mi povedal, ze...). Takze tak :roll:
Bohužel to pro ně ale znamená, že budou platit zbytečně moc. Za věci, které nejspíš nevyužijí.Citace:
Původně odeslal tomase
Je to cena za luxus, komfort. Naco je komu BMW 5, ked ho do prace po meste odvezie aj Felicia a rovnako rychlo?Citace:
Původně odeslal Eagle
"To borrow from a human euphemism, it is not a perfect galaxy."Citace:
Původně odeslal tomase
-Thor, Supreme Commander of the Asgard fleet :mweheh:
prides domov z prace a pustis si pre zabavu Max/Cinemu/Mayu/Combustion ? myslim ze takto sibnutych nas je mizive mnozstvo.Citace:
Původně odeslal Petrik
budem ti vdacny ked mi najdes nieco a-la max/cinema pre linucha a PiT ti myslim ze verejne podakuje ked jemu najdes pre linucha ekvivalent PhotoshopuCitace:
Původně odeslal Petrik
pls, at sem nekdo napise ze "GIMP"Citace:
Původně odeslal -=HaDeS=-
:mweheh:
GIMPCitace:
Původně odeslal tominek
BTW. Bolo by vhodne skoncit s OT.
dobra omlouvam se za vtipek.
bylo to mysleno jako narazka na to ze existuji kvalitni bitmapove editory pro tucnakoidni system.
NEEXISTUJI
a ze by adobe zacalo sve produkty nejak portovat pod linux o tom taky nevim.
treba se chyti pixel ...Citace:
Původně odeslal tominek
ale uz vazne dost ot ...