SIMD - neboli Single Instruction, Multiple Data - znamená, že procesor může jednou instrukcí zpracovat více datových prvků najednou. Typicky to znamená, že místo sčítání dvou čísel přičtete dvě sady čísel paralelně. To může přinést výrazné zrychlení například při zpracování obrazu, audia nebo numerických výpočtů. Pokud již SIMD znáte, tato tabulka je vše, co budete potřebovat. A pokud s SIMD teprve začínáte, tabulku pochopíte do konce tohoto článku
Společnost Serif, tvůrce oblíbených programů Affinity Designer, Affinity Photo a Affinity Publisher, oznámila, že celý balík Affinity Studio je nyní zcela zdarma. Krok přichází krátce po převzetí firmou Canva a znamená zásadní obrat v nabídce profesionálního grafického softwaru.
GPUI Component je open-source Rust knihovna rozšiřující framework GPUI o více než 60 moderních, nativních a multiplatformních UI komponent. Staví na deklarativním přístupu, stateless renderování a jednoduchém API inspirovaném Reactem či Yew. Díky optimalizovanému výkonu, podpoře témat a flexibilním layoutům umožňuje rychlý vývoj desktopových aplikací, jako je například trading nástroj Longbridge Pro. Knihovna je licencována pod Apache 2.0 a dostupná na GitHubu.
Je dobře, že kvůli věcem bez velkých nároků na výkon (grafy, reklamy, …) se už nemusí startovat plugin. Ale má-li Canvas nahradit Flash ve všech aplikacích, včetně her, musí vyřešit tohle:
„Probably the biggest difference between Canvas and Flash is the level of abstraction available. Canvas is really just a low-level 2D graphics API. There are no objects or layers or groups…“.
To, co Flash řeší nativně (příp. i s HW akcelerací, což je aktuální priorita na mobilech), se musí v Canvasu řešit JS knihovnami, což logicky vede k: http://zdrojak.root.cz/zpravicky/porovnani-rychlosti-animacnich-technik/.
Zatím mi není jasné, jestli má Canvas vůbec takové ambice nebo chce náročnější aplikace navždy přenechat pluginům…
Ambice canvasu jsou „docela velké“, viz například (neúplný) port Processing do JS: http://processingjs.org. (Např. port generativního Substrate od Jareda Tarbella: http://processingjs.org/learning/custom/substrate)
Největší zádrhel z praktického hlediska je skutečně v tom, že na rozdíl od Flashe (anebo SVG, …) vytvořený grafický prvek není žádný objekt, k němuž lze přistupovat, věšet na něj handlery událostí, příp. ho z canvasu odstranit, atd.
To je hezky vidět i v diskusi na blogu Githubu, kde se mnoho lidí ptá, proč @mojombo nepoužil SVG, resp. Raphael.js. Ten umožňuje daleko smysluplnější práci s grafickými objekty, viz např. http://raphaeljs.com/github/impact.html, výkonnostně ale za Flashem a canvasem (zatím?) strašně pokulhává: http://www.themaninblue.com/writing/perspective/2010/03/22/ (linkováno v diskusi na Githubu). Pro mně osobně (=subjektivně) je práce s Raphael.js balzám. Je to snesitelně rychlé, je to „normální JS programování“ s využitím jQuery/Prototype/Underscore/etc, Firebug funguje jako debugger, …
Jo, jo. V tomto světle se i to, co se zdálo na první pohled jako úsměvná kuriozita – Flash runtime implementovaný v JS (http://ajaxian.com/archives/gordon-flash-runtime-implemented-in-javascript) přestává zdát kuriozitou, protože to je vlastně nejefektivnější způsob (v tom smyslu, že je prakticky stejně efektivní jako jakýkoliv jiný), jak přejít od Flashe ke Canvasu (s výhodou setrvání u osvědčených nástrojů a pokročilého jazyka).
To, co se Flashi po celá léta vytýkalo, buď zůstává (nepoučený tvůrce bude všechno „malovat“ místo aby strukturoval dokument) nebo se dokonce ještě zhoršuje (další mezivrstvy interpretovaného kódu, další nenažranost).
Ještě pro upřesnění – výše odkazovaný projekt Gordon nerenderuje do Canvasu, ale do SVG, výše uvedená úvaha platí pro potenciální obdobu takové knihovny, která by pracovala s Canvasem (což by bylo v jejím případě asi smysluplnější).