Emuleren van PDA software op groot scherm voor gebruik door slechtzienden

Emuleren van PDA software op groot scherm voor gebruik door slechtzienden Sarah Wuyts

Promotor: prof. dr. ir. Wilfried Philips Begeleider: Rik Bellens Masterproef ingediend tot het behalen van de academische graad van Master in de toegepaste informatica

Vakgroep Telecommunicatie en informatieverwerking Voorzitter: prof. dr. ir. Herwig Bruneel Faculteit Ingenieurswetenschappen Academiejaar 2007-2008

Emuleren van PDA software op groot scherm voor gebruik door slechtzienden Sarah Wuyts

Promotor: prof. dr. ir. Wilfried Philips Begeleider: Rik Bellens Masterproef ingediend tot het behalen van de academische graad van Master in de toegepaste informatica

Vakgroep Telecommunicatie en informatieverwerking Voorzitter: prof. dr. ir. Herwig Bruneel Faculteit Ingenieurswetenschappen Academiejaar 2007-2008

DANKWOORD Graag zou ik mijn begeleider, Rik Bellens, willen danken voor de goede begeleiding van deze masterproef. Hij zorgde voor de nodige documentatie, raadgevingen en volgde mijn vorderingen consequent op. Ook dank aan Jan Wuyts voor het beantwoorden van mijn technische vragen. Tenslotte wil ik Bert Vereycken en Kim Defreyne bedanken. Zij behoren tot de doelgroep van mijn applicatie en waren zo vriendelijk mijn programma uit te testen en hun mening daarover te formuleren.

De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.

2 juni 2008, Sarah Wuyts

i

OVERZICHT TITEL: Emuleren van PDA software op groot scherm voor gebruik door slechtzienden

AUTEUR: Sarah Wuyts

PROMOTOR: Prof. Dr. Ir. Wilfried Philips

BEGELEIDER: Rik Bellens Scriptie afgewerkt aan de Faculteit Ingenieurswetenschappen, Vakgroep Telecommunicatie en informatieverwerking, Universiteit Gent Scriptie voorgelegd aan de Faculteit Ingenieurswetenschappen (Universiteit Gent), voor het behalen van de academische graad van Master in de Toegepaste Informatie

SAMENVATTING In het kader van deze scriptie werd een gebruikersvriendelijker computerplatform voor slechtzienden gecreëerd. Het ontwerp van deze omgeving baseerde zich op mobiele besturingssystemen. Deze zijn speciaal ontworpen om een beperkte hoeveelheid informatie overzichtelijk op een klein scherm te tonen. Door het kleine scherm uit te vergroten naar een desktop monitor ontstond een besturingssysteem dat voor slechtzienden zichtbaar werd, zonder onoverzichtelijk te worden. Andere aanpassingen aan de applicatie moesten de omgeving nog toegankelijker maken voor mensen met een visuele handicap. Trefwoorden: Device Emulator, Visual Studio, C++, visueel gehandicapten

ii

INHOUDSTAFEL 1.

Inleiding ........................................................................................................................................................... 1

2.

Marktonderzoek ............................................................................................................................................ 3

3.

4.

2.1.

Vergrotingssoftware ............................................................................................................................ 3

2.2.

Spraaksyntheseprogramma's .......................................................................................................... 4

2.3.

Voorleessoftware .................................................................................................................................. 4

2.4.

Conclusie van het marktonderzoek ............................................................................................... 5

Device Emulator for Windows Mobile.................................................................................................. 6 3.1.

Algemeen.................................................................................................................................................. 6

3.2.

Source code ............................................................................................................................................. 8

3.3.

Uitvoeren applicatie............................................................................................................................. 9

Bespreking oplossing op technisch niveau ...................................................................................... 12 4.1.

Uitvergroten van de LCD display ................................................................................................. 12

4.1.1.

Rotatie aanpassen ..................................................................................................................... 14

4.1.2.

Methode 1: Zoom functie aanpassen ................................................................................. 15

4.1.3.

Methode 2: Framebuffer aanpassen .................................................................................. 17

4.1.4.

Optimalisatie code .................................................................................................................... 22

4.2.

Verdere uitbreidingen...................................................................................................................... 28

4.2.1.

Cursor vergroten ....................................................................................................................... 28

4.2.2.

Afsluiten ........................................................................................................................................ 28

4.2.3.

Vergrootglas ................................................................................................................................ 29

4.3.

Mogelijke uitbreidingen .................................................................................................................. 32

4.3.1.

Interpolatietechnieken ........................................................................................................... 32

4.3.2.

Uitbreiding naar 2 beeldschermen..................................................................................... 32

4.3.3.

Platform Builder ........................................................................................................................ 33 iii

5.

Testen van het eindproduct................................................................................................................... 34 5.1.

Algemeen............................................................................................................................................... 34

5.2.

Mening van een slechtziende ........................................................................................................ 35

6.

Besluit ............................................................................................................................................................ 37

7.

Bibliografie ................................................................................................................................................... 39

iv

AFKORTINGEN: CPU: Central Processing Unit CTRL-toets: Control-toets DC: Device Context DIB: Device Independent Bitmap DLL: Dynamic-Link Library GDI: Graphics Device Interface LCD: Liquid Crystal Display MFC: Microsoft Foundation Class OS: Operating System (Nl.: besturingssysteem) PC: Personal Computer TTS: Text-To-Speech UI: User Interface

v

1. INLEIDING In onze samenleving, waar de computer een belangrijke rol is gaan spelen, is het aantal visueel gehandicapten niet te verwaarlozen. In België alleen al wordt het aantal blinden en slechtzienden bij benadering geschat op een 150.000-tal. Wereldwijd zijn er volgens de Wereld Gezondheid Organisatie rond de 161 miljoen mensen met een visuele handicap. Voor deze mensen is het vaak moeilijk om met computers en standaard softwarepakketten te werken. Er zijn voor slechtzienden reeds verschillende hulpmiddelen ontwikkeld om de toegankelijkheid tot computers te verbeteren. Het grote nadeel van deze technieken is dat het vaak moeilijk wordt een overzicht over het volledige scherm te bewaren, wat tot gevolg heeft dat de gebruiker vaak lang moet zoeken naar de gewenste functionaliteiten. Het zou beter zijn moest er speciaal voor deze doelgroep een besturingssysteem ontworpen worden. Dit is echter economisch niet haalbaar en om die reden niet beschikbaar op de hedendaagse markt. In deze thesis wordt naar een alternatief gezocht. Het idee bestaat eruit gebruik te maken van besturingssystemen voor PDA’s, zoals bijvoorbeeld Windows Mobile of PalmOS. De hoeveelheid informatie die op een mobiel apparaat getoond kan worden is beperkt. De mobiele platformen zijn dan ook speciaal ontworpen om de beperkte hoeveelheid informatie op een overzichtelijke manier te tonen op het kleine scherm. Van deze eigenschap zou gebruik kunnen worden gemaakt om een overzichtelijk besturingssysteem voor slechtzienden te creëren, indien het besturingssysteem voor de handcomputer uitvergroot zou worden naar een groter desktop beeldscherm. Op die manier wordt de inhoud van het beeld sterk uitvergroot, maar kan er wel een overzicht over het volledige scherm bewaard worden. Ook vaak gebruikte softwarepakketten, zoals tekstverwerkers, rekenpakketten, webbrowsers... zijn speciaal ontworpen om op PDA’s gebruikt te worden en bieden uitvergroot dus ook een oplossing voor slechtzienden. Een besturingssysteem voor een mobiel platform is niet ontwikkeld om op een gewone PC uitgevoerd te worden. Om dit toch te doen, moet gebruik gemaakt worden van een emulator. Een emulator is software in staat om programma’s ontwikkeld voor een specifieke omgeving, in een andere omgeving uit te voeren. De emulator gebruikt in deze scriptie is de Device Emulator van Microsoft. Dit is een programma in staat om Windows Mobile op een desktopcomputer uit te voeren. Hierbij wordt het Windows Mobile 1

besturingssysteem in een klein venster op de PC getoond. Microsoft heeft zijn source code voor de Device Emulator beschikbaar gesteld voor ontwikkelaars. Het is de bedoeling in deze scriptie om, door de emulator code aan te passen, het emulatorvenster uit te vergroten naar een volledige desktop monitor. Het uiteindelijk doel van de thesis is het creëren van een computeromgeving die het werken met een computer voor mensen met een visuele handicap vergemakkelijkt. Naast de uitvergroting werden er nog enkele aanpassingen gedaan aan de emulator om het werken met de applicatie voor de doelgroep gebruiksvriendelijker te maken.

2

2. MARKTONDERZOEK Onder visueel gehandicapten worden mensen met verminderd zicht, kleurenblinden en blinden gerekend. In deze thesis wordt gezocht naar een software oplossing om het computergebruik toegankelijker te maken voor mensen met een verminderd zicht. Voor slechtzienden zijn er reeds verschillende hulpmiddelen ontwikkeld om de leesbaarheid van een computerscherm te verbeteren. Hier volgt een korte beschrijving en enkele voorbeelden van de meest gebruikte mogelijkheden.

2.1.

VERGROTINGSSOFTWARE

Vergrotingssoftware wordt gebruikt om het beeld van een desktopcomputer uit te vergroten. Daar waar de gebruiker focust op het scherm zal het beeld worden uitvergroot, zodat de leesbaarheid stijgt. De uitvergroting kan een soort vergrootglas zijn dat over het scherm wordt gesleept. Hier is de cursor vervangen door een venster met de uitvergroting (figuur 1a). Ook kan het hele beeld vervangen worden door een uitvergroting van het gebied waar de cursor geplaatst is of wordt de uitvergroting in een apart venster getoond zoals op figuur 1b. De meest gebruikte vergrotingsprogramma’s zijn Lunar en Zoomtext Magnifier. Deze programma’s zijn doorgaans geschikt voor slechtziende personen die slechts nood hebben aan een beperkte vergrotingsfactor en geen behoefte hebben aan een bijkomende spraakondersteuning.

F IGUU R 1 B - U I TVE R GR OTIN G BE E LDS CH ER M

F IGUU R 1 A - V IR TUE E L V ER GROOTGLAS

3

2.2.

SPRAAKSYNTHESEPROGRAMMA'S

Spraaksyntheseprogramma’s

produceren

softwarematig

gesproken

taal.

Een

spraaksynthesizer ontvangt informatie van het scherm in de vorm van letters, cijfers of leestekens en spreekt het vervolgens luidop uit. Er wordt ook vaak naar gerefereerd als TTS of text-to-speech systemen. Het doel van een TTS-systeem is menselijke spraak in verschillende talen zo goed mogelijk na te bootsen. Oorspronkelijk klonk de gegenereerde spraak erg robot-achtig, maar de hedendaagse gesynthetiseerde spraak is vaak moeilijk te onderscheiden van echte menselijke spraak. Eurovox en RealSpeak zijn voorbeelden van deze software. Op zich zijn deze programma’s niet voldoende om een “sprekende computer” voor slechtzienden te bekomen. Het programma moet aangestuurd worden door bijvoorbeeld een schermuitleesprogramma. Het kan ook in tekstverwerkers gebruikt worden om tijdens het intypen van tekst voor te lezen wat er op het scherm verschijnt en op die manier visueel gehandicapten te helpen bij het invoeren van tekst.

2.3.

VOORLEESSOFTWARE

Schermuitleesprogramma’s interpreteren de scherminhoud en zetten deze om in spraak. De inhoud van het scherm wordt dan luidop voorgelezen aan de gebruiker. Het gaat hierbij niet enkel over tekst, maar ook over namen en beschrijvingen van knoppen, menu’s, leestekens... die op het scherm getoond worden. Deze programma’s werken in combinatie met spraaksynthesesoftware. De populairste voorleesprogramma’s zijn JAWS voor Windows, gemaakt door de ‘Blind and Low Vision Group’ en ZoomText Reader, een onderdeel van de volledige ZoomText softwarepakket van Ai Squared. ZoomText combineert voorleessoftware met vergrotingssoftware en voegt daarbij nog verschillende hulpmiddelen om het slechtzienden zo eenvoudig mogelijk te maken met een computer te werken. Extra hulpmiddelen zijn bijvoorbeeld de mogelijkheid andere cursors te kiezen of de kleuren van het bureaublad naar wens aan te passen. Dit softwareproduct is momenteel marktleider op het gebied van hulptechnologieën voor visueel gehandicapten.

4

2.4.

CONCLUSIE VAN HET MARKTONDERZOEK

Het marktonderzoek toont dat er verschillende software mogelijkheden bestaan om visueel gehandicapten bij te staan in het gebruik van een computer. Het gaat echter steeds om hulpmiddelen die standaard computerprogramma’s voor hen toegankelijker moeten maken. Doch is het zelfs met die hulpmiddelen niet altijd vanzelfsprekend om standaard computerprogramma’s te hanteren, bijvoorbeeld omdat het moeilijk wordt een overzicht over het volledige beeld te bewaren. Het zou beter zijn als er een besturingssysteem met bijhorende programma’s ontworpen zou worden, rekening houdend met de beperkingen van deze mensen. Door het uitvergroten van de inhoud van het scherm vermindert de hoeveelheid informatie die op het scherm getoond kan worden. Door deze informatie op een overzichtelijke manier op het scherm te tonen, wat vaak ontbreekt bij vergrotingssoftware, zal het voor een slechtziende gemakkelijker zijn om met de computeromgeving te werken. Het overzichtelijk weergeven van een beperkte hoeveelheid informatie is een eigenschap die terug te vinden is in besturingssystemen en programma’s voor mobiele platformen en daarom ook de geschikte basis om een computeromgeving voor slechtzienden te creëren.

5

3. DEVICE EMULATOR FOR WINDOWS MOBILE 3.1.

ALGEMEEN

Voor de uitvoering van deze thesis werd gebruik gemaakt van Windows Mobile, een besturingssysteem voor mobiele toestellen. Dit mobiel platform diende echter op een desktopcomputer te werken, wat mogelijk gemaakt werd door een emulator. Een emulator is een computerprogramma waarmee het mogelijk is om programma’s ontwikkeld voor een specifieke omgeving in een andere omgeving uit te voeren. Het is software in staat om hardware te simuleren. Figuur 2 geeft een overzicht hoe een mobiel besturingssysteem op een gewone PC gebruikt wordt. Op een desktopcomputer dient een emulator voor een mobiel hardware platform geïnstalleerd te worden. Het mobiele besturingssysteem kan dan op zijn beurt in de vorm van een image file in de emulator geladen worden voor uitvoering. De uiteindelijke bedoeling van deze thesis was het beeld door de emulator in een klein venster op het scherm getoond, uit te vergroten naar een fullscreen beeld van een PC. Hiertoe diende niet het mobiele besturingssysteem aangepast worden, maar de hardware emulator zelf.

F IGUU R 2 - G E BR UIK E MU LATOR

6

De voor deze thesis gebruikte Device Emulator is een programma van Microsoft dat de gedragingen van een hardware platform voor Windows Mobile nabootst. Deze software levert een betrouwbare simulatie en ze wordt gebruikt als testomgeving voor applicaties voor mobiele toestellen. Mobiele applicaties kunnen in de gewenste omgeving worden ontwikkeld en kunnen vervolgens met behulp van de Device Emulator getest worden op een desktopcomputer. Op deze manier kan het ontwikkelen en testen van mobiele applicaties op vereenvoudigde wijze gebeuren. Figuur 3 toont een screenshot van de emulatie van een Windows Mobile pocket PC gebruik makende van de Device Emulator.

F IGUU R 3 - D E VI CE E MU LATOR

FOR

W IN DOWS M OBI LE

Microsoft heeft in 2006 de source code voor de eerste versie van de Device Emulator vrijgegeven. De code is vrijgegeven onder een shared-source licentie. Deze licentie houdt in dat de software gereproduceerd mag worden en dat afgeleide producten gemaakt mogen worden van de software, maar dat deze enkel mogen gedistribueerd worden als dit voor academische doeleinden is.

7

3.2.

SOURCE CODE

De Shared Source Device Emulator is een Visual Studio 2005 C++ project. Om het project te builden moet de solution file DeviceEmulator.sln geopend worden in Visual Studio 2005. Met het Build menu kan daar het volledige project gebuild worden. Tijdens het builden van de code worden DeviceEmulator.exe en DeviceEmulatorUI.dll gegenereerd. De uitvoering van de executable in combinatie met zijn resource DLL geeft een betrouwbare simulatie van het hardware platform van een mobiel toestel. Het is een uitgebreid project opgebouwd uit verschillende onderdelen. De mappenstructuur van het project geeft een overzicht van de structuur van het project. De bespreking van de broncode is dan ook gebaseerd op deze mappenstructuur. Het bedraagt hier 5 mappen, nl.  boards: Deze map bevat alle code die te maken heeft met de emulatie van het moederbord. Het bevat algemene code die gebruikt wordt door elk moederbord, alsook specifieke code voor één bepaald moederbord, namelijk de Samsung SMDK2410.  cpus: Hier bevindt zich de broncode voor de emulatie van de CPU van het moederbord.  features: In deze map zijn verschillende algemene bibliotheken terug te vinden die door de emulator gebruikt kunnen worden. Het gaat hier om de skin engine met als taak o.a. de XML descriptor files met de bijhorende bitmaps inladen, de hotspots van de skin beheren, enzovoort. Hiernaast dienen nog twee andere bibliotheken, nl. ZLib en LibPNG, gedownload te worden in deze map. Zlib is een datacompressie bibliotheek die in deze applicatie gebruikt wordt om schijfruimte uit te sparen. LibPNG is de officiële PNG bibliotheek, die hier gebruikt wordt door de skin engine om .png files te ondersteunen.  include: Deze map bevat de gemeenschappelijke include files.  satellite: De files in deze directory worden gebruikt om de satellite DLL te builden. Dit is een resource-only DLL die voor een bepaalde taal gelokaliseerd kan worden. Als een applicatie begint met de uitvoering, laadt MFC automatisch de resource file in die het meest aangewezen is voor een bepaalde omgeving. Bijvoorbeeld een applicatie met Engelse resources en twee satellite DLL’s, één met een Nederlandse en één met een Franse vertaling, wordt uitgevoerd. Indien dit op een Engels systeem gebeurt, zullen de Engelse resources gebruikt worden. Als het in een Franse omgeving wordt uitgevoerd, 8

zal het de Franse resources gebruiken. Hetzelfde geldt voor de Duitse vertaling op een Duits systeem. Bij de uitvoering van de Device Emulator dient er rekening gehouden te worden met de taalinstelling van het systeem waarop het wordt uitgevoerd. Hoe dit kan gebeuren wordt verder uitgelegd in paragraaf 3.3. waar de command line opties toegelicht worden.

3.3.

UITVOEREN APPLICATIE

Nadat de executable en de resource DLL gegenereerd zijn, kan de Device Emulator applicatie uitgevoerd worden. De Device Emulator op zich is slechts het hardware platform van een mobiel toestel. Om dit platform te testen moeten we een besturingssysteem inladen. Dit gebeurt d.m.v. OS boot loader images. De boot loader wordt gebruikt om een OS image in het geheugen te laden en dan over te gaan tot de OS startup routine, zodat bij het opstarten het besturingssysteem gevonden wordt door het hardware platform. Het bestandsformaat van de image files gebruikt in de Device Emulator is .bin of .nb0. Het Nb0 formaat is eenvoudigweg een byte-na-byte kopie van de data zoals deze moet verschijnen in het geheugen voor uitvoering. Het is de onbewerkte versie van een bin image file. De bestandsformaten zijn verschillend, maar uiteindelijk bevatten ze dezelfde informatie. Bij het opstarten van DeviceEmulator.exe via de command line, dient de naam van de image file met het besturingssysteem opgegeven te worden. Anders faalt de uitvoering, aangezien er geen besturingssysteem gevonden wordt. Figuur 3 toonde ons het resultaat van het uitvoeren van de Device Emulator met als besturingssysteem Windows Mobile voor een pocket pc. In bovenstaande uitleg worden geen extra opties ingesteld bij het opstarten. De emulator ondersteunt echter verschillende functies zoals schermresolutie aanpassen, nabootsen van een storage kaart... Om de standaard instellingen aan te passen moet dit als extra optie, naast de binfile, opgegeven worden in de command line. Verschillende standaard instellingen werden aangepast tijdens het uitvoeren van de thesis. De functies die aan bod zijn gekomen gedurende de uitvoering van deze thesis zullen hieronder kort toegelicht worden.

9

 /a: Het emulator venster zal steeds bovenaan getoond worden. Geen andere vensters kunnen boven het emulator venster geplaatst worden.  /language LangID: Er werd reeds vermeld dat er bij de uitvoering van de Device Emulator rekening gehouden moet worden met de taalinstelling van het systeem waarop het wordt uitgevoerd. Standaard veronderstelt de applicatie dat er op een Engelstalig systeem gewerkt wordt. De resource DLL van de applicatie wordt geplaatst in een map met naam ‘1033’, de taalcode voor Engels (United States). Bij het uitvoeren van de emulator op een U.S. systeem zal voor de resource DLL daar gezocht worden. Als men echter op een anderstalig systeem werkt, wordt voor het lokaliseren van de resource DLL gezocht naar de map met de taalcode van dat systeem. Voor een Nederlandstalig systeem bijvoorbeeld is dit ‘1043’. De uitvoering van de applicatie zal mislopen omdat de resource DLL van de Device Emulator niet gevonden zal worden. Om dit tegen te gaan kan deze optie opgegeven worden in de command line met de Engelse taalcode als LangID. Op die manier wordt aan de applicatie doorgegeven waar de DLL zich bevindt. Ook kan de naam van de map veranderd worden in de taalcode van het systeem zodat van de command line optie geen gebruik meer gemaakt dient te worden.  /memsize size: Hier kan de grootte van het geheugen ingesteld worden. De grootte wordt in megabytes opgegeven. De waarde moet tussen 64 en 256 liggen. Indien de RAM size niet groot genoeg is om alle applicaties uit te voeren, geeft Windows Mobile een “Storage memory is critically low” foutmelding na het opstarten. Bij het opstarten is het dus aan te raden de memory size te verhogen d.m.v deze command line optie.  /p: Deze optie laat toe gebruik te maken van de netwerk adapter voorzien in de emulator. Op deze manier kan er binnen de emulator gebruik gemaakt worden van het internet van de PC waarop de emulator wordt uitgevoerd. Hiertoe moet de correcte driver geïnstalleerd worden. Dit wordt verder toegelicht in paragraaf 5.1.  /rotate angle: De Device Emulator wordt standaard onder een rotatiehoek van 0° op het scherm getoond, d.i. in portretweergave. Indien het emulatorscherm gedraaid moet worden, kan dat over een hoek van 90°, 180° of 270°. In het besturingssysteem zelf kunnen de instellingen ook veranderd worden van de standaard portret weergave naar een landschap weergave.

10

 /sharedfolder directoryname: Door deze optie aan te zetten, wordt de directory opgegeven bij deze optie aan de Device Emulator gekoppeld als storage card. Op die manier kunnen bestanden tussen de emulator en de desktopcomputer uitgewisseld worden.  /skin filename: Op figuur 4 zien we dat er default geen skin getoond wordt door de emulator. De skinfile dient mee opgegeven worden in de command line d.m.v. deze optie. De skinfile is een xml-file gelinkt aan skin afbeeldingen. Als deze mee opgegeven worden krijgen we een emulator afgebeeld zoals getoond op figuur 3.  /video <width>xx: Naast de rotatiehoek van het scherm kan ook de schermgrootte en de kleurendiepte opgegeven worden. De schermgrootte is voor zowel breedte al hoogte begrensd tussen 64 en 800. Dit omwille van het feit dat de emulator framebuffer gelimiteerd is op 1Mb. De kleurendiepte geeft het aantal bits dat gebruikt wordt om de kleur van een pixel te coderen. In de emulator dient deze waarde 16, 24 of 32 te zijn. Bij het uitvergroten dient hiermee rekening gehouden te worden.  /z: Deze optie geeft de gebruiker de kans om het beeld van de emulator te vergroten. Dit gebeurt met een factor 2. Het venster en de volledige inhoud van het emulatorscherm zal met een factor 2 uitvergroot worden.

F IGUU R 4- ORI GI N AL E M U LATOR

11

4. BESPREKING OPLOSSING OP TECHNISCH NIVEAU 4.1.

UITVERGROTEN VAN DE LCD DISPLAY

Het uiteindelijke doel van de aanpassingen aan de Device Emulator code was het uitvergroten van de LCD display naar een volledig scherm, zodat het op een desktopcomputer zichtbaar werd voor slechtzienden. Bij het uitvergroten van het scherm werden twee verschillende richtingen gevolgd, die in de volgende secties toegelicht worden. De eerste manier van werken maakte gebruik van de reeds aanwezige zoom functie. Door de schaalfactor van deze functie te vergroten, werd het venster verder uitvergroot. Het doel hier was de correcte schaalfactor vinden. De andere richting die gevolgd werd, was het creëren van een grotere bitmap, deze op de correcte manier in te vullen op basis van de originele framebuffer en op het scherm tonen. Om het beoogde resultaat te bekomen diende slechts een deel van de bestaande code aanpast te worden, nl. daar waar het LCD-scherm gevormd en getoond werd. In volgende files en de bijhorende header files werden de uiteindelijke aanpassingen gedaan:  Config.cpp werd gebruikt om de EmulatorConfiguration class te implementeren. Deze klasse werd gebruikt om de informatie van de globale configuratie op te slaan. De globale configuratie kreeg bij initialisatie standaard waarden. Deze waarden konden bij de uitvoering van het programma via de command line aangepast worden. Bij de uitwerking van de masterproef werden sommige van deze standaardwaarden aangepast om tot een beter resultaat te komen.  Devices.cpp bevatte de code verantwoordelijk voor het implementeren van de SMDK2410 randapparatuur en de delen van het moederbord specifiek voor de emulator UI. Hier werd de bitmap gecreëerd die naar het scherm getoond moest worden. In de tweede methode voor de uitvergroting moesten de aanpassingen hier dus gebeuren.  In WinInterface.cpp bleek de Windows UI van de emulator getoond te worden. Het was de code verantwoordelijk voor het beheer van het Win32 window, het ontvangen van toetsaanslagen afkomstig van Windows, het verwerken van menu items en de communicatie met de skin engine. Deze code was belangrijk voor de volledige uitwerking van de masterproef. 12

In deze thesis speelde het beheer van het Win32 venster dan ook een belangrijke rol. Vooraleer de aanpassingen aan de Device Emulator uitgelegd worden, wordt hier kort geschetst hoe vensters onder Microsoft Windows georganiseerd zijn. Als een applicatie onder Windows wordt uitgevoerd, interageert de gebruiker met de applicatie via informatie die getoond wordt in vensters. Zo’n venster heeft twee grote onderdelen, nl. het frame en de inhoud, of de ‘view’, van het venster. De interactie van de gebruiker met het venster, zoals bijvoorbeeld het verplaatsen of het sluiten van het venster, wordt door Windows zelf geregeld. De inhoud van het venster wordt door de auteur van de applicatie georganiseerd.

F IGUU R 5 - V ERS CHI L : FR AME - VI E W V AN E E N V EN ST ER

Die twee componenten worden in het MFC framework door twee verschillende klassen gepresenteerd en georganiseerd. Een ‘frame-window’ klasse regelt de rand van het venster en een ‘view’ klasse regelt de getoonde inhoud van dat venster. Het ‘view venster’ is dus een onderdeel van het ‘frame venster’. Het frame venster zorgt voor een zichtbare rand rond de inhoud. Die rand heeft een titelbalk en standaard venster controles, zoals een controle menu, minimaliseer en maximaliseer knoppen en de mogelijkheid om de grootte van het venster aan te passen. De inhoud wordt getoond in de client area van het venster, dat volledig gevuld wordt door het view venster. Figuur 5 toont nog eens de relatie tussen het frame en de view van een venster. Het verschil tussen beiden zal in het vervolg van de thesis nog duidelijk aan bod komen. 13

4.1.1. ROTATIE AANPASSEN Eerst en vooral werd de standaard configuratie van de Device Emulator in config.cpp aangepast. Zoals reeds vermeld was de rotatie bij het opstarten ingesteld op 0° en dus in portret weergave. Aangezien het kleinere emulatorscherm naar een volledig beeldscherm uitvergroot diende te worden en een beeldscherm meestal liggend gepositioneerd is, werd de standaard instelling van de rotatiehoek op 90° ingesteld. Op die manier verscheen de emulator bij het opstarten in landschapsweergave op het scherm. Het resultaat hiervan wordt getoond in figuur 6. Het roteren van het emulator beeld diende bij verdere aanpassingen aan het programma in rekening gebracht te worden. De breedte en de hoogte van het beeld waren op die manier omgewisseld en dat was voor het invullen en het tonen van de emulator-bitmap niet onbelangrijk.

F IGUU R 6 - O RI GI NE LE

APP LIC ATI E IN LAN DS CH AP S WEER GAV E

14

4.1.2. M ETHODE 1: ZOOM FUNCTIE AANPASSEN De eerste richting die uitgegaan werd tijdens de uitvoering van de thesis maakte gebruik van de reeds aanwezige zoom functie. Door de zoom optie te activeren, werd het emulator venster verdubbeld in grootte. De code achter deze actie was terug te vinden in wininterface.cpp, de code verantwoordelijk voor o.a. het beheer van het Win32 window. De zoom-optie herschaalde de client area van het Win32 window en vergrootte het originele beeld om deze client area te vullen. Het besturingssysteem dat getoond werd in het venster was zich niet bewust van deze aanpassing, aangezien elk pixel van het besturingssysteem eenvoudigweg van 1 pixel tot 4 pixels uitgebreid werd. Het idee was deze schaalfactor zo aan te passen dat het kleine scherm i.p.v. verdubbeld, over een volledig scherm werd uitvergroot. Om een venster met afmetingen van een volledig scherm te creëren, dienden de afmetingen van het beeldscherm gekend te zijn. Om deze

afmetingen

te

bekomen

werd

gebruik

gemaakt

van

de

Windows

GDI

EnumDisplaySettings functie. Deze functie is in staat om informatie over het gebruikte display device, zoals bijvoorbeeld frequentie of afmeting te bekomen. Bij oproep van de functie werd die informatie in een DEVMODE data structuur opgeslagen. De gewenste informatie, hier breedte en hoogte van het beeldscherm, kon vervolgens uit deze structuur gehaald worden. Op basis van die informatie werd de schaalfactor berekend om een zo groot mogelijk venster te bekomen. Deze schaalfactor diende in horizontale en verticale richting dezelfde te zijn om de verhouding van het originele beeld te behouden. Indien deze verhouding niet werd behouden, waren sommige applicaties binnen Windows Mobile niet meer volledig zichtbaar. Als de originele verhouding van het venster behouden bleef door in beide richtingen dezelfde schaalfactor te gebruiken, was het echter op veel beeldschermen niet mogelijk om een volledige scherm te vullen met het venster van de emulator. Figuur 7 toont het effect van deze werkwijze. Het was ongewenst dat het besturingssysteem van de PC nog gedeeltelijk te zien was. Ook viel onderaan het beeldscherm een deel van het emulator venster weg. Dit werd veroorzaakt door de titelbalk die bovenaan het venster getoond werd. Het beeld dat in 15

figuur 7 getoond wordt, was niet het gewenste “fullscreen” resultaat. Gebruik makend van de zoom functie kon dat resultaat niet behaald worden en werd er naar een andere werkwijze gezocht.

F IGUU R 7 - U I TVE RGR OTIN G D . M . V . Z OOM - FU NC TI E

16

4.1.3. M ETHODE 2: F RAMEBUFFER AANPASSEN Vorige werkwijze bleek onvoldoende. Het was namelijk de bedoeling een ‘fullscreen’ uitvergroting te creëren. Het deel van het scherm dat niet bedekt werd door uitvergroting van het emulatorbeeld moest opgevuld worden, zodat de onderliggende vensters niet meer zichtbaar waren. Ook de titelbalk bovenaan het venster, waardoor een deel van het emulatorbeeld van het scherm viel, diende te verdwijnen. Voor de nieuwe implementatie werd de originele code opnieuw hersteld, op de rotatie na. Er werd een nieuwe file, “fullscreen.cpp” aangemaakt om de nieuwe functies te implementeren. Op de gepaste plaatsen werden deze nieuwe functies in de originele code opgeroepen. Aangezien er van de zoom-functie geen gebruik meer gemaakt kon worden, moest op een totaal andere manier te werk gegaan worden. Door de zoom-functie te gebruiken, gebeurde er een venster manipulatie die de grootte van het venster verdubbelde. De inhoud van het venster werd automatisch aangepast op basis van de venstergrootte. Nu was het de bedoeling het venster de afmetingen van het beeldscherm te geven en de inhoud van het venster zelf aan te passen. Die inhoud moest een uitvergroting van het originele emulatorbeeld worden met behoud van de originele verhouding, maar deze moest in het midden van het scherm gepositioneerd zijn. De delen van het venster die niet bedekt werden door de emulatorbeeld dienden zwart gelaten te worden, zoals op figuur 8 getoond wordt.

F IGUU R 8 - B E TR ACH TE R ES U LTAAT

17

Aangezien een fullscreen beeld gecreëerd moest worden, was de titelbalk van het venster ongewenst. Om deze te verwijderen werd in de window klasse de vensterstijl aangepast. De window style optie liet toe om te bepalen welke onderdelen er aanwezig moesten zijn in de window frame. Er kon o.a. bepaald worden of het formaat van het venster gewijzigd mocht worden of er een window menu aanwezig moest zijn in de titelbalk, enzovoort. Nu diende de titelbalk en de window border volledig verwijderd te worden. Dit kon gedaan worden door als vensterstijl ‘pop-up’ te kiezen. Deze stijl had de eigenschap noch een rand, noch een titelbalk te bezitten. Bij de creatie van het venster van de emulator applicatie kon dan deze window style opgegeven worden en zorgde voor een venster dat verder uitgebreid kon worden naar het gewenste fullscreen venster. De omkadering van het venster was dan in orde. Daarna werd er gekeken naar een manier op de inhoud van het venster aan te passen. Om uit te leggen hoe de view van het venster werd aangepast, word hier eerst geschetst hoe het besturingssysteem in de oorspronkelijke emulator getoond werd in het venster. Alle display updates werden zo in Windows Mobile geïmplementeerd dat het de data rechtstreeks in een framebuffer schreef. Een framebuffer is een stuk geheugen op de videokaart. Dit geheugen bevat het beeld dat op het beeldscherm getoond moet worden. Het beeldscherm spreekt dit stuk geheugen rechtstreeks aan zodat een update meteen op het scherm getoond wordt, zonder dat de computer het eerst nog moet verwerken. Nadat de data in de geëmuleerde framebuffer geladen was, kopieerde de applicatie deze data in een DIB of device-independent bitmap. Dit is een formaat om bitmaps te definiëren in verschillende kleurresoluties die uitwisselbaar zijn tussen verschillende toestellen en applicaties. Indien de bitmap op het scherm niet meer up to date was, werd een functie getriggerd die de nieuw gekopieerde bitmap in de client area van het venster tekende. Om een invulling van het venster te verkrijgen zoals op figuur 8 werd de kopie van de framebuffer naar de bitmap aangepast. De grootte van de bitmap werd ingesteld op de grootte van het volledige beeldscherm, rekening houdend met het aantal bytes dat per pixel bijgehouden werd. Ook bij het kopiëren van de framebuffer in de bitmap diende dit in rekening gebracht te worden. Het aantal bytes dat per pixel werd bijgehouden was variabel in de applicatie. Deze kon ingesteld worden op 1, 2 of 3 bytes. Bij het overbrengen van het 18

beeld naar de bitmap was het dan ook belangrijk om per pixel de juiste hoeveelheid bytes te kopiëren, zodat de juiste pixelwaarde behouden bleef. Voor de vergroting van het emulatorbeeld binnen de bitmap was nog steeds de schaalfactor van de vorige werkwijze nodig. Op basis van de verhouding tussen de originele afmeting van het emulatorbeeld en de afmeting van het beeldscherm werd een zo groot mogelijke schaalfactor berekend waarbij niets van de uitvergroting van het emulatorbeeld van het beeldscherm viel. Op zijn beurt werd er gebaseerd op deze schaalfactor een rij van gehele getallen gecreëerd die gebruikt zou worden bij het uitvergroten. De gehele getallen gaven het aantal aan met welke elke pixel in de originele framebuffer in horizontale en verticale richting vermeerderd dienden te worden om de grote bitmap op te vullen. Ook werd de afstand berekend waarmee het originele emulatorbeeld opgeschoven diende te worden om in het midden van het beeldscherm geplaatst te worden. Deze shift-waarde kon berekend worden op basis van het volledige beeldscherm en het emulatorbeeld vergroot met de schaalfactor.

F IGUU R 9 - K OPI E

FR AM E BU FFER N AAR BI TM AP

Voordat een framebuffer in een bitmap gekopieerd werd, werd deze in het geheugen gestockeerd. De laatst gestockeerde buffer werd telkens gebruikt om te vergelijken met een nieuwe framebuffer. Indien één pixelwaarde in de nieuwe framebuffer verschilde van de pixelwaarde in de laatst gekopieerde buffer, werd een kopie van de nieuwe framebuffer getriggerd. Deze werkwijze werd in de originele implementatie van de emulator ook gebruikt. 19

Bij de initialisatie van de bitmap werden alle pixelwaarden van de bitmap op 0 gezet. Dit kwam overeen met een volledig zwart beeld. Het kopiëren van de pixelwaarden van de framebuffer in de bitmap werd kolom per kolom uitgevoerd en startte in de rechterbovenhoek van het beeld, zoals in figuur 9 aangegeven is. Dit was noodzakelijk omdat we de default rotatie van de emulator 90° hadden gedraaid en de bitmap dus ook gedraaid werd. Op figuur 9 wordt onderstaande uitleg geïllustreerd. Vóór het kopiëren van de pixelwaarden van de framebuffer in de grote bitmap werd de bitmap-pointer gepositioneerd op de kolom met als afstand van de rechterzijde van het beeld, de op voorhand berekende shift-waarde om het emulatorbeeld in het midden van het beeld te positioneren. Door het deel rechts van de pointer op zijn zwarte beginwaarde te laten staan, zorgde dit voor de gewenste zwarte opvulling naast het emulatorbeeld. Kolom per kolom werden de pixels van de originele framebuffer op basis van de op voorhand berekende rij met schaalfactoren, vermeerderd in de grotere bitmap. De rij met schaalfactoren werd per kolom gebruikt om aan te geven hoeveel keer een bepaalde pixelwaarde in verticale richting gedupliceerd moest worden. Per rij werd ook naar de schaalfactoren gekeken om ook in horizontale richting de pixelwaarden met het correcte aantal uit te breiden. Als alle pixels uit de framebuffer gekopieerd waren, bleef aan de linkerzijde van de bitmap nog een deel op de geïnitialiseerde waarde staan. Deze afstand was gelijk aan het zwarte gedeelte

F IGUU R 10 - R E SU LTAAT N A

20

HER TEK E NE N BI TM AP

aan de rechterzijde. Op die manier stond het emulatorbeeld in het midden van het volledige scherm gepositioneerd. Het resultaat van deze bewerkingen wordt getoond in figuur 10. Het beeld werd nu wel correct ingevuld, maar de muis actie afhandelingen waren nog niet voorzien op het anders ingevulde beeld. De muiscoördinaten waren nog steeds ingesteld op een klein emulatorvenster. In de oorspronkelijke emulator werd bij een muis actie eerst nagegaan of de coördinaten binnen het emulatorvenster vielen. Indien dit het geval was, kon er gekeken worden naar een verdere afhandeling van de muis acties. Het nieuwe emulatorbeeld waar in geklikt kon worden (figuur 10), was een uitvergroting van het oorspronkelijke emulatorbeeld (figuur 6). De coödinaten die in de zwarte delen naast het emulatorbeeld vielen, mochten niet als deel van het emulatorvenster gerekend worden. De oorspronkelijke functie die naging of een coördinaat deel uitmaakte van het emulatorvenster moest aangepast worden zodat in het hele venster geklikt kon worden, behalve in die zwarte randen. Nu moesten de coördinaten van het grote venster nog gekoppeld worden aan de coördinaten van het kleine venster. Als het emulatorbeeld ingezoomd werd met de zoom2xfunctie werden de muiscoördinaten van het klikken in het grote venster reeds teruggekoppeld naar de coördinaten van het kleine venster. Van deze functie kon gebruik gemaakt worden in het gecreëerde ‘fullscreen’ venster. Hier werd dan echter geen gebruik gemaakt van een schaalfactor 2, maar van de bij het vergroten berekende schaalfactor. In de breedte werd ook rekening gehouden met de afstand waarmee het venster opgeschoven is om in het midden van het beeld gepositioneerd te staan. Op die manier werd van de reeds bestaande functies gebruik gemaakt om de muiscoördinaten in orde te brengen voor het nieuwe venster.

21

4.1.4. OPTIMALISATIE CODE Na het creëren van de uitvergroting van het beeld met de juiste muis actie afhandeling, bleek de applicatie nog niet optimaal. Bij het gebruik van tekstverwerkers binnen Windows Mobile bleek bij het intypen van tekst in de programma’s niet helemaal correct te verlopen. Letters die ingetypt werden, werden meerdere malen op het scherm getoond. De oorzaak hiervoor was onbekend, tot het CPU gebruik van de applicatie nagekeken werd. Toen werd ontdekt dat applicaties met een knipperende cursor meer CPU verbruikten dan verwacht. Bij andere applicaties waren de CPU levels gelijkwaardig aan de originele CPU levels. Het feit dat het beeld constant geüpdatet moest worden om de knipperende cursor weer te geven, had een negatief effect op de processor performantie van de applicatie. Om dit effect tegen te gaan werd eerst de functie gebruikt bij de kopie van framebuffer naar bitmap aangepast. In de eerste implementatie werd op dat moment steeds de volledige framebuffer bijgewerkt, ook als slecht een beperkt aantal pixels veranderd was. Bij het kopiëren van de laatst ontvangen framebuffer in het geheugen werd pixel per pixel vergeleken of er verandering optrad in deze framebuffer t.o.v. van de laatst getoonde framebuffer. Indien dit het geval was voor 1 of meerdere pixels werd een update getriggerd. Ter verbetering van de performantie werd een update array gecreëerd waarbij veranderde pixels in aangegeven werden Op deze manier ontstond voor elke framebuffer een update array die aangaf welke pixels juist veranderd waren t.o.v. de vorige framebuffer. Bij het kopiëren van de framebuffer naar de bitmap zelf werd dan gebruik gemaakt van de update array om na te gaan welke pixels gekopïeerd moesten worden. Deze manier van werken gaf nog geen verbeterde performantie, maar de code werd toch aangepast om ze leesbaarder te maken in het uiteindelijke resultaat. In de versie werd de vergelijking tussen de vorige en de nieuwe framebuffer uitgevoerd tijdens het kopiëren in de bitmap zelf. Het kopiëren van een pixel gebeurde echter enkel nog als de pixelwaarde in de framebuffer niet overeenkwam met de pixelwaarde in de bitmap. Op deze manier werden enkel de veranderde pixels in de framebuffer geschreven. Opnieuw leverde de aanpassing geen verbetering op.

22

Het gebruik van een framebuffer vereenvoudigde de werking van de emulator, maar het het vermoeden was dat het tonen van de inhoud van de framebuffer op het beeldscherm ook invloed had op de performantie van de applicatie. Om hier een optimalisatie op uit te voeren, moest verder bestudeerd worden hoe het tekenen in Win32 applicaties juist in zijn werk gaat. Vensters en rectangles Een venster of “window” is een fundamenteel onderdeel van Win32 applicaties. Via vensters wordt informatie uitgewisseld tussen de applicatie en de gebruiker. In paragraaf 4.1 werd reeds het verschil uitgelegd tussen de frame van een venster en de inhoud ervan. Het venster zelf wordt door het OS beheerd, de inhoud van het venster is voor de applicatie toegankelijk via een window handle. Het deel van het venster waar die inhoud getoond wordt, wordt de “client area” genoemd en wordt meestal als een rechthoek voorgesteld. Binnen Windows GDI is er een rectangle structuur voorhanden. Deze RECT structuur bevat coördinaten van de vier hoeken van een rechthoek en definieert dus de breedte, de hoogte en de positie van een rechthoek. De coördinaten van de rechthoek die de client area omvat, kan uit het venster gehaald worden door gebruik te maken van de GetClientRect() functie. Device Context Een belangrijk onderdeel van het tekenen in Win32 applicaties is de Device Context (DC). Het levert een basis voor het tonen van informatie op verschillende soorten displays. Door gebruik te maken van een device context worden de details van een bepaalde display voor de ontwikkelaar van een applicatie verborgen. Het weergeven van informatie op een beeldscherm, op een printer of in een bitmap in het geheugen kan op eenzelfde manier gebeuren. De DC zorgt dus voor een laag van abstractie bij het tonen van afbeeldingen op een bepaalde ‘display’ en vergemakkelijkt het ontwikkelen van grafische objecten in Windows. Het gebied waar op getekend kan worden, wordt bepaald door het type DC. Er bestaan vier verschillende DC’s en het is belangrijk het onderscheid tussen de verschillende mogelijkheden te weten zodat voor elk specifiek doel de juiste device context gebruikt kan worden. De vier types die bestaan zijn:  Client DC: Een client DC wordt geassocieerd met een bepaald venster. Het geeft de ontwikkelaar de toegang tot de client area van het venster. 23

 Window DC: Een Window DC wordt ook met een bepaald venster geassocieerd, maar geeft de ontwikkelaar toegang tot elk deel van het venster. Hier worden dus ook de rand en de titelbalk bijgerekend.  Memory DC: Dit soort DC wordt niet met een venster geassocieerd en bestaat enkel in het geheugen. Deze device context kan een door de gebruiker gedefineerde bitmap bevatten. Van deze DC werd gebruik gemaakt bij het creëren van de bitmap op basis van een framebuffer.  General Device DC: Alle andere toestellen waarbij het mogelijk is een DC van te bekomen maken gebruik van de general device DC. Het gaat dan bijvoorbeeld over een printer of een volledig beeldscherm. Het is belangrijk een DC vrij geven na gebruik. Elk van de vier DC-types heeft zijn eigen release-methode en het is belangrijk voor elk type de correcte methode te gebruiken. Update Region Een belangrijk onderdeel van een venster is zijn update gebied. Het update gebied geeft aan welke delen van een venster bijgewerkt moeten worden. De oorzaak kan bijvoorbeeld zijn dat een venster is herschaald, dat een ander venster bovenop het venster geplaatst is geweest en terug verwijderd of een applicatie kan zelf een update van het beeld afdwingen. Om de performantie van een applicatie te verbeteren kan voor het tonen van nieuwe informatie in een venster het tekenen van die informatie beperkt worden tot het update gebied. Een applicatie kan zelf het gebied dat een update nodig heeft bewerken. InvalidateRect() en InvalidateRgn() zijn voorbeelden van functies die hiervoor gebruikt kunnen worden. Deze functies voegen respectievelijk een rectangle of een region toe aan een update gebied van een venster. WM_PAINT message Er werd reeds vermeld dat de view van een venster door de ontwikkelaar beheerd kon worden. Het invullen van de view gebeurt als er een WM_PAINT bericht ontvangen wordt. Een WM_PAINT bericht wordt gegenereerd als het update gebied voor een venster niet leeg is. Door gebruik te maken van de InvalidateRect() of InvalidateRgn() functies, wordt zo’n bericht gegenereerd. De rectangle die daarbij opgegeven wordt, is het gebied dat een update nodig heeft. Als zo’n bericht gegenereerd wordt, wordt een functie die instaat voor 24

het hertekenen van de opgegeven rectangle opgeroepen. Deze functie wordt door de ontwikkelaar zelf geïmplementeerd. Een groot risico bij het bijwerken van het beeld via deze berichten is dat het update gebied niet goed benut wordt. Als het update gebied een deel van het beeld dat een update nodig heeft mist, zal dat deel nooit bijgewerkt worden. Als er echter een te groot update gebied gekozen wordt, zal dit een negatieve invloed hebben op de performantie van de applicatie. Het is dus belangrijk dat de afhandeling van de WM_PAINT berichten zo efficiënt mogelijk gebeurd. Als een bepaald venster bijgewerkt moet worden na het ontvangen van een WM_PAINT bericht, wordt het venster voorbereid op het bijwerken door gebruik te maken van de BeginPaint() functie. Het voorbereiden gebeurt door een client DC te creëren met een gebied dat gelijk is aan het update gebied van het venster. Vervolgens wordt het update gebied gereset, zodat de applicatie weet dat er aan dat gebied gewerkt wordt en dat er geen verdere berichten gegenereerd zullen worden om het gebied bij te werken. De functie initialiseert ook een PAINTSTRUCT structuur. Deze structuur bevat informatie over het bijwerken van het venster. Het bevat o.a. een RECT structuur die de coördinaten geeft van het gebied dat bijgewerkt moet worden. Eenmaal het venster klaar is om hertekend te worden, kunnen functies opgeroepen worden om bijvoorbeeld een bitmap op het scherm te tonen. Functies die hiertoe gebruikt kunnen worden zijn BitBlt() en StretchBlt(). BitBlt() koppelt een memoryDC, die een user defined bitmap bevat, met de client DC gecreëerd door een BeginPaint()-oproep. Dat heeft tot gevolg dat de bitmap op het scherm getekend wordt. Omdat een oproep van BeginPaint() telkens een nieuwe client DC genereert, dient deze na gebruik ook weer verwijderd te worden. Daarom is het belangrijk dat na het bijwerken van het venster een EndPaint() functie opgeroepen wordt. Aanpassingen aan Device Emulator Na onderzoek van hoe het updaten van een venster in zijn werk ging en dan specifiek voor de Device Emulator applicatie, kon in de oorspronkelijke code gekeken worden naar een optimalisatie voor het updaten van een venster.

25

Zoals reeds vermeld, werd in de functie waar de framebuffer gekopieerd werd naar een bitmap eerst een kopie genomen van de framebuffer en deze kopie werd gebruikt om te kopiëren in een bitmap. Telkens als er iets veranderd was in een nieuwe framebuffer t.o.v. de laatst genomen kopie van de framebuffer, werd een vlag op true gezet die een kopie van het veranderde deel naar de bitmap triggerde. Diezelfde vlag werd ook gebruikt om een repaint van het venster te triggeren. Als er iets veranderde in de framebuffer, werd dit op het scherm ook aangepast. Het aanpassen gebeurde door telkens als de vlag op true stond een WM_PAINT bericht te genereren. In deze applicatie werd daarvoor de InvalidateRect() gebruikt. De rectangle die daarbij opgegeven werd, was telkens van de volledige client area. Bij applicaties met een blinkende cursor werd telkens als de cursor veranderde een update voor het volledige scherm getriggerd. Daar zat dus de negatieve invloed op de performantie. In de code werd 12 keer per seconde het frame uit de buffer vergeleken en bij verandering naar het scherm geschreven. In de originele applicatie ging dat over een update van een rectangle met beperkte afmeting. Door de aanpassingen naar een volledig scherm, moest echter telkens een groot oppervlakte geüpdatet worden.

F IGUU R 11 - BEP ALE N V AN H ET

UP DATE GE BI E D

Om dit te verbeteren werd een nieuwe RECT structuur gecreëerd. In deze structuur werden de coördinaten bijgehouden van een rechthoek die het gebied omvatte waar de veranderingen in de nieuwe bitmap zich bevonden. Het gebied dat de rectangle omvatte was een zo klein mogelijke rechthoek die het volledige bij te werken gebied van de op het scherm te tonen bitmap omvatte. Voor elk pixel dat veranderde, werd nagegaan of deze zich binnen de coördinaten van de rechthoek bevond. Indien deze erbuiten lag, werden de 26

coördinaten van de rechthoek zo aangepast dat het pixel er wel binnenviel, maar op een zodanige manier dat er geen overbodige pixels in het update gebied werden meegerekend. De positie van elke veranderde pixel in de bitmap werd op die manier nagegaan om het volledige update gebied te vinden. Het verschil van het originele update gebied en het update gebied in de geoptimaliseerde implementatie is te zien in figuur 11. Stel dat de donkergrijs gekleurde pixels de veranderde pixels zijn, dan wordt in de originele implementatie een volledige bitmap hertekend bij een update, terwijl met in de nieuwe implementatie het update gebied een stuk kleiner is. Door gebruik te maken van deze nieuw gecreëerde rectangle in de InvalidateRect() functie, kon een WM_PAINT message gegenereerd worden enkel voor het gebied waarbinnen iets veranderd was en niet meer voor het volledige venster. Belangrijk was het in de nieuwe implementatie echter rekening te houden met het feit dat de nieuw gecreëerde bitmap gedraaid was t.o.v. de originele implementatie, aangezien bij het begin van de uitwerking de rotatie van het scherm aangepast werd. Bij het opgeven van het update gebied aan de BitBlt() functie werden de coördinaten aangepast aan een gedraaid venster. Op die manier werd het correcte deel van het venster bijgewerkt. Bij de applicaties met een blinkende cursor daalde op deze manier het CPU gebruik terug sterk, waardoor ingetypte karakters opnieuw slechts één maal op het scherm getoond werden, zoals in de originele applicatie.

27

4.2.

VERDERE UITBREIDINGEN

4.2.1. CURSOR VERGROTEN Een nadeel van de implementatie was nog de kleine standaard cursor die niet zichtbaar was voor slechtzienden. Het beeld was wel uitvergroot, maar de cursor had nog steeds hetzelfde formaat. Aan elk venster, dus ook het emulatorvenster, werd een ‘window class’ structuur gekoppeld. Deze structuur bevatte informatie zoals de achtergrond kleur van het venster, het icoon dat gebruikt moest worden in de titelbalk, hoeveel geheugen er voorzien moest worden voor het venster... Daarnaast kon via deze structuur de cursor ingesteld worden. In de originele implementatie werd de cursor op een standaard cursor gezet met de LoadCursor() functie. Daar kon gekozen worden uit verschillende standaard cursors. Het was echter de bedoeling een grotere cursor te tonen. Als niet uit de standaard cursors gekozen werd, kon gebruik gemaakt worden van de LoadCursorFromFile() functie. Daarbij moest een .cur-file opgegeven worden, die de gewenste cursor bevatte. Op het internet waren er vele .cur-files voor slechtzienden terug te vinden. In Visual Studio kon ook zelf een cursor aangemaakt worden. Uiteindelijk werd gekozen voor de cursor te zien in figuur 12.

F IGUU R 12 - CUR S OR

4.2.2. AFSLUITEN Op figuur 10 zien we bovenaan nog een menubalk staan. De reden waarom de menubalk niet verwijderd werd, was dat het mogelijk moest blijven de applicatie af te sluiten. Aangezien het om een fullscreen venster ging, was de enige manier om af te sluiten via deze menubalk. Nu is de menubalk te klein voor een slechtziende en dus niet bruikbaar om af te sluiten. Het idee om de applicatie op een andere manier te beëindigen bestond eruit een combinatie van een toets met een muisklik te gebruiken.

28

Om dit te realiseren, moest de muis actie afhandeling aangepast worden. Dit houdt de acties in die ondernomen worden als er met de muis een bepaalde handeling gedaan wordt. Als bijvoorbeeld de linkermuistoets wordt ingedrukt, zal er een WM_LBUTTONDOWN message gegenereerd worden. In de code wordt voorzien welke acties er ondernomen moeten worden bij het ontvangen van dit bericht, zoals ook bij de WM_PAINT message het geval was. In de originele applicatie werd de rechtermuisknop niet gebruikt. In combinatie met de CTRL-toets kon dat gebruikt worden om de applicatie af te sluiten. Een berichtafhandeling na een rechtermuisklik werd bij voorzien in de nieuwe implementatie. Als er zo een WM_RBUTTONDOWN bericht in de applicatie binnenkwam, werd gekeken of ook de CTRLtoets ingedrukt was. Indien dit het geval was, werd het programma afgesloten. Op deze manier moest de menubalk bovenaan het venster niet meer gebruikt worden door een slechtziende en kon de applicatie ook door hen zelf beëindigd worden.

4.2.3. VERGROOTGLAS Het tot nu toe besproken resultaat was reeds een sterke uitvergroting van het originele emulatorbeeld. Op een gemiddeld beeldscherm werd het beeld toch met ongeveer een factor 3 à 4 uitvergroot. Voor veel slechtzienden is dat vaak nog niet sterk genoeg uitvergroot. Meestal is er voor visueel gehandicapten minstens een factor 6 of meer nodig om het scherm behoorlijk te kunnen zien. Om die reden werd er nog een extra optie in de applicatie voorzien, namelijk een vergrootglas. Dat idee kwam voortgevloeid uit het marktonderzoek. Eén van de reeds bestaande mogelijkheden voor slechtzienden was een vergrootglas dat over het scherm geschoven kon worden en dat het beeld daar nog verder uit vergrootte. Deze extra uitvergroting werd in de applicatie zelf voorzien. Eerst en vooral moest een extra venster gecreëerd worden bij een bepaalde actie. Als CTRL+rechtermuisknop ingedrukt werd, werd de applicatie afgesloten. Enkel de rechtermuisknop indrukken creëerde een nieuw venster met als oppervlakte een vierde van de oppervlakte van het volledige scherm. Het venster werd rond de muiscursor gecreëerd. De vensterstijl werd weer ingesteld als een pop-up venster. Op die manier verdween de titelbalk en de rand van het vergrootglasvenster. 29

Binnen dit nieuwe venster werden opnieuw mouse events gedefinieerd, namelijk voor een beweging van de cursor en het loslaten van de rechtermuisknop. Als met de cursor bewogen werd, werd het venster mee bewogen met de cursor. Indien de rechtermuisknop terug losgelaten werd, werd het nieuwe venster afgesloten. Op die manier onstond er telkens als de rechtermuisknop ingedrukt bleef een venster dat mee met de cursor van plaats veranderd kon worden en dat opnieuw verdween als de rechtermuisknop losgelaten werd. In dat nieuwe venster moest nu een nog grotere uitvergroting komen van het reeds vergrootte emulatorbeeld.

F IGUU R 13 - CRE ATI E

V AN H E T V ER GR OOTGLAS

Op figuur 13 staat geschetst hoe dit juist gerealiseerd werd. Er werd een nieuwe bitmap gecreëerd. Deze moest gevuld worden met een deel van de uitvergrote bitmap. Het stuk dat uit de grote bitmap geknipt werd, moest vervolgens nog eens uitvergroot worden en in het nieuw gecreëerde venster getoond worden. De grootte van de nieuwe bitmap was dus niet hetzelfde als van het venster. De hoogte en de breedte van de bitmap werden gehalveerd t.o.v. de afmetingen van het venster. Het juiste stuk uit de grote bitmap werd in de kleine bitmap gekopieerd. Dit stuk moest nu uitvergroot worden en in het venster getoond worden. Dit kon met één functie gebeuren, nl. met StretchBlt(). Deze had dezelfde functie als BitBlt(), nl. een bitmap aan een client DC koppelen om deze op het scherm te tonen, met dat verschil dat een kleinere bitmap uitgerokken kon worden om in groter venster te passen. Dat was dus exact wat hier moest gebeuren. In deze implementatie kon StretchBlt() gebruikt worden. Bij het vergroten van het originele emulator venster naar een volledig 30

scherm was dat niet mogelijk, aangezien hier extra zwarte randen toegevoegd moesten worden en de bitmap dus moest hertekend worden. Bij het vergrootglas moest echter de reeds correcte bitmap rechtstreeks op scherm getoond worden. Er werd bij de implementatie van het vergrootglas voor gezorgd dat de cursor zich in het midden van het venster bevond. Op die manier kon de cursor m.b.v. het vergrootglas op de gewenste plaats gepositioneerd worden in het volledige scherm. Bij het indrukken van de rechtermuisknop verscheen het vergrootglas. Door het te verschuiven, met de muisknop nog steeds ingedrukt, kon de muisaanwijzer op de gewenste plaats gepositioneerd worden. Als de rechtermuisknop losgelaten werd en het vergrootglas zou verdwijnen, bevond de cursor zich in het grote venster nog steeds op de gewenste plaats. Ook in de window class van dit venster moest de muiscursor aangepast worden van een standaard cursor naar de cursor in figuur 12. Het uiteindelijke resultaat van het vergrootglas in de uitvergroting van de emulator omgeving wordt getoond in figuur 14.

F IGUU R 14 - V ER GR OOTGLAS

31

4.3.

MOGELIJKE UITBREIDINGEN

4.3.1. INTERPOLATIETECHNIEKEN Door het uitvergroten van het originele beeld naar een volledig scherm is de beeldkwaliteit verminderd. De interpolatietechniek gebruikt bij deze uitvergroting was een eenvoudige implementatie die hetzelfde resultaat gaf als een dichtste-buur-interpolatie. In de applicatie werd elke pixel in horizontale en verticale richting uitvergroot door de pixelwaarde in beide richtingen te dupliceren. Op die manier werd het beeld echter wel geblokt. Een test bij de doelgroep toonde aan dat dit het normale gebruik van de applicatie niet hinderde. Het is echter wel een optie om andere interpolatietechnieken te implementeren en de beeldkwaliteit te verbeteren. Andere, ingewikkelde interpolatie-technieken hebben wel tot nadeel dat de performantie van het programma verslechterd. Er moet dus voor het implementeren van deze technieken een afweging gedaan worden tussen beeldkwaliteit en performantie.

4.3.2. U ITBREIDING NAAR 2 BEELDSCHERMEN Een mogelijke aanpassing aan het programma is het vergrootglas niet bovenop het venster zelf te plaatsen, maar de extra uitvergroting op een andere monitor weer te geven. Daarbij zou het programma twee fullscreen schermen omvatten, de ene met de volledige uitvergroting van de emulator, de andere met nog een extra uitvergroting van een deel van het andere beeldscherm. Een moeilijkheid bij deze implementatie zou de aansturing van de 2 verschillende beeldschermen zijn. Er moet voor gezorgd worden dat de 2 fullscreen venster niet over elkaar opstarten, want een fullscreen venster kan niet verplaatst worden. In het venster dat het volledige beeld toont, moet d.m.v. bijvoorbeeld een kader, aangeduid worden welk deel van dat venster juist in de uitvergroting op het andere beeldscherm getoond wordt. Door de implementatie van de extra uitvergroting op deze manier te doen, kan een overzicht over het volledige beeld bewaard blijven terwijl het beeld nog extra wordt uitvergroot voor iemand met een beperkt zicht.

32

4.3.3. P LATFORM BUILDER Het besturingssysteem dat gebruikt werd voor het testen van het eindproduct was Windows Mobile voor een pocket PC. Daarnaast was Windows Mobile voor een smartphone ook ter beschikking. Het nadeel van een mobiel platform is dat er verschillende functies geïntegreerd zijn die op een desktopcomputer niet van toepassing zijn, zoals bijvoorbeeld de toegang tot een telefoonnetwerk. Er is binnen Microsoft een mogelijkheid om mobiele besturingssystemen aan te passen. Dit kan gedaan worden door gebruik te maken van Platform Builder. Het is een ontwikkelomgeving om ingebedde besturingssystemen te ontwikkelen, gebaseerd op Microsoft Windows CE besturingssysteem. Platform Builder bevat alle nodige tools om een Windows CE gebaseerd OS te ontwerpen. Windows CE is eigenlijk het overkoepelende platform voor mobiele platformen van Microsoft. De Windows Mobile platformen zijn afgeleide platformen van het Windows CE platform. Pocket PC en Smartphone bijvoorbeeld verschillen onderling door de verschillende onderdelen die ze van het Windows CE bevatten. Met platform builder kunnen de onderdelen van het mobiele platform zelf gekozen worden en op die manier kan een aangepast OS ontworpen worden. Voor de in deze thesis ontwikkelde applicatie zou dus ook een OS op maat gemaakt kunnen worden met enkel die onderdelen die van toepassing kunnen zijn op een PC.

33

5. TESTEN VAN HET EINDPRODUCT 5.1.

ALGEMEEN

De originele emulator is eigenlijk een programma bedoeld om het ontwikkelen en testen van applicaties voor mobiele platformen te vergemakkelijken. Het is dus niet voorzien om bestanden die via de emulator aangemaakt worden binnen Windows Mobile op te slaan op een PC. Als de emulator afgesloten wordt, verdwijnen de aangemaakte bestanden. Er is binnen de emulator een storage card optie voorzien. Een bepaalde map van de dektop PC kan gekoppeld worden aan het Windows Mobile besturingssysteem binnen de emulator. Op deze manier kunnen bestanden, aangemaakt binnen de emulator, opgeslagen worden in die map en blijven ze bewaard als de emulator afgesloten wordt. Bij het uitvoeren van de applicatie wordt er gekeken of de map “C:/FullscreenPDA” reeds aanwezig is op de PC. Indien dit niet het geval is, wordt ze aangemaakt. Deze map wordt gekoppeld aan de emulator als storage card. Bestanden in deze map kunnen geaccesseerd worden vanuit Windows Mobile en bestanden die hier opgeslagen worden binnen Windows Mobile blijven bewaard als de emulator afgesloten wordt. Indien op de PC internet aanwezig is, is het mogelijk om in de applicatie ook internet te gebruiken. Hiertoe is het nodig de VPC network driver te installeren op de computer. Dat kan door Virtual PC 2007 van Microsoft te downloaden en te installeren. Als de juiste driver geïnstalleerd is, kan via de juiste instelling in Windows Mobile gebruik gemaakt worden van het internet. Dit maakt het dan ook mogelijk om in de uitvergroting van het originele besturingssysteem e-mails te verzenden of te surfen. Het programma vraagt enige tijd voor het volledig opgestart is. De timing van het opstarten van de nieuwe implementatie werd vergeleken met de opstarttijd van de originele emulator. Onder dezelfde omstandigheden blijkt dat de opstarttijd voor beiden dezelfde is. Het uitvergroten van het beeld heeft na de optimalisaties dus geen extra negatieve invloed op de performantie van het programma.

34

5.2.

MENING VAN EEN SLECHTZIENDE

De doelgroep voor de applicatie zijn mensen met een visuele handicap. Om in te schatten of de aanpassingen het gewenste effect hadden voor de doelgroep, werd de uiteindelijk applicatie getest door een slechtziende personen. De eerste persoon die gecontacteerd werd i.v.m. deze applicatie was Kim Defreyne. Kim Defreyne is geboren met een oogaandoening, meer specifiek met cataract of grijze staar. Hierbij vertroebeld de ooglens, waardoor het zicht verminderd. Als kind kon zij daar niet aan geopereerd worden en moest zij wachten tot haar ogen volgroeid waren. Later bleek echter dat ze ook leed aan microcornea, een aandoening waarbij het hoornvlies een te kleine diameter heeft. Dat zorgde ervoor dat zij niet geopereerd kon worden aan haar oogaandoening en waarschijnlijk slechtziende zou blijven. Om het gebruik van een computer mogelijk te maken, gebruikt zij verschillende van de hulpmiddelen besproken in het marktonderzoek van deze thesis, zoals vergrotingssoftware en spraaksyntheseprogramma’s. Toen ze over de voor deze thesis ontwikkelede applicatie hoorde, was zij zeer enthousiast over het concept. Jammer genoeg heeft zij haar mening hier omtrent nog niet kunnen verschaffen. Wel werd de mening van Bert Vereycken reeds ontvangen. Bert Vereycken valt eveneens binnen de doelgroep van deze applicatie. Zijn mening volgt hier: “De kennismaking met het computerprogramma was voor mij een ware openbaring. Mijn visus is zeer beperkt – linkeroog 1/10, rechteroog 1/20 – en toch kon ik vrij vlot met het programma omspringen. Het feit dat je met één enkele muisklik woorden kan vergroten, is hierbij uiteraard cruciaal. Alleen jammer dat het contrast tussen woord en achtergrond – wit op een lichtblauw veld – niet ideaal blijkt te zijn. De leesbaarheid zou aanzienlijk verbeteren als dit contrast geoptimaliseerd zou worden. Ik slaagde erin een korte tekst te typen die zeer duidelijk in beeld verscheen. De letters waren voldoende groot én contrastrijk: zwart op witte achtergrond. Mijn besluit: een programma waarmee ik, denk ik, goed zou kunnen werken en dat me bijgevolg zéér gelukkig zou maken. Ik feliciteer de programmeur en de promotor van harte.” 35

Het gebruik van een computer voor mensen met een visuele handicap is niet vanzelfsprekend. Er bestaan reeds verschillende hulpmiddelen, maar een besturingssysteem speciaal voor slechtzienden werd nog niet ontwikkeld. Het idee om gebruik te maken van mobiele besturingssystemen werd enthousiast onthaald door de testpersonen. Het kleurcontrast binnen de applicatie is voor slechtzienden nog niet optimaal, maar de uitwerking van het concept werd alvast positief bevonden. Het besturingssysteem dat door de applicatie op het scherm getoond werd, viel buiten de reikwijdte van deze master proef. Bij mogelijke uitbreidingen van de applicatie werd reeds vermeld dat een aanpassing van het besturingssysteem d.m.v. Platform Builder mogelijk was. Hierbij werd voorgesteld om de functionaliteiten van het besturingssysteem aan te passen naar functies van een desktopcomputer door de functies voor mobiele apparaten te verwijderen uit het originele Windows Mobile besturingssysteem. Naast de functionaliteiten moet ook naar een oplossing gezocht worden voor het slechte kleurcontrast. Het moet mogelijk zij n om de lichtblauwe achtergrond met witte letters aan te passen naar een meer contrastrijke combinatie van kleuren. Er kan dus besloten worden dat na enkele aanpassingen binnen het besturingssysteem zelf die ervoor moeten zorgen dat het programma voor visueel gehandicapten nog toegankelijker gemaakt wordt, de applicatie voor deze doelgroep een goede oplossing zou kunnen bieden.

36

6. BESLUIT Er bestaan reeds verschillende mogelijkheden om visueel gehandicapten bij te staan in het gebruik van een computer. Het gaat hierbij steeds om hulpmiddellen die standaard softwarepakketten toegankelijker moeten maken. Er is echter nog steeds geen besturingssysteem ontwikkeld speciaal voor deze doelgroep. Het idee van deze masterproef bestond eruit gebruik te maken van de eigenschappen van besturingssystemen voor mobiele platforms om een computeromgeving voor slechtzienden te creëren. Windows Mobile, het mobiele besturingssysteem van Microsoft, werd uitvergroot naar een volledige desktop monitor. Hiervoor werd het besturingssysteem zelf niet aangepast, maar het emulator waarmee Windows Mobile op een desktop uitgevoerd kon worden. Microsoft had de code voor zijn Device Emulator vrijgegeven voor academische doeleinden. Bij het uitvergroten diende rekening gehouden te worden met de originele verhoudingen van de emulator, om de correcte weergave van alle applicaties binnen Windows Mobile te garanderen. Om die reden kon er geen gebruik gemaakt worden van de reeds aanwezige zoom-functie, maar moest de bitmap die getoond werd op het scherm hertekend worden. Op die manier kon een fullscreen venster bekomen worden waarbij de originele emulator zo groot mogelijk op het beeldscherm getoond werd met behoud van de originele verhoudingen van het venster en de niet bedekte delen opgevuld met zwart. Het uitvergroten van het beeld had een negatieve invloed op de performantie van de applicatie, waardoor sommige applicaties binnen Windows Mobile niet correct uitgevoerd werden. Na optimalisatie van de code, door het update gebied voor elk frame te beperken en niet telkens het volledige beeld bij te werken, was het CPU probleem opgelost. Het emulatorvenster werd uiteindelijk op een gemiddeld beeldscherm met een factor 3 à 4 uitvergroot. Voor vele slechtzienden is dit echter nog niet voldoende. Om die reden werd er nog een extra optie toegevoegd aan de applicatie, gebaseerd op een reeds bestaand hulpmiddel voor slechtzienden. Er werd een vergrootglas geïmplementeerd dat het onderliggende venster nog eens extra uit vergrootte met een factor 2. Ook de standaard cursor van de applicatie werd aangepast naar een grotere cursor om beter zichtbaar te zijn

37

voor de doelgroep van deze applicatie. Tenslotte werd er ook een eenvoudige manier voorzien om de applicatie af te sluiten, namelijk met een welbepaalde toetsencombinatie. Aan de uiteindelijk bekomen applicatie kunnen uiteraard nog uitbreidingen gedaan worden om het programma toegankelijker te maken voor visueel gehandicapten, maar het bekomen resultaat werd door een slechtziend persoon reeds functioneel en gebruiksvriendelijk bevonden.

38

7. BIBLIOGRAFIE Informatie over visueel gehandicapten  http://magnifier.sourceforge.net  http://www.aisquared.com  http://www.koc.be/kw/hmvisus/kw_hmvisus.html  http://www.who.int/mediacentre/factsheets  http://www.kimdefreyne.be

Informatie over programma en aanpassingen  http://msdn.microsoft.com  http://forums.microsoft.com/MSDN  http://www.microsoft.com/downloads  http://www.codeproject.com/KB/GDI/paint_beginner.aspx  http://www.codeproject.com/KB/GDI/updatergn.aspx  M.H. DEITEL & P.J. DEITEL, Small C++ - How To Program, Pearson Education Inc., 2005

39