1. No category

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.
Innehållsförteckning
1 Introduktion ............................................................................................................................. 1 2 Bakgrund .................................................................................................................................... 2 2.1 javascript ........................................................................................................................................... 2 2.1.1 Mätning av svarstider i javascript ......................................................................................................... 2 2.2 Canvas ................................................................................................................................................ 3 2.2.1 Bildattribut i Canvas .................................................................................................................................... 4 2.3 Tidigare arbeten ............................................................................................................................. 4 3 Problem ...................................................................................................................................... 6 3.1 Hypotes .............................................................................................................................................. 6 3.2 Metodbeskrivning .......................................................................................................................... 6 3.2.1 Metoddiskussion ........................................................................................................................................... 7 3.2.2 Alternativa metoder .................................................................................................................................... 8 3.2.3 Forskningsetik ................................................................................................................................. 8 4 Genomförande/Implementation ....................................................................................... 9 4.1 Förstudie ........................................................................................................................................... 9 4.2 Beskrivning av prototyp .............................................................................................................. 9 4.3 Pilotstudie ..................................................................................................................................... 12 5 Utvärdering ............................................................................................................................. 13 5.1 Presentation av undersökning ............................................................................................... 13 5.2 Analys .............................................................................................................................................. 14 5.3 Slutsats ............................................................................................................................................ 23 6 Avslutande diskussion ......................................................................................................... 25 6.1 Sammanfattning .......................................................................................................................... 25 6.2 Diskussion ..................................................................................................................................... 25 6.3 Framtida arbete ........................................................................................................................... 26 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 JankunKelly (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
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.
2.1.1 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
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
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 10 000 strokes. Om man då använder sig av 10
000 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.
2.2.1 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
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
3
Problem
Problemet är att dagens Canvas objekt målas ut alldeles för långsamt. Johnson och JankunKelly (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
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.
3.2.1 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
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.
3.2.2 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.
3.2.3 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
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, http://stackoverflow.com/.
4.2
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.
4.2.1
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
4.2.2
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
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
4.2.3
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.
4.2.4 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
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.
4.2.6 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
4.2.6.1
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
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
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.
5.1.1 Utrustning
MacBook Air, OS X version 10.10.3.
1,3 GHz Intel Core i5, 8GB RAM.
Grafikkort Intel HD Graphics 5000 1536 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
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.
5.2.1 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 10.
14
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 68–95–99.7 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 10.
15
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.
5.2.2 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
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
68–95–99.7 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
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 yaxlar 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
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.
5.2.3 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
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 10.
20
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 68–95–99.7 rule, Wikipedia.
5.2.4 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, 10
100 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
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
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 13.2. 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
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 13.2.
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
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 68–95–99.7
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
inte jättestor, men för personer som skapar hemsidor kan det vara intressant att veta hur
Canvas fungerar och i vilken webbläsare just de objekt man har tänkt använda sig av passar
in bäst. Informationen om slutsatserna som tas fram i projektet är något en person som
arbetar inom webbutveckling kan dra nytta av.
Olika etiker som används inom detta projekt och inom experimentet är att inte använda sig
av något som kan kopplas till en unik person. Ingen känslig information tas upp samt inga
testpersoner, dels för att jag inte direkt ansåg dra nytta av testpersoner på grund av att
testerna utför på en hårdvara men endast en person som styr vilket blir mig själv. Det enda
som undersökningen kräver är kunskap inom webbutveckling samt en utrustning för att
klara av att göra tester. Jag stävade också efter att uppnå upprepningsbarhet, alltså att vilken
annan person kan utföra exakt samma tester. Kod, resultat samt utrustning anges i
dokumentet.
6.3
Framtida arbete
Nästa steg som man kan ta detta projekt till är via att utöka hypotesen, man kan tilläga att
vid ändring av lager inom en bild kan man minska renderingstiden av ett Canvas objekt. Vad
jag menar med det är att via illustrator/photoshop sätta ihop olika lager i en bild som
använder sig av samma färger för att kunna minska antalet paths vilket kan leda till
minskade renderingstider inom webbläsaren. Om man kan minska antalet lager i ett objekt
minskas också antalet paths. Detta skulle kunna vara nästa del i just detta projekt, alltså en
kortsiktig lösning för att förbättra renderingstiderna.
Vad som skulle göra Canvas till ett bättre sätt att förmedla bilder via är ifall dagens
webbläsare förbättrar sina renderingsmotorer, för tillfället presterar Canvas inte lika bra. Att
kunna ändra bilder direkt på webben är något som skulle kunna användas effektivt men att
använda sig av färdiga bilder så som jpg och png är det bara att ladda bilden när man
kommer in på sin webbsida vilket har bättre laddningstider än vad Canvas har
renderingstider. Detta är något som jag ser som en långsiktig lösning för Canvas i framtiden,
att förbättra renderingsmotorerna inom webbläsarna.
26
Referenser
Ahmadi, N., Jazayeri, M. & Repenning, A. (2012) Performance Evaluation of User-created
Open-web Games. Proceedings of the 27th Annual ACM Symposium on Applied Computing.
SAC ’12. New York, NY, USA, ACM. s. 730–732.
Anon (n.d.) HGustavs/SVG-Converter-2014. GitHub. Tillgänglig på Internet:
https://github.com/HGustavs/SVG-Converter-2014.
Anon (2015) 68–95–99.7 rule. Wikipedia, the free encyclopedia. Tillgänglig på Internet:
http://en.wikipedia.org/w/index.php?title=68%E2%80%9395%E2%80%9399.7_rule&oldid
=659779336.
Buck, I., Humphreys, G. & Hanrahan, P. (2000) Tracking graphics state for networked
rendering. Proceedings of the ACM SIGGRAPH/EUROGRAPHICS workshop on Graphics
hardware. ACM. s. 87–95.
Chi, D. & Liu, H. (2014) A details enhancement rendering method for pointillism. Image and
Signal Processing (CISP), 2014 7th International Congress on. IEEE. s. 442–446.
Heok, T.K. & Daman, D. (2004) A review on level of detail. Computer Graphics, Imaging
and Visualization, 2004. CGIV 2004. Proceedings. International Conference on. IEEE. s.
70–75.
Jan Skansholm, Java direkt med Swing. (2013) (6.uppl.).
Johnson, D.W. & Jankun-Kelly, T.J. (2008) A Scalability Study of Web-native Information
Visualization. Proceedings of Graphics Interface 2008. GI ’08. Toronto, Ont., Canada,
Canada, Canadian Information Processing Society. s. 163–168.
McAnlis, C., Lubbers, P., Jones, B., Mazur, A., et al. (2014) HTML5 Game Development
Insights. Apress.
Meek,
A.
(2014)
The
Pink
Golf
Ball.
Tillgänglig
på
Internet:
https://www.flickr.com/photos/adammeek/14657862889/ [Hämtad February 17, 2015].
Mehrara, M., Hsu, P.-C., Samadi, M. & Mahlke, S. (2011) Dynamic parallelization of
JavaScript applications using an ultra-lightweight speculation mechanism. 2011 IEEE 17th
International Symposium on High Performance Computer Architecture (HPCA). February
s. 87–98.
Mikkonen, T. & Taivalsaari, A. (2009) Creating a Mobile Web Application Platform: The
Lively Kernel Experiences. Proceedings of the 2009 ACM Symposium on Applied
Computing. SAC ’09. New York, NY, USA, ACM. s. 177–184.
27
Mowery, K. & Shacham, H. (2012) Pixel perfect: Fingerprinting canvas in HTML5.
Proceedings of W2SP.
Pinto, E., Amador, G. & Gomes, A. (2010) A graphics library for delivering 3D contents on
Web browsers. 2010 6th International Conference on Digital Content, Multimedia
Technology and its Applications (IDC). August s. 109–114.
Rajamony, R. & Elnozahy, E. (Mootaz) (2001) Measuring Client-Perceived Response Time
on the WWW. USITS. s.
Shiraishi, M. & Yamaguchi, Y. (2000) An algorithm for automatic painterly rendering based
on local source image approximation. Proceedings of the 1st international symposium on
Non-photorealistic animation and rendering. ACM. s. 53–58.
Thummalapenta, S., Devaki, P., Sinha, S., Chandra, S., et al. (2013) Efficient and Changeresilient Test Automation: An Industrial Case Study. Proceedings of the 2013 International
Conference on Software Engineering. ICSE ’13. Piscataway, NJ, USA, IEEE Press. s. 1002–
1011.
Wei, J. & Xu, C.-Z. (2011) Measuring Client-Perceived Pageview Response Time of Internet
Services. IEEE Transactions on Parallel and Distributed Systems. 22 (5), s. 773–785.
28
Appendix A -
CSS
@charset "utf-­‐8"; /* CSS Document */ body{ background-­‐color: #607D8B; margin:0 auto; } .wrapper{ width: 1230px; height: 250px; margin: 20px 25px 20px 25px; margin-­‐left: auto; margin-­‐right: auto; } .titel{ height: auto; width: 600px; margin-­‐left: auto; margin-­‐right: auto; background-­‐color: #455A64; } .knapp{ text-­‐align: center; margin-­‐bottom: 20px; } .nextsite{ height: auto; width: 200px; background-­‐color: #455A64; margin-­‐left: auto; margin-­‐right: auto; 29
text-­‐align: center; } .paintbutton{ height: 45px; width: 75px; font-­‐size: 25px; background-­‐color: #B6B6B6 } h2{ color: #CFD8DC; font-­‐family: Georgia, Times, Palatino, serif; font-­‐size: 35px; } h3{ color: #CFD8DC; font-­‐family: Georgia, Times, Palatino, serif; font-­‐size: 30px; } h3:hover{ color: #795548; } 30
Appendix B -
HTML
<!DOCTYPE html> <html> <head> <meta charset="UTF-­‐8"> <link rel="stylesheet" type="text/css" href="sidomall.css"> <script type="text/javascript" src="canvas.js"></script> <title>Filips Examensarbete</title> </head> <body> <div class="titel"> <h2>Filips Examensarbete våren 2015</h2> </div> <div class="wrapper"> <canvas id="myCanvas" width="1000" height="500"> </canvas> </div> <div class="knapp"> <select id="menu"> <option value="1">Symboler</option> <option value="2">Orm</option> <option value="3">test</option> </select> <input onclick="option()" type="submit"value="Paint"></input> <input onclick="clearcanvas()" type="reset"value="Clear"></input> <input onclick="downloadfile()" type="submit"value="Download"</input> </div> </body> </html> 31
Appendix C -
Javascript
function option(){ var x = document.getElementById("menu").selectedIndex; // alert(document.getElementsByTagName("option")[x].text); if(document.getElementsByTagName("option")[x].value==1){ initcanvas(); } else if (document.getElementsByTagName("option")[x].value==2){ drawsnake(); } else { } } var ctx; function segment(kind,x1,y1,x2,y2,x3,y3) { this.kind = kind; this.x1 = x1; this.y1 = y1; this.x2 = x2; this.y2 = y2; this.x3 = x3; this.y3 = y3; } function path(fgcolor, stcolor,lineW, gAlpha) { this.fgcolor = fgcolor; this.stcolor = stcolor; this.lineW = lineW; this.gAlpha = gAlpha; this.segments = new Array(); this.draw = function() { 32
ctx.beginPath(); ctx.fillStyle=this.fgcolor; ctx.strokeStyle=this.stcolor; ctx.lineWidth=this.lineW; ctx.globalAlpha=this.gAlpha; for(i=0;i<this.segments.length;i++){ var seg=this.segments[i]; if(seg.kind==1){ ctx.moveTo(seg.x1,seg.y1); }else if(seg.kind==2){ ctx.lineTo(seg.x1,seg.y1); }else if(seg.kind==3){ ctx.bezierCurveTo(seg.x1,seg.y1,seg.x2,seg.y2,seg.x3,seg.y3); } } ctx.fill(); ctx.stroke(); } } function initcanvas(){ var x = document.getElementById("menu").selectedIndex; timeArray = []; startTime = performance.now(); var canvas=document.getElementById("myCanvas"); canvas.width= window.innerWidth; canvas.height=window.innerHeight; var c = canvas.getContext('2d'); if (canvas.getContext) { ctx = canvas.getContext("2d"); if(document.getElementsByTagName("option")[x].value==1){ setupcrocodile(); }else if (document.getElementsByTagName("option")[x].value==2){ setuptent(); }else { 33
setuplion(); } } endTime = performance.now(); } Appendix D -
Svarstider
var oldtime=0; var iterations=0; var sumTime=0; var a,b,c,d,e,f,g,h,j,k,l,m,n,o,p,q,r,s,t,u,v,w,y,z; function drawCroc() { var benchmarktid=performance.now()-­‐oldtime; oldtime=performance.now(); sumTime += benchmarktid; timeArray.push("6 objekt -­‐ Iteration " + iterations + " tog " + sumTime+ " Ms Totalt och "+ benchmarktid + " Ms per iternation" + "\n"); ctx.save(); for(var i=0;i<5;i++){ ctx.translate(115,0); p.draw(); } console.log(iterations); ctx.restore(); iterations++; if(iterations<100) { window.requestAnimationFrame(drawCroc); } 34
} Appendix E -
Iterationer
if(iterations<1000) { window.requestAnimationFrame(drawCroc); } Appendix F function downloadfile(){ var string = ""; for(var c=0;c<timeArray.length;c++){ string += timeArray[c]; } var a = window.document.createElement('a'); a.href = window.URL.createObjectURL(new Blob([string], {type: 'text/csv'})); a.download = 'Examensarbete-­‐tider-­‐' + date + '.csv'; document.body.appendChild(a); a.click(); document.removeChild(a); } 35
Appendix G -
Lösning av kastad teknik
Lösning vid sex objekt/boxar.
<div class="wrapper"> <div class="bild1"> <canvas id="myCanvas1" width="400" height="250"> </canvas> </div> <div class="bild2"> <canvas id="myCanvas2" width="400" height="250"> </canvas> </div> <div class="bild3"> <canvas id="myCanvas3" width="400" height="250"> </canvas> </div> </div> <div class="wrapper"> <div class="bild1"> <canvas id="myCanvas4" width="400" height="250"> </canvas> </div> <div class="bild2"> <canvas id="myCanvas5" width="400" height="250"> </canvas> 36
</div> <div class="bild3"> <canvas id="myCanvas6" width="400" height="250"> </canvas> </div> </div> Lösning vid tre objekt/boxar.
<div class="wrapper"> <div class="bild1"> <canvas id="myCanvas1" width="400" height="250"> </canvas> </div> <div class="bild2"> <canvas id="myCanvas2" width="400" height="250"> </canvas> </div> <div class="bild3"> <canvas id="myCanvas3" width="400" height="250"> </canvas> </div> </div> Lösning vid ett objekt.
<div class="wrapper"> <div class="solobild"> <canvas id="myCanvas" width="400" height="250"> </canvas> </div> </div> 37
Appendix H -
Pilotstudie Graf 1
Del 1 – Mätning Chrome 6 objekt 50 gånger i MS
38
Del 2 - Mätning Chrome 1 objekt 50 gånger i MS
39