Sammanfattning. Nyckelord: Renderingstid, Canvas, Attribut och iterationer.

Transkript

1

2 Sammanfattning På grund av att Javascript har utökats inom webben de senaste åren är även Canvas på uppgång. Javascript möjliggör dynamiskt genererad grafik vilket gör Canvas möjligt att skapa grafik via Javascript. Canvas objekt består av ett stort antal kurvor/linjer där varje kurva/linje har ett x antal olika attribut, vid ändring av dessa attribut kan man påverka renderingstiden på webben. Problemet med dagens webbläsare är att renderingsmotorerna inte presterar lika bra som det gör för att ladda en bild på webben. Canvas blir därmed en långsam teknik och andra format så som jpg och png ligger steget före. Detta projekt implementeras med en kombination av tre programmeringsspråk, HTML, CSS och Javascript. Med hjälp av funktioner och variabler kan man ta reda på renderingstiders för olika objekt som skapas och målas ut. Vad projektet ger i slutändan är en analys av hur renderingen av olika objekt i olika webbläsare presterar. Det finns både kortsiktiga och långsiktiga utvecklingar av detta projekt. Nyckelord: Renderingstid, Canvas, Attribut och iterationer.

3 Innehållsförteckning 1 Introduktion Bakgrund javascript Mätning av svarstider i javascript Canvas Bildattribut i Canvas Tidigare arbeten Problem Hypotes Metodbeskrivning Metoddiskussion Alternativa metoder Forskningsetik Genomförande/Implementation Förstudie Beskrivning av prototyp Pilotstudie Utvärdering Presentation av undersökning Analys Slutsats Avslutande diskussion Sammanfattning Diskussion Framtida arbete... 26

4 1 Introduktion Javascript blir mer och mer populärt trots dess långsamma respons samt att Javascript har blivit en standard som finns på 95% av webben menar Mehrara (2011). Javascript har dock en del problem, bland annat dess långsamma respons som har att göra med att det aldrig riktigt har stöd av flerkärniga system. Javascript behandlas inte som ett flertrådat språk vilket begränsar möjligheter tyder Mehrara (2011). HTML5 Canvas möjliggör dynamisk skript rendering. Genom en fullständig uppsättning ritfunktioner kan man komma åt områden med Javascript vilket möjliggör dynamisk genererade grafik. Canvas har också ett stort stöd, alla sorts webbläsare samt mobilversioner kan hantera rendering av canvas objekt. Varje Canvas objekt består av ett antal linjer som i sin tur har unika egenskaper. Dessa egenskaper även kallade attribut kan vara färger, former och storlek. Attributen avgör hur slutresultatet skall bli tillsammans med en algoritm. Wei och Xu (2011) säger i sin artikel att Amazon har tagit fram resultat av förlorad försäljning på 1% på grund av 100 ms fördröjning. Med detta resultat kan man dra slutsatsen av att användarna strävar bland annat efter snabba svarstider, om detta ej uppfylls kan användarna enkelt ta sig vidare till nästa sida. Genom att hålla snabba svarstider kan en verksamhet enklare hitta problem samt en lösning för detta problem vilket kan leda till att verksamheten sparar både pengar och tid. Rajamony och Elnozahy (2001) menar att man kan med hjälp av Javascript mäta svarstiden utan att använda sig av ändringar inom webbläsaren. Problemet är att dagens canvas objekt målas ut alldeles för långsamt. Johnson och Jankun- Kelly (2008) menar att canvas har problem med sin rendering, att andra format som SVG ligger steget före canvas. Ahmadi, Jazayeri och Repenning (2012) tyder på att dagens webbläsare varierar i prestanda. Frågeställningen som skall besvaras är hur stor skillnad det är mellan olika canvas objekt som utgår från samma bild men använder sig av olika antal linjer och egenskaper på parametrar. Alla linjer har olika attribut som måste anges innan de kan målas ut vilket innebär att hårdvaran och mjukvaran behöver använda en mängd resurser för att få fram ett resultat. Totalt kan en bild ta lång tid att rendera vilket kan leda till längre responstid. En experimentmetod kommer att användas för att utföra tester på målningar med olika antal linjer och parametrar för att kunna mäta tiden och sedan se skillnaden på resultatet. Experimentet fungerar som så att man målar ut en bild med parametrar och linjer med olika egenskapar, målet är att använda sig av en bild med egenskaper som skapar en bild med låg kvalitet, en med hög kvalitet, samt en som ligger mitt emellan. 1

5 2 Bakgrund Detta kapitel kommer först att handla om grunder inom de program och språk som kommer att användas för att utföra detta experiment för att senare gå in mer djupgående. 2.1 javascript Javascript är ett programmeringsspråk som används mycket inom webbtillämpning och är tillgängligt för alla webbläsare. Javascript är något som inte syns på utsidan på en hemsida, det ligger i grunden av uppbyggnaden. En stor del av vad det kan användas till är att skapa effekter, exempelvis animationer. Javascript är något som kommer vara till användning i detta arbete för att hålla ordning på renderingstider samt kopplingar kring funktioner och dess variabler. Javascript är det bästa sättet att komma fram till hur lång tid det tar för ett objekt att målas ut eftersom man kan koppla ihop knappar och variabler i funktioner för att få ut ett gemensamt resultat. Javascript kommer mer och mer till användning trots dess långsamma respons. Mehrara (2011) säger att Javascript har blivit en standard på 95% av webben. Mehrara (2011) menar också att Javascript är långsamt på grund av att det aldrig riktigt har behandlats som ett flertrådat språk, vilket begränsar möjligheten att utnyttja ett flerkärnigt system. Responsiva program uppbyggda med hjälp av Javascript är dynamiskt skrivet och traditionellt exekverande med hjälp av bytekod tolkning. Tolkningen gör Javascript mycket långsammare i jämförelse med ursprunglig kod genererad för statiskt språk såsom C eller C++. Mehrar (2011) säger också i sin artikel att det primära problemet är att document of object (DOM), används av Javascript för att interagera med webbsidor och webbläsare, att DOM inte har en modell för delat tillträde. Detta betyder att två trådar kan involvera flera händelsehanterare som ändrar samma DOM-objekt och skapar antingen raceförhållanden eller korrekthetbuggar Mätning av svarstider i javascript Ur en användares perspektiv är svarstiden den tid som förflutit från det att en begäran inleds vid en klient till den tidpunkt då svar är visat av klienten. Snabba svarstider inom webben är något användaren strävar efter. Rajamony och Elnozahy (2001) menar att man kan med hjälp av Javascript mäta svarstiden utan att använda sig av ändringar inom webbläsaren, att man använder sig av skript som körs på användarens dator och kontrollerar tiderna därifrån. Därmed kan skriptet få dem rätta tiderna från användarens nuvarande situation. Therefore, obtaining quantitative measures of the response times in a timely and costeffective manner is fundamental to manage e-commerce services across a diverse and rapidly changing client population - Jianbin (2011) Genom att hålla goda svarstider kan ett företag enkelt identifiera sina problem, lösa dem och komma tillbaka till normalt igen och därmed minska sina kostnader. När det kommer till hemsidor så har användaren många val att välja mellan, speciellt inom e-handel är har detta stor betydelse. Det är mycket enklare att gå vidare till nästa hemsida än att gå till en annan butik ute på stan. Det är där med av stor betydelse att uppfylla kvalitetskraven en användare ställer, svarstiden kan vara en av dem. Man vill både behålla 2

6 sina användare samt få tag på nya. Svarstiden på en hemsida inkluderar hela innehållet, även bilder. Rajamony och Elnozahy (2001) menar att det är två faktorer är viktiga när det gäller svarstiden, internetfördröjning och fördröjning av serversidan. Rajamony och Elnozahy (2001) menar också att det finns några etablerade tekniker för att minska svarstiden över webben, användningen av kraftfulla servrar, omvända proxyservrar, webb cachar och smart lastbalansering bland geografiskt utspridda servrar. 2.2 Canvas Canvas är en del av HTML5 och möjliggör dynamisk skript rendering. Canvas består av en utdragbar region som definieras i HTML5 med höjd- och breddegenskaper. Genom en fullständig uppsättning ritfunktioner kan man komma åt områden med Javascript vilket möjliggör dynamiskt genererad grafik. Canvas kan bland annat användas inom spel, animationer och bildkomposition. Mowery och Shacham (2012) tar upp canvas breda stöd, att det finns tillgängligt i Chrome, Firefox, Internet Explorer, Opera och Safari samt mobil Safari och Android browser. Shiraishi och Yamaguchi (2000) beskriver att processen av att måla ut ett objekt består av två steg, förberedelse och sammanställning. Förberedelsen innebär att fördela linjer och dess attribut och till sist vilken ordning de kommer att målas ut i. Under sammanställning utförs målningen av linjerna en efter en. Varje linje är fixed och behöver gå igenom fyra olika steg (Stroke attributes) för att bli fullständig. Figure 1 visar ett exempel på hur det kan se ut när man går igenom de olika stegen. Steg ett är färgprovtagning, en färg utsätts till linjen. Steg två är bildbeskärning, man fokuserar på en mindre del av bilden. Steg tre är färgskillnad, den beskärda bilden görs svartvit för att de olika linjerna sedan ska få den korrekta färgen. De sista steget är rektangel beskärning, en liten del av bildbeskärningen tas ut för att sedan beskäras ner till mindre rektanglar som i sin tur tilldelas färger för att skapa ett slutresultat. Figure 1: Olika steg för stroke attribut (Orginalfoto Adam Meek 2014) 3

7 När man väl använder sig av canvas för att måla av en befintlig bild vill man få den att likna de ursprungliga objektet så bra som möjligt. De målet kan oftast vara ett problem, canvas objekt kan bestå allt ifrån 2000 strokes till strokes. Om man då använder sig av strokes istället för 2000 srokes så måste man gå igenom de fyra fasta stegen 8000 gånger extra, vilket tar tid och resurser men man får ett bättre resultat Bildattribut i Canvas I Canvas använder man sig av ett stort antal linjer, det kan variera från hundratals till tusentals. Varje linje har unika attribut för att kunna forma och färglägga en bild. Figure 1 visar hur uttagningen av attributen går till. Bildattributen kan variera beroende på vilken algoritm man använder för att ta ut linjernas attribut. En algoritm bestämmer hur man vill utforma områdena inom bilden, hur man vill att det skall gå till vid mörka områden samt vid ljusa. Attribut så som färg, position och storlek är viktiga att ta reda på för varje penseldrag. Buck, Humphreys och Hanrahan (2000) säger att grafikaccelatorer är optimerade för att flytta data en riktning, från host till skärmen. Därför är varje åtgärd som krävs mycket dyr. Grafikkortet håller reda på de flesta, om inte alla tillstånd och dess attribut. Attribut så som aktuella färger, transformationsmatrisen, och så vidare. Genom att kontrollera värdena kan man förhindra onödiga tillståndkommandon från att genereras när det finns flera kontexter med samma värden. Det kan vara så att det blir en stor skillnad enbart av att ändra så att man målar ut alla linjer som använder färgen röd först och sedan går vidare till nästa färg istället för att gå fram och tillbaka mellan röd. Buck, Humphreys och Hanrahan (2000) tror att genom att spåra tillståndet tillsammans med en hierarkisk representation av tillståndsförändringar är en effektiv teknik för att förbättra hastigheten och robusthet av renderingssystem. 2.3 Tidigare arbeten Pinto, Amador och Gomes (2010) har presenterat en rapport om 3D-grafik bibliotek helt skrivet i Javascript som möjliggör utveckling av 3D-innehåll direkt i webbläsarn. Dem använder sig av Canvas tillsammans med 3D-algoritmer kodade i Javascript. Vanligtvis så används Canvas för att utforma 2D-grafik men dessa personer tar nytta av dessa 2Dritfunktioner för att skapa, manipulera och rita 3D-objekt direkt i webbläsaren. Vad man kan få fram av detta arbetet är att det behöver inte vara frågan om rendering av 3Dgrafik utan att förändra attribut för linjerna, hur dem är lagda och formade samt färger för att optimera utritningshastigheten. Shiraishi och Yamaguchi (2000) presenterade ett arbete om en metod för automatisk rendering av en målning. De använde sig en ursprunglig bild, exempelvis ett foto för att sedan måla av detta objekt med hjälp av en algoritm. De använder sig av olika attribut på bilderna, exempelvis att de minskar antalet linjer från en bild till en annan för att se skillnaden i bildkvaliten. Metoden de använder sig av kontrollerar tätheten av linjerna samt ordningen de målas i baserade på storleken. De börjar med de större linjer först och avslutar med de mindre. 4

8 Detta arbete tyder på att det blir en skillnad på hur bildkvaliten varierar beroende på linjeattributen. Man kan tycka att detta arbete liknar tanken med detta. Där det finns likheter är hur bildkvaliten kan variera, men att detta arbetet är mer fokuserat på responstiden mellan de olika bilderna och hur stor skillnaden egentligen är. 5

9 3 Problem Problemet är att dagens Canvas objekt målas ut alldeles för långsamt. Johnson och Jankun- Kelly (2008) menar att canvas har problem med sin rendering, att andra format som SVG ligger steget före canvas. Ahmadi, Jazayeri och Repenning (2012) tyder i sin artikel på att dagens webbläsare varierar i prestanda och att vi kan i farmtiden vänta oss snabbare renderingsmotorer. Alla linjer har olika attribut som måste anges innan de kan målas ut vilket innebär att hårdvaran och mjukvaran behöver använda en mängd resurser för att få fram ett resultat. Totalt kan en bild ta lång tid att rendera vilket kan leda till längre responstid. Ett objekt består av ett stort antal linjer där varje linje har egna egenskaper vilket gör att en målning med fler linjer tar längre tid att måla ut eftersom att fler egenskaper måste anges. Frågeställningen som skall besvaras är hur stor skillnad det är mellan olika canvas objekt som utgår från samma bild men använder sig av olika antal linjer och egenskaper på parametrar. Vilka parametrar kan man påverka utan för dåligt resultat och hur stor skillnad är det på responstiden, från början till slut om man ändrar objektens egenskaper? Exempelvis om man ritar ut ett objekt med andra linjeparametrar, hur påverkas svarstiden? 3.1 Hypotes Hypotesen är att linjeattribut eller minskat antal parametrar påverkar renderingstiden positivt men att man kommer se en skillnad i bildkvaliten. Färre antal linjer i ett objekt behöver inte gå snabbare, färre antal linjer innebär tjockare linjer vilket är mer krävande vid utritning och vid ett större antal linjer används mer men mindre linjer. Detta kan påverka renderingstiden på olika sätt, antingen så tar det längre eller kortare tid att måla ut ett objekt med mindre antal linjer. Uppkopplingen kan också vara en faktor som påverkar renderingstiden, det kan vara en skillnad på hur en webbläsare samt en dator reagerar på en uppkoppling med 80 Mbit och en med 10 Mbit. Att avgöra om det är värt att försämra bildkvaliten för att påverka renderingstiden positivt är upp till användaren eller skaparen, det kan bero på vad för sort ämne det handlar om. Man kan tycka att det kanske inte är värt att lägga tid och resurser på att måla ut en bild under en längre tid när man egentligen vill visa upp en sida där bilden inte är i fokus utan att texten ligger i fokus. 3.2 Metodbeskrivning Den metod som passar bäst för att kunna testa hypotesen är experimentmetoden. Den gör så att man kan testa målningar med olika antal linjer och parametrar för att kunna mäta tiden och sedan se skillnaden på resultatet. Man sedan kan använda sig av de olika tiderna man har fått från testerna för att skapa grafer som gör det enkelt att urskilja resultatet. Om man går igenom liknade arbeten så kan man se att de använder sig av samma sorts metod. Bland annat så kan man se att Shiraishi och Yamaguchi (2000) använder en experimentmetod för att kunna se resultat mellan olika Canvas objekt som använder sig av 6

10 olika antal linjer. Heok och Daman (2004) använder sig också av en experimentmetod för att kunna urskilja detaljnivån av 3D-objekt. Chi och Liu (2014) utför också ett experiment när de testar algoritmer för att rendera icke-fotorealistiska bilder av typen Pointillism, vilket är en typ av bild som består av prickar av färg i ett mönster. Experimentet kommer fungera som så att man målar ut en bild med parametrar och linjer med olika egenskapar, målet är att använda sig av en bild med egenskaper som skapar en bild med högre kvalitet än de andra och sedan använda sig av en med betydligt sämre kvalitet och till sist använda en bild som ligger mitt emellan. Det man mäter då är tiden från man startar målningen tills den är 100% klar. Det kan också vara intressant att veta hur det kan påverka ett Canvas objekt igenom att använda en färgordning, de vill säga att man målar ut röd, röd och sen blå istället för röd, blå och röd igen vilket gör att man får ändra färgegenskapen ytterligare en gång. Om detta sker ofta kan det bygga på en tid som i slutändan kan ses som en skillnad. Rajamony och Elnozahy (2001) menar att man kan med hjälp av Javascript mäta svarstiden utan att använda sig av ändringar inom webbläsaren. Rajamony och Elnozahy (2001) säger att man kan mäta svarstiden genom att starta en klocka när användaren exempelvis klickar på en länk och sedan stoppa tiden via en onload funktion på sidan. Dock fungerar de inte lika bra att starta klockan om en användare går in på sidan via en URL-adress. Rajamony och Elnozahy (2001) menar också att man inte ska gå efter klockan när man mäter svarstiden, att man istället använder sig av ett client-script. Detta skriptet körs på användarens dator och kan antingen utföras när en speciell händelse inträffar eller när dokumentet laddas. Skriptet tar reda på tiden genom att ta reda på nuvarande tid och starttid som skriptet kommer ihåg från tidigare steg och sedan räkna ut hur lång tid det tog Metoddiskussion Att använda olika enheter för att utföra tester är en möjlighet för att få annorlunda data. Exempelvis att utföra testerna på en bärbar och en stationär dator är ett sätt. Det negativa med detta är att det blir svårt att jämföra resultatet eftersom en stationär dator oftast mer kraftfull än vad en bärbardator är. Utifrån arbetets förutsättningar kommer inte denna idé att fungera. Detta beroende på att datorerna som är tillgängliga är baserade på olika operativsystem och om man skulle behöva använda sig av en virtual machine för att köra ett annat operativsystem på ett redan befintligt, så använder datorn mycket mer resurser för att köra två operativsystem och det blir då obalans i mätningen som i sin tur ger dåligt resultat. Det blir också svårt att jämföra de olika webbläsarna eftersom de bland annat är på olika operativsystem och att de stödjer olika webbläsare. På exempelvis OS X fungerar Safari på men inte på Windows som i sin tur stödjer Internet Explorer. Detta är ett problem om man vill utföra tester på så många webbläsare som möjligt, då det blir svårt att testa både Internet Explorer och Safari på samma dator. Lösningen för detta är att använda sig av en virtual machine men då återkommer man till samma probleme att datorn får köra flera operativsystem och mer resurser på datorn används och det kan försämra tiderna i mätningen. Genom att använda tillägg för webbläsaren (Exempelvis Greasemonkey) blir det ett problem att utföra dessa tester på en mobilenhet. Det går inte att implementera ett skript som ska köras på webbläsaren när man besöker en viss sida, man kan mäta med Javascript-variabler men inte med tillägg som inte fungerar i alla webbläsare. Detta gör så att man inte kan testa 7

11 skillnaden på en mobil och dator. Alla är medvetna om att en mobil idag fungerar som en dator och att man nästan kan göra allt på den som man kan göra på en dator. Mikkonen och Taivalssari (2009) säger i sin artikel att det finns ett antal allvarliga problem med en webbapplikation på en mobilenhet, bland annat har webbläsaren en dåliga prestanda och inte är designad för en applikationsplattform Alternativa metoder En annan metod som skulle kunna användas inom detta ämne är fallstudie. Det som skiljer fallstudien från experiment är att man går djupare inom ämnet för att undersöka fenomen medan experimentmetoden kan fokusera mer på att göra mätningar av variabler. Genom att använda fallstudie kan man forska sig vidare för att få fram ett vetenskapligt resultat som stödjer en hypotes medans man med experiment får testa sig fram för att få ett resultat som kan följa en hypotes. I detta fall verkar fallstudie inte relevant, och man får inte direkt fram något av det Forskningsetik Inga testpersoner kommer att användas för detta experiment på grund av att det inte är relevant för att testa hypotesen. För utgöra mätningar av responstider behövs ingen direkt person, vad som behövs är data och ingen känslig sådan. Det kan hända att personer agerar på objekten som målas ut, exempelvis djur eller bild på en person. För att detta inte ska inträffa kan man använda sig av ett objekt så som en boll, ett bord eller en bil. Någonting som inte kan kopplas till en unik person. Eftersom detta kommer att publiceras och innehålla den kod och information som används kommer det att finnas en garanti av återupprepbarhet samt en öppenhet med resultatet. Resultatet kommer att vara oberoende av åsikter från forskare och endast bestå av sammansatt data från testerna. Experimenten kommer utföras i ett flertal webbläsare för att garantera möjligheten att återupprepa. Det kan hända att en del personer föredrar en speciell webbläsare och inte känner sig bekväma med de andra som finns tillgängliga. Det är också för att utöka resultaten och inte endast för att öka garantin av återupprepning. Thummalapenta, Devaki, Sinha och Chandra (2013) tar upp att det kan vara bra att testa flera webbläsare på grund av att renderingen kan variera samt att DOM-strukturen också kan variera mellan olika webbläsare, webbläsarversioner och därmed ha en inverkan på skripten som körs. 8

12 4 Genomförande/Implementation Detta kapitel kommer att beskriva en förslagen lösning av mätning av Canvas objekt och vägen till ett resultat. Kapitlet kommer att avslutas med en pilotstudie för att visa att de mätningar som samlats in kan användas för att analysera resultatet. 4.1 Förstudie Inspirationen av detta projekt uppstod på grund av en kombination av ett intresse av webben och HTML5 Canvas, att få chansen att arbeta djupare inom ämnet Canvas som kan vara på ingång och kan bli en bättre teknik på webben. Java direkt med Swing är en kurslitteratur skriven av Jan Skansholm och är en bok som handlar om programspråket Java. Boken tar bland annat upp olika attribut inom Canvas som ger lösningen till problemet och hypotesen inom detta projekt. Utöver Java direkt har inspiration av implementationer kommit från forum via webben, Beskrivning av prototyp De olika tekniker som används i projektet är en koppling mellan och Javascript. Alla tekniker behöver varandra för att fungera på ett effektivt sätt, mer djupgående beskrivs nedantill HTML Vad som görs i HTML är att man deklarerar en div-box till en Canvas vilket görs med ett id, canvas id= mycanvas. Detta id används sedan i Javascriptet för att skapa ett Canvas objekt till just de unika id. Med HTML gör man också kopplingen mellan olika webbsidor samt koppling till CSS-mallen och Javascripet. Man kan använda sig av koden för Javascriptet direkt i HTML-filen men det är ingen snygg lösning, blir enklare att läsa och arbeta med koden om man använder sig av en separat fil som sedan HTML-filen läser av. En skapad teknik med HTML som finns i detta projekt är en dropdown meny som görs med en option, vilket är bra för att man skall kunna göra val av vilket sorts objekt man vill måla ut. Detta alternativ kan vara bra om man använder sig av flera antal olika objekt eller om man inte väljer att hårdkoda in objekten. Se appendix B för hela koden. Figure 3: Dropdownmeny Javascript Javascriptet är själva nyckeln i detta projekt, här görs koden för Canvasen samt kontrollen för svarstiderna vilket är syftet med projektet. Scriptet fungerar så att först görs en kontroll av vilket val som har gjorts i HTML-filen, alltså vilken option som har valts. Beroende på valet så går man vidare till en funktion som skapar ett nytt Canvas objekt. Nästa steg är att gå vidare till den tilldelade funktionen som har koordinaterna för de olika linjerna/kurvorna för ett objekt. Alla koordinater skickas via en path där man pushar ett segment till en funktion som sedan ritar ut och färglägger objekten, färgläggningen sker samtidigt vilket innebär att alla objekten målas ut samtidigt. Alla koordinater sparas i minnet och målas ut när alla koordinater för alla objekt har tilldelats. Varje segment består av en kind med 9

13 antigen x1,y1 eller x2,y3 eller x3,y3 därmed behöver en kurva en kombination av x1,y1,x2,y2 och x3,y3 för att skapa bågen av linjen. Se appendix C för hela koden. Efter koordinaterna har skickats in via en path så vill man gå direkt vidare till att måla ut objektet med en draw(). Men på grund av att använda sig av requestanimationframe så behöver man anropa draw vilket gör att man får skapa en helt ny funktion som gör anropet på draw(). Samtidigt i den skapade funktionen används en translate vilket avgör hur många objekt som skall målas ut, se mer utförlig förklaring nedan. De olika objekten är implementerade via tilldelade koordinater. Objekten är vektorbaserade bilder skapade i Adobe Illustrator (svg-filer), för att få reda på koordinaterna för de skapade bilder så kan man överföra svg-filen till Canvas objekt görs via en konverter, SVG-Converter (2014). Detta är ett php-script som överför bildens linjer, kurvor, färger och så vidare till koordinater samt hexadecimala värden av färger. Valet av hur många objekt som skall målas ut görs via en for-loop där man sätter ett värde beroende på antal objekt, vad som görs i loopen är att man använder en translate på det valda objektet. Vad som menas med en translate är att man översätter objektet och målar ut de igen fast jämsides med det tidigare objektet. Figure 4: Translate Svarstider Lösningen av svarstiderna går att lösa på två olika sätt eller genom att använda teknikerna tillsammans. En av lösningarna är att använda performance.now(), det fungerar så att man skapar ett stoppur vilket är en grundteknik inom Java som tar den nuvarande tiden vilket medför att man kan deklarera en starttid och sedan deklarerar man en sluttid. När man har samlat in starttiden och sluttiden kan man räkna ut den beräknade svarstiden, sluttid starttid = sumtid. Vad som skiljer preformance.now() mot Date() är att man får decimaltal. Detta är bra för att mätningar som dessa inte skiljer mycket i ms vilket gör det ännu viktigare att få reda på decimala värden. En annan lösning är att använda sig av requestanimationframe vilket fungerar så att man talar om för webbläsaren att man vill utföra en animation och begär att webbläsaren kallar på en viss funktion för att uppdatera animeringen innan nästa utmålning. Med denna lösning kan man helt enkelt kontrollera frames per second på ett objekt. Se appendix D för fokus på lösningen med tiderna Iteration av objekt Det finns ett flertal olika sätt att utföra iterationer på en webbsida, om man inte har tillgång till koden kan man använda sig av tillägg i sin webbläsare där man skapar ett script som körs på just en sida och man kan kolla upp olika variabler som används för att göra dessa iterationer. Den enklaste lösningen samt den bästa lösningen är självfallet att hårdkoda in iterationen i sin egen kod, vilket görs i detta projekt. Det fungerar så enkelt att man skapar en for-loop runt anropen på utritningen, detta gör att loopen kommer att gå runt om och om igen ett x antal gånger. Se appendix E för fokus på iterationen. 10

14 4.2.5 Analys av svarstider För att kunna utföra en analys av svarstiderna via exempelvis en graf behöver man få tillgång till tiderna och inte bara via webbläsarn. Koden i appendix F visar en lösning för att kunna spara ned tiderna i en string som läggs i en array enligt följande, Iteration 1 tog 30Ms. Denna arrays skall sedan gå att ladda hem till sin dator via sin webbläsare i excel-format, vilket är ett utmärkt program för att göra grafiska analyser av mätningarna. Denna array töms sedan inför varje gång man väljer att måla nya objekt Progression Eftersom att koordinaterna för varje objekt sparas i minnet och målas ut samtidigt och inte var för sig så blir det ett problem med att ta reda på hur lång tid det tar för ett objekt att målas ut från början till slut. En annan implementation som inte fungerade var att använda sig av funktioner för varje Canvas objekt, att man tilldelade en div-box ett speciellt Canvas objekt. Det fungerade att måla ut objekten genom att tillkalla funktionen men problemet var att man inte kunde ändra attribut för objekten mellan olika boxar, exempelvis färg eller border. Den lösning man kunde göra via denna implementationen var att skapa en ny funktion för ett likadant objekt när man ville byta färg. Det är absolut ingen snygg eller bra lösning, den fungerade men det blir för många funktioner som gör samma saker. En lösning som fick kastas var att använda sig av arrays, en för varje attribut man vill ändra. Man kan sedan skicka med ett värde från en array beroende på vilket id Canvasen har i forloopen. colors=["","red","blue","green","lightblue","yellow","#f5f5f5]; Denna array fungerar så att Canvasen som får ett i-värde, om i=1 skickar man med color[i] vilket innebär att color=röd. Så istället för att skapa ett flertal funktioner för liknande objekt fast med olika egenskaper så kan man skapa arrays som innehåller olika värden som sedan skickas med beroende på vilket id Canvasen har tilldelats, exempelvis i Figure 4 kan man se att objektet har färg röd vilket menar att det är första objektet som skapats. Man behöver då endast en funktion för varje objekt men en ytterligare funktion som skapar de olika Canvasobjekten samt tilldelar egenskaper Lösningar För att lösa problemet med den första tekniken ovan behöver man använda sig av en translate på det valda objektet. Med hjälp av translate kan man enkelt välja hur många objekt som skall målas ut och enkelt att mäta svarstider på. Eftersom att man inte är intresserad av att ta reda på hur lång tid det tar från att skicka in koordinaterna samt att måla ut koordinaterna är translate den bästa lösningen. Man kan använda sig av samma funktion av objekt och upprepa de ett antal gånger beroende på hur många objekt man vill måla ut. Lösningen för det andra problemet som beskrev ovan blev det enklast att hårdkoda om objektet med dess nya attribut. 11

15 4.3 Pilotstudie Syftet med mätningen är enkel, det handlar enbart att ta reda på information om hur renderingstiden är mellan olika objekt med olika attribut eller utritnings ordning. Det kan vara en lösning som färgordning för att minska antalet anrop på draw() eller skillnaden mellan att måla ut ett, tre och sex objekt. Figure 5 visar ett resultat av en mätning av sex objekt 50 gånger, man kan se att första målningen tar betydligt mycket längre tid än resterande. Vad man kan sammanställa av denna mätning är att objekten är små och kräver inte mycket cpu-kraft. Appendix H visar en linjegraf av en liknande mätning av sec objekt. Vad som skiljer de åt är att Figure 5 körs på safari och appendix H via Google Chrome. Figure 6 påvisar ett näst intill unikt exempel av en mätning, vad som skiljer de åt från Figure 5 är att man mäter renderingstiden på ett enskilt objekt. En utmåling av ett objekt 50 gånger istället för sex objekt 50 gånger. Vad man kan sammanfatta från det är att ett objekt går fortare än vad sex objekt gör vilket är uppenbart eftersom att de är samma objekt fast mindre antal. Dock så kan man inte riktigt dra någon slutsats från dessa mätningen på grund av att störta andelen av iterationerna tar 0 ms vilket inte går att göra en mätning på. Figure 5: Mätning 6 objekt. Appendix H del 2 så får kan man se en linjegraf av en mätning av renderingstiden av ett objekt 50 gånger i Google Chrome, en motsvarande mätning av tidigare test. Vid just dessa mätningar kan man ej fatta några direkta slutsatser på grund av att objekten som testas är små och består av ytterst få lager, linjer och endast två färger. Vad man kan få ut av denna pilotstudie är att prototypen går att använda för att utföra mätningar av olika objekt. Vad som behövs ändra innan testerna är de hårdkodade Canvasattributen samt antal iterationer som skall utföras. Figure 6: Mätning 1 objekt. 12

16 5 Utvärdering Detta kapitel börjar med att beskriva den genomförda studie, som följs av en analys av den insamlade data från experimentet. Kapitlet avslutas med en sammanfattning av de slutsatser som gjorts i analysen. 5.1 Presentation av undersökning Undersökningen är uppdelad i tre delar, varje del består av ett eget objekt. De olika objekten som undersöks är ett stort objekt med ca 400 kurvor/linjer och 23 lager, ett litet objekt med ca 100 kurvor/linjer och består endast av ett lager samt ett objekt som ligger på ca 150 kurvor/linjer och 19 lager vilket gör de ett objekt som ligger emellan de stora och de lilla. Vad som gör de lilla och medelstora objektet så olika även fast de bara skiljer ca 50 kurvor/linjer är att de skiljer 18 lager. Varje gång ett objekt byter färg eller börjar på en helt ny punk så behöver man skapa ett nytt lager, ett nytt lager innebär en ny path som skickas in. Genom att testa de lilla och det medelstora objektet så kan man urskilja hur mycket tid de kostar att skapa en ny path. Skillnaden mellan de stora och det medelstora objektet är antal kurvor/linjer, antal paths är nästan den samma. Med de två objekten kan men urskilja hur mycket de påverkar om man har många kurvor/linjer vid rendering. Den uppdelning som beskrivs ovan går att kombinera på olika sätt. Vad som görs är att man måla ut dessa objekt 1000 gånger vid varje test, varje test av ett objekt utförs 15 gånger. Detta 15 tester delas upp i tre delar, fem tester för varje del. En del för att måla ut en bild av objektet med 1000 iterationer, en del för att måla ut fem bilder av objektet med 1000 iterationer och den sista delen för att måla ut tio bilder av objektet med 1000 iterationer. Alla dessa tester görs i tre olika webbläsare, Google Chrome, Mozilla Firefox samt Safari. Med dessa tester kan man urskilja de olika webbläsarnas renderingsmotorer och se vilken som presterar bäst. Inför varje analys tas den absoluta första iterationen bort i summeringen av iterationerna. Detta görs på grund av att just den första iterationen målar inte bara ut objekten utan skickar också in alla koordinater, färger och så vidare vilket gör de till en ojämn mätning om man väljer att ta med den informationen. Det man vill mäta på är utritningen och inget annat onödigt som kan göra informationen annorlunda Utrustning MacBook Air, OS X version ,3 GHz Intel Core i5, 8GB RAM. Grafikkort Intel HD Graphics MB. Hårddisk på 126GB SSD. Testerna utförs på ett 100/100 trådlöst nätverk med en ASUS router, RT-N12 Wireless-N. Testerna utförs på Högskolan i Skövdes webbserver för studenter - wwwlab.iit.his.se 13

17 5.2 Analys Analysen av varje mätning utförs i Excel, genom att samla ihop tiderna från varje test och ta reda på medelvärdet för varje iteration för att sedan kunna skapa grafer utifrån den informationen Objekt Krokodil Objekt Krokodil anses som det lilla objektet som består av ca 100 kurvor/linjer och endast ett lager. Experimentet har utförts i tre olika webbläsare med 1000 iterationer Figure 7.1: Objekt Krokodil summan av 1,10,100 och 1000 iterationer. Figure 7.2: Bättre syn av figure 7.1 iteration 1 och

18 Figure 7.1 visar resultatet av objekt Krokodil, resultatet är ifrån testerna som utfördes av utmålningen av 10 krokodiler per iteration. Grafen består av ms i y-axeln och summan av antal iterationer i x-axeln. De olika färgerna står för vilken webbläsare tiderna kommer ifrån. Man kan tydligt se att Mozilla Firefox sticker ut över de två andra webbläsarna, medan att Google Chrome och Safari har näst intill samma värde. Vad som skiljer dem åt är att Safari har en bättre standardavvikelse vilket betyder att nästa gång man utför testerna så är det ca 98% chans att resultatet hamnar innanför standardavvikelsen enligt rule, Wikipedia. Den standardavvikelse som används är multiplicerat med tre (Stddev*3). För att få en bättre bild av iteration 1 och 10 se figure 7.2. Figure 8.1: Objekt Krokodil summan av 1,10,100 och 1000 iterationer. Figure 8.2: Bättre syn av figure 8.1 iteration 1 och

19 Figure 8.1 visar en liknande graf som i figure 7.1. Vad som skiljer dessa två från varandra är att resultatet i figure 8.1 visar summan av 1,10,100 och 1000 iterationer av 5 objekt per iteration. Medelvärdet a varje iteration används för att skapa en summa av antal iterationer. Vad som kan sammanfattas från grafen i figure 8.1 är samma som tidigare sammanfattning av figure 7.1. Alltså att Mozilla Firefox tar längre tid på sig att rendera alla objekten 1000 gånger medans Google Chrome och Safari är jämsides vid 100 och 1000 iteratoner. Om man ser närmare på figure 8.2 så får man en bättre bild av iteration 1 och 10 och få resultatet på att Google Chrome startar långsamt men går fortare och fortare medan Mozilla Firefox tappar sin renderingstid men att Safari fortfarande presterar bättre. Standardavvikelsen visar att Safari håller den mest stabila mätningen. Standardavvikelsen som används är multiplicerat med tre (Stddev*3). Analysen av liknande test fast med summan av 1,10,100 och 1000 iterationer av 1 objekt per iteration ger en graf som ser ut som grafen för summan av 1,10,100 och 1000 iterationer av 5 objekt per iteration i figure 8.1. Alla analyser fungerar på samma sätt fast använder sig av olika tider eftersom att tiderna tas ifrån de olika testerna som görs. Alla analyser använder sig av en standardavvikelse multiplicerat med 3 (Stddev*3) och utförs i olika webbläsare Objekt Tält Objekt Tält ses som det medelstora objektet som består av ca 150 kurvor/linjer samt 19 lager. Experimentet utförs i tre olika webbläsare och testerna görs med 1000iterationer. Figure 9.1: Objekt Tält summan av 1,10,100 och 1000 iterationer. 16

20 Figure 9.2: Bättre syn av figure 9.1 iteration 1 och 10. Figure 9.1 visar en graf med resultatet av summan av 1,10,100 och 1000 iterationer av 10 objekt per iteration. Grafen fungerar som alla tidigare, ms i y-axeln och summan av antal iterationer i y-axeln. Grafen består också av standardavvikelsen multiplicerat med tre (Stddev*3). Här kan man tydligt se att Mozilla Firefox presterar mycket sämre än Google Chrome och Safari, detta gäller vid summan av alla iterationer. Om man kollar på figure 9.1 och 9.2 så ser man tydligt att Google Chrome presterar bäst men består av en stor standardavvikelse vilket menar att Safari inte behöver prestera sämre på grund av just denna analys. Eftersom att standardavvikelsen multiplicerat med tre ger en 98% säkerhet enligt rule, Wikipedia av att nästa mätning kommer hämna innan för standardavvikelsen. Om man jämför resultatet i figure 9.1 mot figure 7.1 vilket båda gör en mätning av 1,10,100 och 1000 iterationer av 10 objekt per iteration fast med två olika objekt men endast ca 50 kurvor/linjer. Det som skiljer dem åt är att objekt tält består av 19 lager medan objekt krokodil endast har ett lager. Vad man kan se om man tittar noggrant på dessa två figurer är att summan av iterationerna är betydligt mycket mer i ms och att webbläsarna är hyfsat när varandra i figure 7.1. Däremot i figure 9.1 så är skillnaden på webbläsarna betydligt mycket större vilket ger ett resultat av att renderingsmotorn påverkas beroende på hur många lager objektet består av, men också att antal kurvor/linjer inte behöver påverka renderingstiden vilket är hypotesen i detta experiment. 17

21 Figure 10.1: Objekt Tält summan av 1,10,100 och 1000 iterationer. Figure 10.2: Bättre syn av figure 10.1 iteration 1 och 10. Figure 10.1 visar resultatet av mätningen av objekt tält med summan av 1,10,100 och 1000 iterationer av 10 objekt per iteration. Grafen fungerar som alla tidigare, likadana x- och y- axlar samt standardavvikelsen multiplicerat med tre. Efter en analys av denna mätning kan man resultera i att Safari fungerar bättre när mindre antal objekt målas ut vid varje iteration. En annan slutsats man kan fatta är att Mozilla Firefox fortfarande är den webbläsare som har den högsta renderingstiden men också att Google Chome och Safari fortfarande är 18

22 jämsides och att standardavvikelsen för Safari fortfarande är betydligt mycket mindre än de andras. Figure 11: Objekt Tält summan av 1,10,100 och 1000 iterationer. Analysen av mätningen i figure 11 med summan av 1,10,100 och 1000 iterationer av 1 objekt per iteration ger en helt annan information än tidigare analys av objekt tält. Vad man kan sammanställa från denna analys är att de olika webbläsarna ger ungefär samma summa av renderingstider Objekt Lejon Objekt Lejon är det stora objektet i detta experiment. Det består av ca 400 kurvor/linjer samt 23 lager vilket gör de 250 kurvor/linjer större än objektet som ses som medelstort. Detta test ger ett resultat av hur mycket renderingsmotorns resurser som går åt för antalet kurvor/linjer. Testerna utförs som alla tidigare, i tre olika webbläsare och analyseras i Excel genom att skapa grafer baserat på medelvärdet för varje iteration. Om man tar summan av ett antal iterationer av medelvärdet (1,10,100 och 1000) från varje test av de olika webbläsarna så kan man tydligt se skillnaden av hur renderingsmotorn i webbläsaren reagerar på objekten som målas ut. 19

23 Figure 12.1: Objekt Lejon summan av 1,10,100 och 1000 iterationer. Figure 12.2: Bättre syn av figure 12.1 iteration 1 och

24 Figure 12.1 visar tydligt att väl när man kommer upp i ett större antal kurvor/linjer i ett objekt så blir det en betydligt större skillnad bland de olika webbläsarna. Om man fokuserar mer på iteration 100 och 1000 i y-axeln kan man se att Google Chrome har en betydligt mycket bättre renderingstid av summan av antalet iterationer. Vad som mäts i figure 12.1 är summan av 1,10,100 och 1000 iterationer av 10 objekt per iteration, alltså vid varje iteration så målar man ut 10 stycken lejon. Dessa 10 lejon målas ut intill varandra. Figure 12.2 är samma värden som i figure 12.1 men fokuserar på summan av iteration 1 och 10 på grund av att dessa staplar i grafen blir så pass små att det blir svårt att tyda, men med grafen i figure 12.2 får man en bättre graf vilket innebär summan av första iterationen samt de 10 första. Man kan tydligt se att Google Chrome startar snabbast och Mozilla Firefox startar långsamt medan Safari ligger mitt emellan. Standardavvikelsen för varje webbläsare går inte i varandra vilket innebär en 98% chans att nästa mätning hamnar inom standardavvikelsen enligt rule, Wikipedia Alla tre objekt tillsammans i samma webbläsare Den analys som görs under denna punk är att jämför renderingstiden av summan av 1, och 1000 iterationer av 10 objekt per iteration av de tre olika objekten (krokodil, tält och lejon) för att se hur mycket längre tid de tar. Analysen sker för enskilda webbläsare, alltså tre objekt målas ut 10 gånger med 1000 iterationer i Google Chrome, Mozilla Firefox och Safari. Figure 13.1: Summan av 1,10,100 och 1000 iterationer av tre olika objekt i Chrome. Det man kan resultera ut analysen i figure 13.1 är att renderingstiderna för de tre olika objekten ökar, den blå stapeln står för det lilla objektet, den röda för det medelstora objektet och den gröna för det stora objektet. Analysen görs i Google Chrome med standardavvikelsen 21

25 multiplicerat med tre. Antalet kurvor/linjer skiljer inte mycket mellan den blå och röda stapeln, vad man kan sammanfatta från det är att renderingsmotorn i webbläsaren reagerar olika beroende på hur många lager ett objekt består av. Om man jämför den röda och den gröna stapeln som inte skiljer så mycket i antal lager men däremot i antalet kurvor/linjer kan man tydligt se att summerade renderingstiden skiljer mycket. Med detta sagt kan resultera att renderingsmotorn reagerar annorlunda för objekt med ett större antal kurvor/linjer och inte bara antal lager i ett objekt. Figure 13.2: Summan av 1,10,100 och 1000 iterationer av tre olika objekt i Firefox. Vad man kan se i figure 13.2 är en likadan analys som i 13.1, den ända skillnaden är att analysen sker i Mozilla Firefox. Vad man kan resultera i när man kollar på denna graf är att det skiljer mycket mer mellan stapel blå och röd, alltså att Mozilla Firefoxs renderingsmotor reagerar sämre på renderingstiden av ett objekt som består av mer antal lager och inte lika mycket på antalet kurvor/linjer som Google Chrome gör. 22

26 Figure 13.3: Summan av 1,10,100 och 1000 iterationer av tre olika objekt i Safari. Figure 13.3 gäller det de samma som i figure 13.1 och Det som är annorlunda är att denna figure visar mätningsvärden från webbläsaren Safari. Man kan se i denna graf att det stora objektet (lejon, vilket är den gröna stapeln) verkligen sticker ut, alltså kan man med säkerhet säga att Safaris renderingsmotor reagerar sämre på objekt med ett större antal kurvor/linjer. Skillnaden mellan den blåa och röda stapeln är skillnaden mellan de lilla och det medelstora objektet vilket skiljer i stor del av antal lager i bilden, detta leder till att Safari också reagerar på antalet lager i en bild men också antalet kurvor/linjer. 5.3 Slutsats Efter att ha gjort analyser på olika mätningarna som gjort i detta experiment kan man dra ett antal slutsatser. För att tydliggöra vad som har testats i detta projekt så är de inte mätningar av objekt med olika egenskaper på attributen. Alltså inga mätningar på samma objekt fast med olika egenskaper, exempelvis ändring av färger, tjockleken på bordern och så vidare. Det som har testats är hur webbläsarens renderingsmotor reagerar på objekt som är uppbyggda på olika sätt. Vad som menas med uppbyggda är hur strukturen ser ut, består objektet av ett stort antal linjer eller är de mer avancerat. Ett mer avancerat objekt är uppbyggt av många lager, ett nytt lager behövs när man ändrar färg eller börjar på en ny utritningspunkt. Vad som då mäts är hur lång tid det tar att måla ut ett objekt med många lager till skillnad från ett objekt med ett större antal linjer och få lager. En utav dessa slutsatser som kan dras är att standardavvikelsen ser olika ut beroende vilken webbläsare testerna utförs i. Standardavvikelsen i Mozilla Firefox har den största positiva och negativa piken vilket innebär att renderingstiderna för varje iteration i Mozilla varierar mest, vilket innebär att nästa mätning kommer att hamna inom just den standardavvikelsen. 23

27 Standardavvikelsen i Google Chrome är mindre än Mozillas men har också en stor skillnad mellan den positiva och negativa piken. Webbläsaren med den minsta standardavvikelsen är Safari, om man kollar de grafer som har tagits upp under analysdelen kan man se att i alla grafer är de Safari som har en minsta standardavvikelse vilket innebär att nästa mätning kommer till 98% chans att hamna inom den piken. En annan slutsats som man kan dra i etta experiment är att Mozilla Firefoxs renderingsmotor reagerar sämre på objekt med flera antal lager i sig tillskillnad mot objekt som består av ett större antal kurvor/linjer, det är något man kan se tydligt i figure Däremot kan man också dra slutsatsen att Google Chromes renderingsmotor reagerar sämre på objekt med ett större antal kurvor/linjer tillskillnad mot objekt som består av fler antal lager i sig. Detta är rena motsatsen mot Mozilla Firefox. Det sista slutsatsen man kan dra med detta experiment är att Google Chrome hanterade de mätningarna bäst i längden, alltså att när man kommer upp i ett större antal iterationer så blir den summerade renderingstiden för Google Chrome den lägsta jämfört med Mozilla Firefox och Safari. Man kan också se att Mozilla var den webbläsaren som presterade sämst under dessa mätningar vilket gör att Safari hamnar mitt emellan Chrome och Mozilla. Däremot så presterade Safari bättre i uppstarten, alltså att Safari hanterade de första iterationerna snabbast men tappade i längden och detta har att göra med att Google Chromes iterationer var så pass varierande, att de kunde gå från 30 ms till 7 ms. Google Chrome presterade därför bättre vid 1000 iterationer istället för 1-5 iterationer men att Safari alltid höll sig på samma tid under alla 1000 iterationer vilket gör de till den stabila webbläsaren. Om man sammanfattar denna slutsats med hypotesen från tidigare kapitel kan man bekräfta att hypotesen stämmer överens med resultatet. Ett objekts renderingstid behöver inte vara beroende av antal kurvor/linjer utan mer av objektets uppbyggnad, alltså hur många lager bilden består av. Figure 13.1, 13.2 och 13.3 visar alla tre att det är skillnad på renderingstiden av objekt som består av näst intill samma antal kurvor/linjer men har olika attribut i sig. 24

28 6 Avslutande diskussion 6.1 Sammanfattning Om man kollar på frågeställningen tidigare i dokumentet under problem-kapitlet, exempelvis om man ritar ut ett objekt med andra linjeparametrar, hur påverkas svarstiden? Svarstiden eller med andra ord renderingstiden påverkar på olika sätt beroende på vilken webbläsare man väljer att rendera i. I detta experiment testades Google Chrome, Mozilla Firefox och Safari och man kan sammanfatta det kort. Google Chromes renderingstider påverkar av hur många kurvor/linjer och objekt innehåller men är också den snabbaste webbläsaren i längden. Mozilla Firefoxs renderingstider påverkar av hur många lager en bild består av och är den webbläsare som har den längsta renderingstiden. Safari ligger emellan Mozilla och Chrome men håller jämnast renderingstider. Ett objekts renderingstid påverkas inte av vilken färg, opacity eller border objektet har utav av antalet kurvor/linjer eller antalet lager en bild har. Ett lager uppstår när en bild ändrar färg eller får en ny startpunkt, exempelvis en boll har endast en startpunkt eftersom att det är en cirkel. 6.2 Diskussion Vad som gör detta projekt unikt från de liknande projekten som tagits upp i bakgrunden är att det är olika objekt som testas vilket gör att man kan få en bättre förståelse av vad de olika webbläsarna är bra på men också att man utför projektet i ett fler tal webbläsare, också hur ett Canvas objekt presterar samt att se varför Canvas ligger steget efter andra format på webben. Efter att ha gjort ett sort antal mätningar förstår man varför man väljer andra filformat före Canvas. Man får en bättre förståelse av varför Canvas är så pass långsamt och vad webbläsarens renderingsmotor är bra på. Det unika med projektet är inte bara mätningarna i olika webbläsare för att sammanfatta ett resultat för varje webbläsare, men även att andra projekt som linkar detta använder sig av olika algoritmer för att ändra uppbyggnaden av Canvas objekten. Vad dessa algoritmer exakt gör är att de ersätter ett antal linjer/kurvor i en bild för att korta ner på resurser som krävs. Detta kan leda till kortare renderingstider men ger ofta ett sämre resultat när de gäller bildkvalitet. Detta är inget som görs i detta projekt, här är fokuseringen mer på tre olika objekt som är uppbyggda på olika sätt, alltså att inget är likt de andra men också att inga algoritmer används för att ändra i objekten. Vad som får mig att tro att dessa mätningsvärden och analyser är trovärdiga är på grund av att jag har används mig av ett stort antal iterationer för varje test (1000) vilket minskar chansen för att spikes ska påverka resultatet. En annan sak som gör analysen trovärdig är användningen av standardavvikelsen, den gör så att sannolikheten av nästa mätning kommer till 98% chans hamna inom just den tillagda standardavvikelsen enligt rule, Wikipedia. Varje graf i detta projekt använder sig av en standardavvikelse multiplicerat med tre vilket ökar chansen till 98% som nämndes ovan. Vad jag anser om detta projekt och vad det har för nytta inom olika arbeten finner jag intressant, arbetsbranschen som har nytta av informationen som tas upp i detta projekt är 25