Adaptiv vektorgrafik och framerate i mobila enheter

(1)

ADAPTIV VEKTORGRAFIK OCH FRAMERATE I MOBILA ENHETER

ADAPTIVE VECTOR GRAPHICS AND FRAME RATE IN MOBILE DEVICES

Examensarbete inom huvudområdet Datalogi Grundnivå 30 högskolepoäng

Vårtermin 2015 David Gustafsson

Handledare: Henrik Gustavsson

Examinator: Mikael Berndtsson

(2)

Sammanfattning

Genom nya utvecklade standarder så spås webben i framtiden alltmer utgöra en fullgod applikationsplattform. HTML5 skapar bland annat möjligheten att använda sig av vektorgrafik genom Canvas-API. Användningen av vektorgrafik kräver dock lokal rendering och på en resurssvag enhet kan detta innebära att displayens framerate sjunker. Användaren upplever "lagg" och för många applikationer är detta negativt för användbarheten. För att webbapplikationer ska kunna fungera tillfredställande för en stor bredd av enheter med varierande kapacitet är det fördelaktigt att användningen av grafik sker adaptivt. Detta arbete undersöker om användningen av progressiv detaljrikedom i Canvas-grafik kan bidra till att hålla framerate uppe vid tillämpning på mobila enheter. Resultaten pekar som väntat på att reducerade detaljnivåer samt att byta ut bezierkruvor mot linjer ger förbättrad fps, men att utfallen varierar mellan olika webbläsare och telefonmodeller.

Nyckelord: HTML5, Canvas, Framerate, Level of detail

(3)

Innehållsförteckning

1 Introduktion...1

2 Bakgrund...2

2.1

Vektorgrafik ...2

2.1.1

Canvas... 2

2.1.2

Scalable Vector Graphics ... 3

2.2

Renderingstekniker ...4

2.3

Progressive level of detail ...4

2.4

Mätning av svarstider ...6

2.5

Framerate och upplösning ...7

3 Problemformulering ...8

3.1

Hypotes ...8

4 Metod ...9

4.1

Alternativ metod ...9

4.2

Etiska frågeställningar ...10

5 Genomförande ...11

5.1

Implementation...11

5.1.1

Detaljnivåer... 12

5.2

Pilotstudie...14

5.3

Progression ...14

6 Utvärdering...16

6.1

Presentation av undersökning...16

6.1.1

Mätning av exekveringstid ... 18

6.1.2

Mätning av fps ... 20

6.2

Analys och slutsatser ...20

7 Avslutande diskussion...23

7.1

Framtida arbete ...24

Referenser ...25

(4)

1 Introduktion

Taivalsaari och Mikkonen (2011) spår att genom nya utvecklade standarder så som HTML5 så kommer webben i framtiden att utgöra en fullgod applikationsplattform. Möjligheterna med HTML5 innebär att applikationer skapade i denna miljö kan användas av en stor mängd olika enheter som är beskaffade med webbläsare. Oberoende av plugins eller programvara från tredje part. Möjligheten att bygga applikationer som körs direkt i webbläsaren och inte kräver plugins eller programvara från tredjepart är också en stor fördel för de användare som verkar i miljöer där sådana inte tillåts (Cartagen, 2010). Traditionella kompilerade programvaror ställer ofta uttalade krav på användarens hårdvara för att dess funktion ska vara garanterad. Användare som når en webbaserad programvara med sin webbläsare kommer i större utsträckning förvänta sig att utan hinder kunna använda sig av den i likhet med vilken webbplats som helst.

Vektorgrafik är skalbart och därmed adaptivt för en stor variation av displayer. HTML5 skapar nya möjligheter att använda sig av vektorgrafik genom SVG-element och Canvas-API.

En annan fördel vektorgrafik har är möjligheten att genom algoritmer bryta ned den till lägre detaljnivåer (level of detail, LoD). Antalet noder (punkter) reduceras då och bilden får på så sätt mindre detaljrikedom. Användningen av vektorgrafik kräver dock lokal rendering och på en resurssvag enhet kan detta innebära att framerate sjunker, det antal gånger per sekund som displayen uppdateras. En försämrad framerate kan under vissa omständigheter innebära att användaren presterar sämre samt överlag ge en sämre användarupplevelse.

Claypool och Claypool (2009) har studerat vilken påverkan olika nivåer av framerate och upplösning har inom området datorspel och funnit att framerate genomgående har en mycket högre påverkan på användarnas resultat än vad upplösningen har.

Detta arbete undersöker om användningen av olika nivåer av detaljrikedom i vektorgrafik kan bidra till att hålla framerate uppe på mobila enheter. Hypotesen är att framerate kan bibehållas på en högre nivå om man anpassar detaljnivån i grafiken utefter den mobila enhetens beräkningskraft och upplösning

Genom ett experiment utan medverkan av testpersoner undersöks hur användningen av progressiv detaljrikedom påverkar framerate på fem olika typer av smartphones samt två olika webbläsare. En testapplikation i två delar har tagits fram. Den första delen genererar de testbilder som används i mätningarna. De canvas-ritinstruktioner som bilderna utgörs av har lagts in i ett definerat dataformat för att enklare kunna manipulera instruktionerna på olika sätt. Fyra olika bildobjekt med tilltagande nivå av komplexitet har lagts in i formatet och för vardera bild har fem olika detaljnivåer genererats med hjälp av testapplikationen. En av de fem detaljnivåerna motsvarar innehållet i originalbilden. I de övriga fyra är detaljnivån reducerad och förekomsten av Bezierkurvor har tagits bort och ersatts med en eller flera linjer.

Den andra delen av testapplikationen utgörs av en webbsida där bildobjekten ritas ut på en Canvas. De olika detaljnivåerna visas sekventiellt i 10 sekunder vardera samtidigt som de animeras i en enkel pendlande rörelse. Framerate för displayen mäts samtidigt med hjälp av javascript-funktionen RequestAnimationFrame(). Varje bild mäts på detta sätt fem gånger vilket ger totalt 50 mätvärden för framerate vid de olika detaljnivåerna. Utöver detta mäts även exkveringstiden för körningen av ritinstruktioner.

(5)

2

2 Bakgrund

Vektorgrafik kan användas på olika sätt på webben. I detta kapitel kommer olika tekniker samt deras för- och nackdelar att summeras.

2.1 Vektorgrafik

En vanlig digital bild byggs upp genom enskilda pixlar (färgblock), sådana bilder benämns ofta som pixelgrafik. Vektorgrafik byggs istället upp av geometriska primitiver bestående av punkter, linjer och kurvor som beskrivs genom matematiska uttryck och koordinater. Dessa ritas ut (renderas) när de ska visas. Då vektorgrafik består av en beskrivning av den bild som ska skapas snarare än faktisk bildinformation så kan de renderas i vilken skala som helst.

Detta till skillnad från pixelgrafiken som blir otydlig i brist på punkttäthet. I figur 1 exemplifieras detta.

Figur 1 Jämförelse av pixelgrafik (a) och vektorgrafik (b)

2.1.1 Canvas

Canvas är en scriptbaserad grafikmiljö som kan omvandla ritkommandon till motsvarande pixelgrafik. Canvas ingår i HTML5-standarden och består av två delar. Den första delen är ett ritbart område som kan placeras ut på en html-sida (<canvas>). Detta område har ingen egen förmåga att göra utritningar utan detta tillhandahålls istället genom den andra delen, ett rit-API där man genom javascript har tillgång till ett antal ritkommandon. Det finns två olika API att använda, ett för 2D-grafik och ett för 3D (WebGL). I figur 2 finns ett exempel på hur ritinstruktioner kan se ut i en 2D-canvas. Canvas-ytan i sig utgör ett DOM-objekt men för de utritade objekten finns ingen DOM (Document Object Model). Likaså saknar Canvas

(6)

en eventmodel. Detta försvårar interaktion med den grafik som renderas i en Canvas. En möjlig teknik för att överkomma detta är att lägga ett transparent SVG-objekt över canvasområdet. SVG-objekt har stöd för DOM och genom att passa in områden med interaktionsmöjlighet över de olika grafiska objekten i en canvas så kan användaren få möjlighet att interagera.

c.fillStyle = "#5D1FFF";

c.strokeStyle = "#000000";

c.lineWidth = "14.9";

c.beginPath();

c.moveTo(125,25.5);

c.lineTo(157.3,91);

c.lineTo(229.6,101.5);

c.lineTo(177.3,152.5);

c.lineTo(189.6,224.5);

c.lineTo(125,190.5);

c.lineTo(60.4,224.5);

c.lineTo(72.7,152.5);

c.lineTo(20.4,101.5);

c.lineTo(92.7,91);

c.lineTo(125,25.5);

c.globalAlpha = 1.0;

c.fill();

c.stroke();

Figur 2 Exempel på ritinstruktioner för Canvas-API

2.1.2 Scalable Vector Graphics

Scalable Vector Graphics (SVG) är ett XML-baserat grafikformat för tvådimensionell grafik som har varit en standard från WC3 sedan 1999. Det krävdes tidigare någon form av plugin till webbläsaren för att kunna visa SVG-objekt, men i och med HTML5 finns ett SVG- element (<svg>) som medger att SVG-objekt kan placeras och renderas direkt på webbsidan.

Formatet har stöd för interaktion och animation. Utritade objekt är tillgängliga genom DOM och kan därmed påverkas av CSS och interagera med javascript. Event-model medger händelser så som mouse-over. SVG-formatet kan därmed anses vara bättre lämpat än Canvas vid implementationer där interaktion med användaren är viktigt. Canvas levererar dock bättre prestanda vid rendering (Corcoran, Mooney, Bertolotto, et al., 2011). SVGT (SVG Tiny version) är en variant av SVG-formatet framtaget särskilt för mobila enheter. Eftersom ett SVG-objekt består av XML-kod med mycket repetition av samma text så kan komprimering ge ett stort genomslag. Gzip-algortimen kan användas på SVG-objekt för att skapa komprimerade versioner med filändelsen .svgz. Dessa kan bli 40-50% mindre än originalet.

(7)

4

I figur 3 finns ett exempel på XML-kod som används för att bygga upp ett SVG-objekt i form av en blå stjärna. I koden, som är genererad genom Adobe Illustrator, används standarden för SVG-Tiny formatet.

<?xml version="1.0" encoding="utf-8"?>

xmlns="http://www.w3.org/2000/svg"

xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"

width="250px" height="250px" viewBox="0 0 250 250" overflow="inherit"

xml:space="preserve">

</svg>

Figur 3 SVG-objekt och dess XML-kod

2.2 Renderingstekniker

Kee, Salowitz & Chang (2012) jämför i ett experiment ett antal olika renderingstekniker för vektorgrafik, bland annat 2D-Canvas, WebGL-Canvas och SVG. Man jämför framerate vid olika nivåer av datamängd i det renderade objektet. Författarna konstaterar att valet av teknik bör utgå från egenskaperna hos det aktuella projektet där man ska tillämpa en rendering. WebGL-Canvas är dock det bästa valet sett till prestanda. Denna teknik har vid rendering tillgång till hårdvaruaccelering via OpenGL. Nackdelen är att tekniken medför att utvecklaren måste skriva mer kod jämfört med andra tekniker samt måste vara bekant med OpenGL ES. 2D-Canvas ger nästan lika bra prestanda som WebGL-Canvas men till dess fördel kan räknas att det i experimentet endast krävdes 56 rader kod att implementera denna teknik jämfört med 205 för WebGL-Canvas.

2.3 Progressive level of detail

En fördel vektorgrafik har framför pixelgrafik är att den genom algoritmer kan brytas ned till lägre detaljnivåer, level of detail (LoD). Antalet noder (punkter) reduceras då och bilden får på så sätt mindre detaljrikedom. Figur 4 visar ett exempel på ett enkelt hörn som kan tänkas vara en del i en större figur. I sin fullskaliga version (c) har hörnet en rundad form. Genom att successivt reducera antalet noder blir hörnet alltmer kantigt. Versionen med lägst detaljnivå (a) innehåller färre ritinstruktioner och tar följaktligen upp mindre lagringsutrymme. Den kräver också mindre beräkningskraft från datorn när den ska renderas. I figuren har De Casteljau's algoritm använts, en algoritm som kan användas för att beräkna punkter på en Bezier kurva (Boehm & Müller, 1999). Kurvorna ersätts då med ett antal punkter och raka linjer mellan dessa.

(8)

Figur 4 Skärmdumpar från javascript som använder De Casteljau's algoritm i Canvas.

Chang, Chuang, Wang (2004) föreslår en kategorisering (se uppställning i figur 5) av olika tekniker för att tillämpa level of detail (LoD). Man gör en huvudsaklig uppdelning i tekniker som fungerar "on-the-fly", alltså genererar grafiken i den stund den begärs, samt tekniker där grafiken har genererats på förhand (pre-generated) och där en samling av olika versioner av samma bildobjekt finns tillgängliga direkt på servern.

Figur 5 Chang, Chuang, Wang (2004) kategorisering av LoD-tekniker.

Genom att minska ned detaljrikedomen i en vektorgrafikbild kan man förbereda den för att överföras som en progressiv ström av vektordata som stegvis kan renderas med allt mer

(9)

6

detaljrikedom. Corcoran, Mooney, Bertolotto, et al. (2011) slår fast att en överföringsteknik kan anses vara progressiv om den uppfyller följande två kriterier:

(1) Data is transmitted incrementally in the form of refinements which may be integrated and used by the client without the requirement for a complete dataset transmission. (2) Wherever possible, data previously transmitted is used to fulfill current client requests and is not re-transmitted.

Om man i figur 4 tänker sig att en progressiv överföring sker så inleds denna med det första byggsteget där hörnet är i sin enklaste form och endast består av tre punkter (a). I det andra byggsteget finns två av de ursprungliga punkterna kvar på samma plats och det är enbart information om de två tillkomna punkterna som har behövt överföras (b). Ytterligare två punkter har tillkommit i det sista byggsteget och bilden har uppnått full detaljnivå (c).

En progressiv ström av vektordata och dess byggsteg blir totalt sett större än det ursprungliga originalet på grund av extra indexeringsdata. Den tar därför längre tid att ladda hem i sin helhet. Dock ger den snabbare feedback till användaren om att en nedladdningen pågår. Om det handlar om grafik med möjlighet till interaktion så kan användaren också snabbare komma igång och börja använda sig av den data som finns tillgänglig (Han, Tao &

Wu, 2003).

2.4 Mätning av svarstider

Svarstid är den tid från att en användare i en webbläsare begär en sida eller annan resurs tills dess att svaret från webbservern är nedladdat och visas i sin helhet. Rajamony &

Elnozahy (2001) lägger fram ett principellt ramverk för hur mätningar av svarstid kan genomföras utan ett behov av extra programvara eller nämnvärd belastning på de lokala systemresurserna. Deras ramverk består främst av två komponenter, en “Timekeeper” och en “Librarian”.

"Timekeepern" genomför själva tidsmätningen genom att använda sig av möjligheten att koppla körningen av ett javascript till klick på länkar. När användaren klickar på länken körs ett angivet javascript som lägger det nuvarande klockslaget i en variabel. Denna variabel sparas lokalt med hjälp av “Librarian”. Det finns flera tekniker för hur detta kan gå till, exempelvis i en cookie-fil eller genom de nya möjligheterna till lokal lagring i HTML5. Sidan eller resursen laddas hem och genom eventhandlern “onload” körs ett andra javascript när sidan är mottagen i sin helhet. Det första tidsvärdet hämtas tillbaka, den förflutna tiden beräknas och sparas sedan undan tillsammans med ett ID för den uppmätta resursen.

Informationen kan sedan skickas vidare direkt till en mottagare, så som en databas, eller sparas undan för en senare uppladdning av flera samlade värden.

Utöver tid så kan även andra mätvärden registreras i samband med att de två scripten körs så som framerate.

(10)

Figur 6 Principen för Rajamony & Elnozahys (2001) lokala mätning av svarstid.

2.5 Framerate och upplösning

Framerate är ett mått på hur många gånger per sekund som en enhet ritar om innehållet på displayen. Upplösning syftar på antalet bildpunkter som en display visar i höjd och bredd.

En display är normalt byggd för att visa ett antal bildpunkter vid en viss framerate. Beroende på om den upplösning som datorn skickar till displayen matchar denna eller inte får bilden skalas upp eller ned. Det finns vanligtvis ett direkt förhållandet mellan upplösning och framerate sett till systemresurser. En hög upplösning resulterar i en låg framerate då systemresurserna blir otillräckliga för hålla uppe framerate. En låg upplösning möjliggör av samma anledning en hög framerate (Claypool och Claypool, 2009).

Claypool och Claypool (2009) har studerat vilken påverkan olika nivåer av framerate och upplösning har inom området datorspel. Man kom fram till att framerate genomgående har en mycket högre påverkan på användarnas resultat än vad upplösningen har. Även spelarnas subjektiva kvalitetsuppfattning av spelen följde detta förhållande. Nivån av påverkan varierade dock för olika spelgenrer och spelmoment. För spel med små tidsmarginaler och inslag där hög precision är av vikt hade framerate som störst påverkan.

Den framerate som en enhet för närvarande producerar kan mätas på olika sätt. För att mäta framerate genom webbläsaren utan att använda programvara från tredje part kan javascript- kommandot RequestAnimationFrame() vara ett sätt. RequestAnimationFrame() är ett API för att mer effektivt köra scriptbaserade animationer. Den traditionella metoden är att använda timeouts, funktioner som räknar tid och begär en ny renderingscykel varje gång denna tidsräkning har gått ut. Genom att använda RequestAnimationFrame() överlåts styrningen av när renderingen sker till webbläsaren som kan koordinera den med andra animeringar och framförallt anpassa den till tillgänglig beräkningskapacitet. Detta kan förhindra att en animation överbelastar och destabiliserar en webbläsare. Funktionen kan också stoppa animeringar som sker i fönster som inte syns för användaren och på så sätt spara resurser. Genom att räkna hur många frames i sekunden som RequestAnimationFrame() renderar en animation så får vi dels fps-värdet för webbläsarens fönster och dels ett indirekt värde på hur hårt belastade systemresurserna för närvarande är (Sawicki & Chaber, 2012).

(11)

8

3 Problemformulering

Problemet är att när komplex grafik skall ritas ut på displayen och det finns otillräckligt med beräkningskraft tillgängligt så begränsar detta uppdateringsfrekvensen av displayen. Detta kan ha en negativ inverkan på användarupplevelsen beroende på uppgiften som användaren ägnar sig åt samt graden av interaktion (Claypool och Claypool, 2009).

Syftet med detta arbete är att, med särskilt fokus på mobila enheter, undersöka hur stor påverkan användningen av progressiv detaljrikedom i vektorgrafik kan bidra med för att göra en webbapplikation mer adaptiv för olika hårdvarumiljöer. Adaptiva applikationer måste vara medvetna om och ta hänsyn till den hårdvarumiljö som programmet körs i (Wang och Cheng, 2004). Detta arbete inriktar sig på adaptiv användning av vektorgrafik i webbapplikationer. Dels sett till hårdvarans förmåga att rendera grafiken och dels sett till tillgänglig bandbredd för överföring av data.

He et al. (2007) pekar på flera fördelar med användningen av vektorgrafik i mobila enheter.

Hög kvalitet i förhållande till filstorlek, förlustfri kompression utan artefakter och framförallt enkel skalbarhet för visning på displayer av varierande storlek. Vektorgrafik kräver dock rendering och mobila enheters begränsade beräkningskraft utgör ett hinder i detta (Wang och Meng, 2010). Utan wifi-uppkoppling har dessa enheter även normalt en begränsad bandbredd tillgänglig att hämta data över och datatung grafik kan ge märkbara nedladdningstider för användaren.

Vid brist på CPU/GPU vid rendering av vektorgrafik kan framerate försämras. Vid varje uppdatering av skärmen ska grafiken ritas ut på nytt. När kapaciteten hos hårdvaran inte räcker till hoppas cykler över. Detta kan medföra en ryckig uppdatering av skärmen, så kallat

”lagg” och medför en försämrad användarupplevelse. Progressiv detaljrikedom (Progressive level of detail) ger en möjlighet att rita ut grafiken i en enklare version som kräver mindre systemresurser vid rendrering. Det krävs också mindre dataöverföring för att få fram en första version av bilden till användaren (Sawicki och Chaber, 2012). Den data som ligger till grund för vektorgrafiken är på förhand nedbruten i flera nivåer med allt lägre inslag av detaljer. Vid rendering av bilden använder sig varje detaljnivå av informationen från den föregående nivån. Programvaran kan stanna vid den nivå som är hållbar sett till omständigheterna. Sawicki och Chaber (2012) visar i sitt försök med 3D-grafik hur uppdateringsfrekvensen (frames per second) kan hållas högre genom stoppa renderingen vid en detaljnivå som kan hanteras av tillgänglig hårdvara. Samma förhållande bör gälla även 2D-grafik.

3.1 Hypotes

Hypotesen är att uppdateringsfrekvensen kan bibehållas på en högre nivå om man anpassar detaljnivån i grafiken utefter den mobila enhetens beräkningskraft och upplösning. En anpassad detaljnivå innebär en lägre detaljnivå än vid den fullständiga kompletta bilden.

Detta måste dock inte nödvändigtvis innebära en sämre användarupplevelse för användaren då en display med låg upplösning ändå inte kan visa de detaljer som går förlorade.

(12)

4 Metod

Metoden för undersökningen är experiment. Experiment lämpar sig när man vill manipulera skeenden direkt, precist och systematiskt (Wohlin et al., 2012). Inspiration hämtas från det experiment Sawicki och Chaber (2012) genomför med sin prototypapplikation för visning av 3D-vektorgrafik i webbläsare. De använder sig då av utritning i ett Canvas-element och tillämpar progressiv detaljnivå. Uppdateringsfrekevensen för displayen mäts vid de olika detaljnivåerna som ett mått på hur belastad enheten är. En avgörande skillnad för detta experiment är att tvådimensionell grafik kommer att används istället för tredimensionell.

En algoritm kommer att implementeras för omvandlingen av vektorgrafikobjekt till versioner med flera steg av successivt lägre detaljnivå. Ett antal vektorgrafikobjekt av varierande komplexitet genomgår denna omvandling för att fungera som testobjekt i mätningarna. En testapplikation implementeras i form av en webbsida med en HTML5- Canvas i vilken grafiken renderas i omvänd ordning med den lägsta graden av detaljrikedom först. Displayens uppdateringsfrekevens (framerate) mäts vid visningen av grafiken vid de olika graderna av komplexitet (antal vertices), liksom tid till första visningen av en bild.

Testet genomförs på ett antal olika mobila enheter och webbläsare. Mätningar i experimentet kommer att genomföras enligt de principer Rajamony & Elnozahy lägger fram (2001). Mätdata sparas genom javascript i lokala variabler som efter att mätningen har avslutats förs över från enheten för sammanställning.

Funktionen RequestAnimationFrame() i javascript överlåter styrningen av uppdateringsfrekvensen för grafiken till webbläsaren. Den ger också en möjlighet att indirekt mäta hur hårt belastade systemresurserna är genom att räkna utfallet av frames per second (Sawicki and Chaber, 2012). Mätningen av uppdateringsfrekvensen skulle även kunna göras med sådana utvecklingsverktyg som exempelvis webbläsarna Chrome och Firefox inkluderar. Användningen av dessa skulle dock göra det svårt att jämföra mätningar från olika webbläsare mot varandra eftersom det är troligt att värdena i dessa verktyg inte beräknas med samma tekniker.

4.1 Alternativ metod

Experimentet är teknikorienterat och involverar inga testpersoner. Resultaten blir genom detta mer exakta men aspekter går också förlorade. Om en låg uppdateringsfrekvens kan anses vara ett problem eller inte avgörs mycket av den uppgift en tänkt användare försöker genomföra. Vid vissa uppgifter kan en reduerad framerate ligga inom toleransområdet och inte ha någon nämnvärd påverkan på personens användarupplevelse (Claypool och Claypool, 2009).

Genom användandet av testpersoner skulle mätdata också kunna inhämtas kring upplevd kvalitet på grafiken som behandlas. Även om reduceringen av detaljrikedom leder till förbättrad framerate kan den upplevda kvalitén falla utanför ramen för vad användare finner acceptabelt vilket reducerar metodens värde. Även användarnas toleransnivåer för laddningstider skulle kunna vara intressant att mäta då användningen av progressive level of detail normalt ska ge en kortare tid till första visningen av en begärd bild. De Silva, Cheng, Ooi, et al. (2010) gör en sådan mätning där man begränsar sig till faktorerna nätverksfördröjning och datahastighet. Man konstaterar dock att många fler faktorer kan

(13)

10

påverka användarnas toleransnivå och att en fullskallig undersökning skulle bli mycket stor.

Man kan spekulera i att en sådan faktor som påverkar är mognadsgraden hos använd hårdavaruteknik och att användarnas toleransområde kan skifta i och med teknikutvecklingen. Detta skulle minska värdet i resultaten från en sådan undersökning då de skulle bli svåra att jämföra över tid.

En alternativ metod till experimentet skulle kunna vara en fallstudie där en framtagen artefakt tillämpas i en verklig kontext. Fallstudier har fördelen att de är enklare att planera och har mer realistiska omständigheter än ett experiment (Wohlin et al., 2012). Det finns dock många olika typer av applikationsområden för adaptiv vektorgrafik med olika förutsättningar och egenskaper så som kartapplikationer, spel och grafik i användargränssnitt. Det skulle bli svårare att dra några generella slutsatser kring möjligheterna vid användandet av adaptiv detaljnivå. En fallstudie ligger också utanför de praktiska förutsättningarna för detta arbete.

4.2 Etiska frågeställningar

Mätningen involverar inga testpersoner eller personuppgifter och ingen testdata kan därför kopplas till personer. Ingen behöver heller notifieras om testet före dess genomförande.

Testdatan, som består av bildmaterial, porträtterar neutrala objekt som ej riskerar att väcka anstöt och som är representativa för verkliga scenarion.

För att underlätta återupprepning av experimentet kommer all programkod som skapas att publiceras med denna rapport tillsammans med information om vilka webbläsare i vilka versioner som har använts, vilken typ av enheter som testerna genomförts på samt hänvisningar till de grafiska objekt som testerna har körts med. De sistnämnda kommer även vara fria att använda och vara licensierade enligt Creative Commons eller motsvarande.

På så vis ska det finnas goda förutsättningar att genomföra mätningen på ett likartat sätt och därigenom kunna verifiera eller avfärda resultaten från denna undersökning.

Då mätningarna i experimentet sker med en egendefinerad kod, istället för inbyggda verktyg i webbläsaren, så minskar risken att resultaten ska viktas till någon enskild webbläsare eller leverantörs fördel. Rapporten ska i övrigt förhålla sig leverantörsoberoende genom att mäta på mobila enheter av olika fabrikat liksom på flera olika webbläsare.

(14)

5 Genomförande

5.1 Implementation

Den för mätningen framtagna webbapplikationen består av en canvas-yta på vilken bildobjekt ritas ut och animeras i en enkel pendlande rörelse genom funktionen translation(). En FPS-mätare summerar antalet bilduppdateringar för varje sekund (Stackoverflow, 2011). Ett testprogram initieras så fort sidan har laddats och visar det aktuella bildobjektet sekventiellt i fyra olika detaljnivåer. Varje detaljnivå visas i tio sekunder innan den går vidare till nästa, varje visning ger alltså tio st mätvärden för "frames per second". Alla mätvärden lagras i en variabel och skrivs ut på skärmen först efter att mätningarna är slutförda för att undvika påverkan av renderingstider.

I den framtagna applikationen har ett dataformat satts upp för organiseringen av de Canvas- ritinstruktioner som används för mätningarna. Formatet, som liknar det för SVG fast i en enklare variant, använder sig av en kombination av arrayer och javascript-objekt (figur 7).

Varje bildobjekt (image) består av en array som innehåller ett antal kurvor (paths) i form av javascript-objekt. Dessa objekt håller dels ett antal övergripande egenskaper för kurvan så som linestyle (ls) och fillstyle (fs) men också en array av de segment som kurvan består av.

Dessa segment utgörs av olika typer av javascriptobject som motsvarar de olika ritinstruktioner som finns, bland annat lineTo() och moveTo(). Varken applikationen eller dataformatet medger någon möjlighet att bygga vidare på bildinformation från tidigare hämtad detaljnivå utan varje detaljnivå ritas ut var för sig. Bilderna som används i mätningarna har konverterats från SVG-format till canvas ritkommandon och har sedan utan vidare modifiering förts in i dataformatet.

Genom användningen av loop-funktioner i applikationen omsätts sedan informationen till ritinstruktioner i den stund de begärs. I denna första versionen av applikationen tillämpas alltså den variant av LoD-teknik som Chang, Chuang, Wang (2004) refererar till som “on- the-fly". Den begärda detaljnivå genererades på begäran för varje renderingscykel.

Användningen av dataformatet möjliggör enkel modifiering av hur ritinstruktionerna i bilden ska användas, man kan exempelvis välja att hoppa över en viss typ av ritinstruktion eller att ersätta den med något annat, så som körningen av en funktion. För kunna ersätta en instruktion med användningen av en funktion kan det vara nödvändigt att kunna hålla reda på “current path”, alltså var på ritytan man befinner sig inför nästa ritkommando. Det finns ingen funktion i canvas rit-API för att få fram koordinaterna för den nuvarande positionen.

(15)

12

Figur 7 Dataformat för hantering av Canvas-ritinstruktioner.

5.1.1 Detaljnivåer

Testbilderna, som utgår från public-domain-bilder hämtade från openclipart.org, kan visas i fem olika detaljnivåer (figur 8). Nivå 2 och 3 använder sig av De Casteljau's algoritm för att ersätta varje Bezier-kurva med ett antal punkter och raka linjer (ritkommandot lineTo()).

Utgångspunkten är att Bezier-kurvor är mer resurskrävande än raka linjer och att dessa tillsammans ska kräva mindre systemresurser att rendera än den kurva de ersätter. På nivå 2 ersätts kurvorna med två linjer och på nivå 3 med tre linjer. På nivå 1 har alla bezierkruvor ersatts direkt med en enstaka linje med samma start- och stopppunkt. Nivå 0 utgår från nivå 1 och genom en algoritm har vartannat linje-objekt plockats bort där minst två sådana förekommer i följd. Antalet ritkommandon samt bildens detaljnivå blir därmed påtagligt reducerade jämfört med nivå 1. Nivå 4, den högsta nivån, är originalbilden med alla Bezier- kurvor intakta.

(16)

Figur 8 De fem olika detaljnivåerna för två av bildobjekten. "Bil" och "Citron".

(17)

14

5.2 Pilotstudie

Preliminära mätningar visade på ett oväntat resultat där originalbilden gav ett klart högre FPS-värde jämfört med de reducerade versionerna, alltså tvärtemot vad som kunde förväntas. Vid närmare undersökning visade det sig att den tillämpade De Casteljau- funktionen tog påtaglig tid att exekvera vilket gav långsammare rendering av detaljnivåerna 2 och 3 där denna användes. För att ge samma förutsättningar för alla detaljnivåer vid mätningarna av FPS utvecklades applikationen vidare för att cacha ritinstruktionerna efter det att den första renderingcykeln körts igenom. På så sätt borde De Casteljau-funktionens inverkan bli minimal då den endast exekveras en gång per mätning. Parallellt med att ritinstruktionern kördes första gången så skrevs de även in som en sträng till en variabel som sedan gång på gång exekverades genom den inbyggda javascript-funktionen eval(). Även efter denna modifikation förblev dock skillnaden i FPS. Vidare undersökning visade att eval- funktionen i sig är mycket kostsam. Mätningar visade att det med eval() i snitt tog 0,72 milisekunder att genomföra en ritoperation där motsvarande normal körning av instruktionerna tog 0,07 milisekunder, alltså en tiondel så lång tid. Detta beror bland annat på att kompilatorn inte kan optimera koden när eval() används (Flanagan, 2002).

5.3 Progression

För att lösa problemet med den kostsamma eval-funktionen justerades utgångspunkten för mätningen till att alla ritkommandon är pre-generated på serversidan, alltså den andra varianten av LoD-teknik som Chang, Chuang, Wang (2004) definierar i sin uppställning. Sett till avgränsningen för denna undersökning har detta ingen påverkan på mätningarna. Det fastställda dataformatet används då endast för att på förhand få fram ritkommandona för de olika LoD-versionerna av bilderna. Dessa körs sedan som rena ritkommandon som placerats i enskilda funktioner. Applikationen blir därmed uppdelad i två delar. En del som används för att förbereda de olika nivåerna av ritinstruktioner. En annan som kör utritning och genomför mätningar.

Med dessa förbättringar genomfördes en ny mer omfattande provmätning där två bildobjekt renderades tillsammans på en iPhone4 samt en iPhone5 med webbläsaren Safari.

Testprogrammet registrerar 10 mätningar av varje nivå och kördes i fem omgångar.

Medelvärdet av dessa 50 mätningar för respektive detaljnivå presenteras i figur 9.

Standardavvikelsen har beräknats med online-verktyg som tillhandahålls av Arcidiacono, G (2009). Dessa första mätvärden indikerade att det inte finns några resursvinster att hämta i de tekniker för reducering av detaljnivå som har använts. Även när en bezierkurva ersatts med endast en linje (nivå 1) så blir FPS-värdet lägre än när den fullskaliga versionen ritas ut.

Exkveringtiden för respektive ritfunktionen uppmättes ej, men antalet rader kod (ritkommandon) för den mer komplexa av de två objekten som ritades ut är 360 rader i fullversionen att jämföra med 288 för nivå 1. Färre ritkommandon exekverades alltså i nivå 1 än i nivå 4.

Vidare undersökning visade dock på en brist i genereringen av de nya detaljnivåerna.

Överflödiga stroke() kommandon lämnades kvar vilket kraftigt bidrog till att påverka mätvärdena. Dessa hade ingen påverkan på bildens utseende utan förlängde endast utritningen. I ett vidare progressionssteg så togs dessa överflödiga ritinstruktioner bort manuellt och förekommer inte i efterföljande mätningar.

(18)

Figur 9 Resultat från provmätning.

(19)

16

6 Utvärdering

6.1 Presentation av undersökning

Mätningar har genomförts på fem olika mobila enheter (se tabell 1). För iPhone5-enheten har två mätningar genomförts, dels med Safari som webbläsare och dels med Chrome. Detta för att kunna få en indikering på hur stor påverkan webbläsaren har på de uppmätta värdena.

Testprogrammet kör igenom en animering av respektive detaljnivå i tur och ordning med start på nivå 0. För varje nivå registreras 10 värden av det snitt som fps-värdet uppnår under en sekund. Med fem olika detaljnivåer tar en komplett mätserie alltså ca 50 sekunder att köra igenom. Varje bildobjekt har körts i fem kompletta mätningar på respektive enhet vilket ger totalt 50 mätvärden per detaljnivå. Standardavvikelsen har beräknats med funktionen

"STDEVP" i Google Drive spreadsheet. Inga testpersoner har varit involverade i mätningarna och det har därför kunnat garanteras att alla mätningar genomförts under likartade förutsättningar. Webbfönstret har lämnats öppet under hela mätningen, skärmen har inte scrollats och enheterna har ej varit anslutna för laddning.

Utöver fps har även exekveringstiden för respektive cykel registrerats, alltså körningen av samtliga ritkommandon i respektive detaljnivå. Enligt principerna Rajamony & Elnozahy (2001) lägger fram har en timekeeper registrerat klockslag med hjälp av funktionen Performance(). iOS-enheterna saknar dock stöd för denna funktion varför Date() har fått användas istället. Denna funktion ger en lägre upplösning i mätvärdet, endast hela millisekunder, varför mätningarna från de två olika operativsystemet inte blir fullt ut jämförbara. För att få en hanterbar mängd mätvärden har endast var 20:e renderingscykel registrerats, dock alltid den första körningen i varje detaljnivå.

Tabell 1 Testenheter

Modell OS Webbläsare

Sony Xperia Z2 Android 5.0.2 Chrome v. 42.0.2311.111 Samsung Galaxy Alpha SM-G850F Android 4.4.4 Chrome v. 42.0.2311.111

Sony Z3 Android 5.0.2 Chrome v. 42.0.2311.111

iPhone4 iOS 7.1.2 Safari

iPhone5 iOS 8.3 Safari

iPhone5 iOS 8.3 Chrome 42.0.2311.47

Fyra olika bildobjekt, med en successivt tilltagande komplexitet, har använts i mätningarna (se tabell 2). Ett femte mätobjekt har utgjorts av två av bildobjekten (bilen och älgen) som ritas ut tillsammans på skärmen.

(20)

Tabell 2 Ritkommandon i bildobjekt

Bildobjekt: Tennisboll Citron Älg Bil Bil+Älg Antal ritkommandon lvl 0 24 100 187 444 631 Antal ritkommandon lvl 1 25 144 358 636 994 Antal ritkommandon lvl 2 44 345 764 1473 2237 Antal ritkommandon lvl 3 52 441 966 1863 2829 Antal ritkommandon lvl 4 28 153 360 693 1053

Antal bezierkurvor 8 96 202 390 592

Antal tecken i lvl 4 i förhållande

till SVG-original 17% 89% 166% 113% 127%

Antalet ritkommandon för nivå 1 och 4 ska egentligen bli detsamma då varje bezierkurva ersätts med en motsvarande linje. Mindre skillnader förekommer dock då ett sent upptäckt fel i genereringen av level 1 har resulterat i att kommandot för globalAlpha utelämnats.

Värdet avgör opaciteten för den aktuella kurvan och har ingen större betydelse för mätresultaten annat än att antalet ritkommandon skiljer sig något.

Användningen av RequestAnimationFrame() som en del i mätmetoden förefaller inte medge mätningar på allt för enkla bildobjekt. Grafen i figur 10 ger ett exempel på hur framerate förblir mer eller mindre konstant vid de olika detaljnivåerna för det enklaste bildobjektet (Tennisbollen). Det krävs mer komplexa objekt för att tendenserna ska bli synliga. Fokus ligger därför på mätningen av bildobjektet med flest ritoperationer (Bil+Älg).

Figur 10 FPS-värden för bildobjekt "Tennisboll"

(21)

18

6.1.1 Mätning av exekveringstid

Den första utritningscykeln av en ny detaljnivå visar genomgående ett högt värde för exekveringstid. Med största sannolikhet då webbläsaren efter den första körningen återvinner instruktionerna från en cache. Alla testade enheter visar genomgående samma cachnings-beteende och detta exemplifieras i figur 11 där mätvärden från bildobjektet

"Älg+Bil" på iPhone4 presenteras. Mätvärdena för dessa initiala körningar är borttagna ur figur 12 då det är den kontinuerliga uppdateringsfrekvensen som är intressant. De initiala värdena presenteras för sig i figur 13. Förutom att generellt ligga högre så följer dessa intitialcykler samma mönster som övriga cykler. Värdena för iPhone 4 avviker dock, troligtvis pga. en okänd störning i mätningen.

Figur 11 Exempel på exekverings-spikar för varje ny detaljnivå.

(22)

Figur 12 Exekveringstid för ritkommandon vid olika detaljnivåer (Bil+Älg)

Figur 13 Initial exekveringstid för ritkommandon vid olika detaljnivåer

(Bil+Älg)

(23)

20

6.1.2 Mätning av fps

Till skillnad från övriga detaljnivåer så mäts den första nivån (nivå 0) en extra gång. Detta första mätvärdet blir felaktigt lågt då fps-mätaren inte mäter korrekt under uppstarten av mätningen. Detta första värde har därför lagts åt sidan och ingår inte i snittet för nivå 0.

Som nämnts tidigare så visar det mest komplexa bildobjektet de tydligaste utfallen och värdena för denna bild presenteras i figur 14. Övriga bildobjekt visar liknande tendenser eller inga uttydbara tendenser alls. Sony-enheterna förblir mer eller mindre opåverkade utan håller en jämn fps genom samtliga nivåer. Övriga tenderar att tappa fps vid tilltagande detaljnivå varav iPhone5 visar den tydligaste förändringen.

Figur 14 FPS-mätning (Bil+Älg)

6.2 Analys och slutsatser

Figur 15 visar exkveringstiden i förhållande till antalet ritinstruktioner. Mätvärdena indikerar att vid användningen av bezierkurvor (detaljnivå 4) går exekveringstiden upp något då alla enheter utom iPhone5C med Chrome visar på en förhöjd exkveringstid, för denna enhet går tiden istället ned. Värdena kommer dock från mätningar på ett enstaka bildobjekt och mätvärdena har stora standardavvikelser som överlappar varandra.

Trenden förefaller vara att med ett växande antal kommandon så sjunker exkveringstiden per kommando. Man kan spekulera i att hårdvaran kan hantera ett större antal kommandon på ett mer ekonomiskt sätt.

(24)

Figur 15 Exekveringstid i förhållande till antal ritkommandon

I figur 16 visas fps i förhållande till det antal ritkommandon som respektive detaljnivå omfattar. Det går att utläsa att iOS-enheterna tydligt påverkas negativt vid användningen av bezierkurvor. De testade modellerna från Sony visar dock ej samma tendens. Mätningarna omfattar för få värden för att säkert dra slutsatsen att ersättningen av bezier-kurvor med linjer ger en generell fps-vinst. Mätresultaten indikerar också att de testade versionerna av Chrome är betydligt bättre på att hantera rendering av Canvas-objekt än motsvarande versioner av Safari.

Det avtagande tappet i fps som följer med ökningen av antal ritkommandon liknar de resultat som Sawicki & Chaber (2012) får i sin mätning av fps vid körning av 3D-objekt på en canvas. I denna undersökning jämför man värden från körningar i webbläsarna Firefox och Chrome. I likhet med resultaten i denna undersökning så ser man där en stor skillnad i prestanda hos de olika webbläsarna.

(25)

22

Figur 16 Fps i förhållande till antal ritkommandon

Sett till antalet tecken som respektive canvas-objekt omfattar i jämförelse med det ursprungliga SVG-objektet så minskar den datamängd som behöver föras över endast inledningsvis med små enkla bildobjekt. Tillämpningen i mätningen har dock inte omfattat några försök till komprimering och det ursprungliga SVG-objektet som jämförelsen görs mot är även det okomprimerat.

Mätmetoden med RequestAnimationFrame() är problematisk då den endast indirekt ger en mätning av resursanvändning. Webbläsaren har kontroll över rendering och fps kan komma att anpassas sig till faktorer som enhetens inställningar för batteribesparning. Funktionen kan dock ses som ett realistisk tillämpningsscenario då den på bred front rekommenderas för användning vid animationer i webbläsare.

Hypotesen kan anses bevisad. Fps går att hålla uppe genom att reducera detaljnivån. Dock krävs en viss nivå av komplexitet i bildobjektet innan vinsterna blir så betydande att insatsen lönar sig.

(26)

7 Avslutande diskussion

Vektorgrafik har en stor bredd av användningsområden och kan tillämpas istället för pixelgrafik i de flesta situationer där enklare grafik används. Exempelvis applikationer som omfattar statistiska presentationer (så som börsdata), spel, kartapplikationer etc.

Vektorgrafik är i grunden adaptivt genom sin egenskap att utan kvalitetsförlust kunna ritas ut i valfri upplösning. En stor bredd av olika displayer kan få anpassad grafik från samma bildkälla, vilket är särskilt fördelaktigt om man med en HTML5-applikation vänder sig till en stor bredd av användare.

En konkret åtgärd utifrån resultaten i denna undersökning är att användningen av bezierkurvor bör undvikas där så är möjligt. Att ersätta dessa med linjer behöver inte innebära någon betydande visuell förlust, särskilt inte om man applicerar användningen av rundade hörn. Överlag behöver inte heller reducering av detaljnivå innebära en förlust för användaren. Gauffuri (2012) pekar på att en för hög detaljnivå är en bidragande orsak till försämrad prestanda i kartapplikationer som använder sig av vektorgrafik. Det är inte bara onödigt att skicka och rendera komplett bilddata sett till prestandaförlusten, utan också för att höga detaljnivåer kan vara ett problem i sig vid olika inzoomningsgrader beroende på hur stor displayen är. Detta då det kan bli för mycket och för tät information för att användaren ska kunna dra nytta av den.

Sett till samhällsnytta så kan man tänka sig att användningen av adaptiv grafik bidra till att hårdvara kan användas längre. När kapaciteten hos de enheter som användarna innehar i längre utsträckning fortsätter att fungera med populära appar så minskar benägenheten att byta till en nyare modell. Det kan också vara en del i en mer ekonomisk användning av mobil bandbredd då anpassad grafik direkt kan placera sig närmare vad den mottagande enheten faktiskt har möjlighet att visa användaren. Detta istället för att skicka den fullständiga versionen som sedan skalas ned lokalt.

Att reducera detaljnivåer i vektorgrafik för att uppnå dessa fördelar kan dock medföra vissa risker. En alltför långtgående reducering skulle kunna resultera i att användarens tolkning av den bild som betraktas blir störd. Som minst kan detta påverka användbarhets- upplevelsen negativt. Användaren kan behöva titta en extra gång för att förstå hur bilden ska tolkas och upplever applikationen som krånglig. I värre fall skulle man kunna tänka sig att information blir direkt misstolkad utan möjlighet att upptäcka misstaget. Om exempelvis reduceringen av detaljnivån i ett bildobjekt som innehåller ett diagram genomförs på fel sätt så skulle hela innebörden av informationen förvanskas. Ett hörn tas bort och grafen får en ny lutning med en helt annan innebörd.

Att hålla uppe fps för webbapplikationer är ett rörligt mål, hårdvara får ständigt bättre kapacitet samtidigt som användarna förväntar sig att applikationer följer med utvecklingen och tar ny kapacitet i anspråk. Man kan dock spekulera i att möjligheterna att skapa plattformsobereonde applikationer genom html5 innebär att en större bredd av enheter med varierande kapacitet förväntar sig att kunna köra dessa applikationer. Adaptiv användning av grafik blir då en viktig del i lösningen för att kunna ta i beaktande så många användares förutsättningar som möjligt.

Det faktum att detta och andra experiment visat på stora skillnader i olika webbläsares prestanda när det kommer till att rendera Canvas pekar på att tekniken fortfarande är i sin

(27)

24

linda. Inom ramen för mätningarna i detta experiment förefaller Chrome än så länge ha kommit längre i utvecklingen än Safari.

7.1 Framtida arbete

Detta arbete har mätt på renderingen av olika detaljnivåer av en bild i sin helhet. Varje byggsteg har renderats från grunden utan någon användning av informationen i de tidigare nivåerna. Det skulle vara intressant att mäta på en mer sofistikerad metod som faktiskt bygger upp detaljrikedomen i bilden successivt med hjälp tidigare hämtad data och se hur detta påverkar fps. Det skulle också var intressant med fler mätningar som direkt jämför användningen av bezierkurvor jämfört med att ersätta dessa med enstaka linjer. Framförallt att då undersöka hur stora fps-vinster som finns att hämta och hur stor skillnad användarna egentligen upplever. Man skulle också kunna titta närmare på möjligheten till en algoritm som undviker att ersätta de bezierkurvor som ger de mest omfattande förändringarna av originalbilden. Överlag skulle det vara intressant att följa upp användarnas subjektiva uppfattning vid en tillämpning av adaptiv detaljnivå och försöka avgöra om det finns ett mer optimalt avvägningsområde mellan detaljnivå och fps.

(28)

Referenser

Arcidiacono, G (2009) Alcula.com. Tillgänglig på internet

http://www.alcula.com/calculators/statistics/standard-deviation/ [Använd april 9, 2015]

Boehm, W. & Müller, A. (1999) On de Casteljau’s algorithm. Computer Aided Geometric Design. 16 (7), s. 587–605.

Chang, Y. H., Chuang, T. R., & Wang, H. C. (2004) Adaptive Level-of-detail in SVG. SVG Open 2004: 3nd Annual Conference on Scalable Vector Graphics. Tillgänglig på Internet:

http://www.svgopen.org/2004/papers/AdaptiveLoD/

Claypool, M. & Claypool, K. (2009) Perspectives, Frame Rates and Resolutions: It’s All in the Game. Proceedings of the 4th International Conference on Foundations of Digital Games.

FDG ’09. New York, NY, USA, ACM. s. 42–49.

Corcoran, P., Mooney, P., Bertolotto, M. & Winstanley, A. (2011) View- and Scale-Based Progressive Transmission of Vector Data. Beniamino Murgante, Osvaldo Gervasi, Andrés Iglesias, David Taniar, et al. (eds.). Computational Science and Its Applications - ICCSA 2011. Berlin, Heidelberg, Springer Berlin Heidelberg. s. 51–62.

De Silva, R.N., Cheng, W., Ooi, W.T. & Zhao, S. (2010) Towards Understanding User Tolerance to Network Latency and Data Rate in Remote Viewing of Progressive Meshes.

Proceedings of the 20th International Workshop on Network and Operating Systems Support for Digital Audio and Video. NOSSDAV ’10. New York, NY, USA, ACM. s. 123–

128.

Flanagan, D. (2002) Javascript: The Definitive Guide. O'Reilley Media, Inc.

Gaffuri, J. (2012) Toward Web Mapping with Vector Data. Proceedings of the 7th International Conference GIScience. Columbus, OH, USA. Springer Berlin Heidelberg s.

87-101.

Han, H., Tao, V. & Wu, H. (2003) Progressive vector data transmission. Proceedings of the 6th AGILE, Lyon, France. s. 103–113.

He, G., Bai, B., Pan, Z. & Cheng, X. (2007) Accelerated Rendering of Vector Graphics on Mobile Devices. Julie A. Jacko (ed.). Human-Computer Interaction. Interaction Platforms and Techniques. Berlin, Heidelberg, Springer Berlin Heidelberg. s. 298–305.

Kee, D.E., Salowitz, L. & Chang, R. (2012) Comparing Interactive Web-Based Visualization Rendering Techniques. IEEE Conference on Information Visualization (InfoVis), 2012.

Tillgänglig på Internet: http://valt.cs.tufts.edu/pdf/kee2012comparing.pdf [Hämtad February 19, 2015].

Rajamony, R. & Elnozahy, M. (2001) Measuring client-perceived response times on the WWW. Proceedings of the 3rd conference on USENIX Symposium on Internet Technologies and Systems-Volume 3. USENIX Association. s. 16–16.

Sawicki, B. & Chaber, B. (2012) 3D mesh viewer using HTML5 technology. Przeglad Elektrotechniczny (Electrical Review), ISSN. s. 0033–2097.

(29)

26

Stackoverflow (2011) Stackoverflow. Tillgänglig på internet

http://stackoverflow.com/questions/8279729/calculate-fps-in-canvas-using- requestanimationframe [Hämtad februari 14, 2015]

Taivalsaari, A. & Mikkonen, T. (2011) The Web as an Application Platform: The Saga Continues. 2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA). August s. 170–174.

Wang, Q. & Cheng, L. (2004) A flexible awareness measurement and management architecture for adaptive applications. IEEE Global Telecommunications Conference, 2004. GLOBECOM ’04. November s. 2118–2122 Vol.4.

Wang, Y. & Meng, H. (2010) Managing multi-scale spatial data for mobile application. 2010 Seventh International Conference on Fuzzy Systems and Knowledge Discovery (FSKD).

August s. 2839–2843.

Wohlin, C., Runeson, P., Höst, M., Ohlsson, M.C., et al. (2012) Experimentation in Software Engineering. Berlin, Heidelberg, Springer Berlin Heidelberg.

(30)

Appendix A - generate_LOD.html

<html>

<head>

<style>

</style>

<!-‐-‐jQuery-‐-‐>

<!-‐-‐De Casteljaus Algotihm-‐-‐>

<!-‐-‐Dataformat canvas draw commands-‐-‐>

<!-‐-‐Slider for detail-‐level, FPS-‐counter-‐-‐>

<!-‐-‐Animation of object-‐-‐>

//Canvas-‐variabel var d;

var acanvas;

//Variabler vid konvertering av ritkommandon till CRI-‐format var onlylines = [];

var only_once = true;

var first_cycle = true;

var reduced_line_version='';

var drawcommands='';

var detail_level = 1;

var detail_level_changed = false;

var previous_was_lineto = false;

var test_counter = 0;

var test_results = '';

//Animation av bildobjekt var animation_width;

var animation_height;

var position_h;

var position_v;

var positive_direction = true;

//Förflyttning per frame var tx = 0;

var ty = 0;

var tnx = 0;

var tny = 0;

(31)

II

function initcanvas() {

acanvas = document.getElementById("CanvasBox");

if (acanvas.getContext) {

d = acanvas.getContext("2d");

d.canvas.width = (window.innerWidth -‐ 400);

animation_width = (window.innerWidth/4);

position_h = animation_width;

d.canvas.height = window.innerHeight;

animation_height = (window.innerHeight/4);

position_v = animation_height;

//d.translate(-‐200,-‐550);

//d.scale(2,2);

window.requestAnimationFrame(redraw);

} }

</script>

<!-‐-‐Inläsning av tillgängliga bildobjekt-‐-‐>

<!-‐-‐<script type="text/javascript" src="canvas_objects/moose_level1.js"></script>-‐-‐>

//***Val av bildobjekt som ska användas***

//var image = tennisball_img;

//var image = lemon_img;

//var image = moose_img;

var image = car_img;

//Current path-‐coordinates var cx;

var cy;

//Initiera animationsfunktion timeout();

//****Utritning av bild från dataformat****

function redraw() {

d.clearRect(0,0,700,700);

(32)

//Nivå 0 -‐ Halvering av antalet linjer från nivå 1 if(!first_cycle && detail_level == 0){

//Kör igenom lagrade ritkommandon eval(reduced_line_version);

//Skriv ut ritkommandon på skärmen if (only_once == true){

document.getElementById('array_output').innerHTML = "";

document.getElementById('array_output').innerHTML = 'Level 0:

'+reduced_line_version;

only_once = false;

} }

//Förändrad detaljnivå samt original bild else{

//Tömmer cachade ritkommandon drawcommands = '';

//För varje path i bilden

for (var i = 0; i < image.length; i++){

//Path-‐properties: Linewidth (lw) if (image[i].lw != null){

if(detail_level==1 && first_cycle){

onlylines.push('d.lineWidth = '+image[i].lw+';');

}

else{

d.lineWidth = image[i].lw;

drawcommands += 'd.lineWidth = '+image[i].lw+';';

} }

//Linesstyle (ls)

if (image[i].ls != null){

onlylines.push('d.lineStyle = '+image[i].ls+';');

}

else{

d.lineStyle = image[i].ls;

drawcommands += 'd.lineStyle = '+image[i].ls+';';

} }

//Fillstyle (fs)

(33)

IV

if (image[i].fs != null){

onlylines.push('d.fillStyle = "'+image[i].fs+'";');

}

else{

d.fillStyle = image[i].fs;

drawcommands += 'd.fillStyle = "'+image[i].fs+'";';

} }

//Strokestyle (ss)

if (image[i].ss != null){

onlylines.push('d.strokeStyle = "'+image[i].ss+'";');

}

else{

d.strokeStyle = image[i].ss;

drawcommands += 'd.strokeStyle = "'+image[i].ss+'";';

} }

//GlobalAlpha (ga)

if (image[i].ga != null){

onlylines.push('d.globalAlpha = '+image[i].ga+';');

}

else{

d.globalAlpha = image[i].ga;

drawcommands += 'd.globalAlpha = '+image[i].ga+';';

} }

//lineCap (lc)

if (image[i].lc != null){

if(detail_level==1){

onlylines.push('d.lineCap = "'+image[i].lc+'";');

}

else{

d.lineCap = image[i].lc;

drawcommands += 'd.lineCap = "'+image[i].lc+'";';

} }

//lineJoin (lj)