.NET
Colin Fahey
1. Definition af .NET
Udtrykket ".NET" henviser til følgende samling af teknologier:
(1) Framework Class Library (FCL)
(2) Intermediate Language (IL)
(3) Common Language Runtime (CLR)
1.1 Framework Class Library (FCL)
De Framework Class Library (FCL) er et omfattende sæt af klasser til at støtte:
* Beholdere (Array, String, List, ...)
* Multithreading (tråde, thread pools)
* Networking (stikkontakter, protokoller, klienter, servere)
* Fil operationer
* Data-streams
* Parsing (regulære udtryk, XML håndtering)
* Matematiske operationer
* Undtagelse håndtering
* Language features (refleksion, stack trace, dynamisk kode)
De Framework Class Library (FCL) er gennemført for mange forskellige platforme ( Windows, Linux, MacOS, ... ).
Således er et enkeltstående program, der bruger Framework Class Library (FCL) kan udvikles uden væsentlig viden om forskelle mellem Målplatforme.
De Framework Class Library (FCL) indeholder nyttige modeller af grundlæggende begreber i datalogi (såsom "tråd, socket, strøm" osv.).
På en måde er Framework Class Library (FCL) giver hver understøttet operativsystem en moderne, højt niveau, konsekvent programmerings-interface.
De Framework Class Library (FCL) er et af de mest avancerede, omfattende, ensartet udformede, veldokumenterede samlinger af funktioner og data typer til rådighed for programmører.
Desværre følgende multimedie aspekter er ikke en del af Framework Class Library (FCL): lydoptagelse, lydafspilning, videooptagelse, videoafspilning, 3D rendering, joystick indgang, anordning kontrol ( CD/DVD, ... ) osv.
Microsoft har en .NET version af DirectX biblioteker for deres Windows operativsystemet.
Der er C# indpakningsmaterialet for OpenGL, OpenAL, GLUT, SDL osv., men det er ikke helt så nem som havende en sådan multimedie-funktioner skal indgå i de centrale Framework Class Library (FCL) og medtaget i den endelige bruger "køre-time" biblioteker.
Et af problemerne med at udvikle programmer, der bruger særlig biblioteker er, at det bestemt sæt af slutbrugere vil kræve støtte til udvalgte biblioteker.
Hvis det ikke er praktisk at hente og installere nødvendige biblioteker, en slutbruger kan vælge ikke at bruge et program der kræver disse biblioteker.
En slutbruger kan også være uvillige til at vente på et bibliotek til download fra et online-placering.
Hvis et program bygherren kræver en slutbruger at finde, erhverve, og installere biblioteker, alle uden bistand fra et bestemt program, så slutbrugeren kan vælge ikke at bruge programmet.
For eksempel er mange open source projekter kræver slutbrugere at finde, downloade og installere, mange forskellige biblioteker fra andre open source-projekter (eksempler: openssl, zlib, libpng, libjpg, glut, ...), der er tid - forbrugende, kompliceret, frustrerende, og kan resultere i slutbrugere vælger at søge efter alternative programmer eller produkter.
De "Windows Update" service tilsyneladende hjælper installere version 1.1 af .NET køre-time biblioteker til Windows brugere.
Disse løbe-tid biblioteker er inkluderet med Windows XP operativsystemet.
Derfor skaber Windows programmer, der kræver .NET 1.1 forekommer helt rimeligt.
Også de køre-time biblioteker til Microsoft's implementeringer af .NET Framework Class Library (FCL) frit kan omfordeles, så udviklere kan levere disse biblioteker til slutbrugere, der ikke allerede har biblioteker.
De Windows Vista operativsystem skibe med .NET 3.0 køre-time biblioteker (en kombination af de .NET Framework Class Libraries og flere nye biblioteker som f.eks "Windows Presentation Foundation" (WPF)).
Derfor implementerer .NET 2.0 og .NET 3.0 programmer for Windows Vista kræver ikke installatører for .NET køre-time biblioteker.
1.2 Intermediate Language (IL)
De Intermediate Language (IL) er et lille sæt af simple, processor-uafhængig, operativsystemspecifikke uafhængige instruktioner, der er tilstrækkelige til helt at udtrykke de data, strukturer og funktioner af mange forskellige høj-niveau programmeringssprog ( C++, C#, F#, Visual Basic, Java, Ocaml, ... ).
Kildekode skrevet på et højt niveau sprog kan være kompileret ned til en tilsvarende "Intermediate Language" form.
Kode i en "Intermediate Language" form let kan kombineres med anden kode i en "Intermediate Language" form.
Et edb-program (også kaldet "software)" kan inkludere kildekode skrevet i flere forskellige højt niveau sprog (eg, C#, C++, og Visual Basic).
Alle kildekoden kan kompileres (omregnet) til en "Intermediate Language" format til at gøre det let at kombinere med andre kompileret kode.
Programmer i en "Intermediate Language" form er normalt konverteres til maskinlæsbare specifikke instrukser (f.eks CPU instrukser) meget kort tid før gennemførelse (f.eks "Just-In-Time" (JIT) omstilling af IL til CPU instruktioner).
Men et program kan også gennemføres i forbindelse med en Virtual Machine (VM) designet til at fortolke Intermediate Language (IL) instruktioner.
Kode skrevet i forskellige højt niveau sprog ( C#, F#, Ocaml, C++, Visual Basic, ... ), kan kompileres til Intermediate Language (IL) form ved en passende compiler på en understøttet platform ( Windows, Linux, MacOS X, ... ), og den resulterende fil, med indlejret Intermediate Language (IL) kode, er platform-uafhængige og kan køre på enhver platform, der har en gennemførelsen af .NET Common Language Runtime (CLR).
De Intermediate Language (IL) kode genereret af compiler er stort set uafhængige af platform, hvor den compiler blev henrettet.
1.3 Common Language Runtime (CLR)
De Common Language Runtime (CLR) er den mekanisme er ansvarlig for udførelsen kode indgives i den Intermediate Language (IL) form.
De Common Language Runtime (CLR) tilbyder forskellige tjenester.
De Common Language Runtime (CLR) mai konvertere Intermediate Language (IL) kode til instruktioner, der er hjemmehørende på den platform (f.eks CPU instruktioner).
Konverteringen fra Intermediate Language (IL) til platform-specifik (f.eks CPU-specifik) instruktioner kan ske på forhånd om udførelse (dvs. en "Ahead-Of-Time" (AOT) konvertering) eller kan ske gradvist, således som det program henretter (dvs. "Just-In-Time" (JIT) konvertering) .
De Just-In-Time (JIT) konvertering kan bruge udviklende statistikker om Program Execution til dynamisk optimere konverteret kode (eksempel: at identificere hyppigt anvendte sløjfer og filialer, og optimere dem i henhold til observeret adfærd (som selv er afhængig af aktuelle data og begivenheder)).
De Common Language Runtime (CLR) forvalter tildeles hukommelse på vegne af programmet.
Derfor er CLR sikrer, at programmet ikke undlade at få adgang tildeles hukommelse, mens referencer til sådanne hukommelse fortsætter, og sikrer, at hukommelsen tildelinger er aflyst, og at hukommelsen er stillet til rådighed igen til fremtidige tildelinger efter programmet skiller sig af alle henvisninger til sådanne tildelinger .
De Common Language Runtime (CLR) registrerer, når programmet ikke længere har en henvisning til en hukommelse tildeling, og hukommelsen fordeling er markeret til deallocation.
De Common Language Runtime (CLR) bruger noget af en række "affaldsstativ samling" algoritmer (eksempel: "mark-and-sweep") at identificere og genvinde hukommelsen blokke ikke længere tilgængelig via et program.
De Common Language Runtime (CLR) håndterer program undtagelser.
De Common Language Runtime (CLR) håndhæver sikkerhedspolitikken.
De Common Language Runtime (CLR) bruger "P/Invoke" mekanisme til at indlæse platform-specifikke biblioteker og påberåbe (indkaldelse) funktioner inden for disse biblioteker.
2. .NET ( FCL, IL, CLR ) implementeringer af Microsoft
2.1 Indledning
De .NET paradigme ( FCL, IL, CLR ) er blevet gennemført med Microsoft.
Den nyeste version, "3.0", blev udgivet i 2006.10.
.NET 3.0 består af .NET 2.0 Framework Class Libraries og flere nye biblioteker, som f.eks "Windows Presentation Foundation" (WPF) forbundet med "Silverlight" (tidligere WPF/E, tidligere Sparkle, ...) browser plugin til Firefox og Internet Explorer.
Microsoft opdeler .NET 2.0 software i to forskellige pakker:
(1) .NET Framework Version 2.0 Redistributable Package
Den videredistribuerbare pakke er påkrævet i henhold til slutbrugerne til at eksekvere programmer er bygget til den .NET paradigme. Denne pakke skal også være installeret af udviklere, før du installerer og bruger .NET Software Development Kit (SDK) nævnt nedenfor.
(2) .NET Framework Version 2.0 Software Development Kit
Den Software Development Kit (SDK) kræves af udviklere til at kompilere C# kildekoden til Intermediate Language (IL) program files.
Denne pakke indeholder forskellige udviklingsværktøjer og dokumentation.
2.2 .NET Framework Version 2.0 Redistributable Package
Den videredistribuerbare pakke er påkrævet i henhold til slutbrugerne til at eksekvere programmer er bygget til den .NET paradigme.
Denne pakke skal også være installeret af udviklere, før du installerer og bruger .NET Software Development Kit (SDK) nævnt nedenfor.
De følgende Internet side er det vigtigste .NET download side:
Afsnittet navngivne ".NET Framework Version 2.0 Redistributable Package" har links til tre hardware-platforme: "Download x86 version", "Download x64 version", "Download IA64 version".
For eksempel at følge linket "Download x86 version", fører til en side med titlen "Microsoft .NET Framework Version 2.0 Redistributable Package (x86)"
(Filnavn: dotnetfx.exe; Version: RC1; Udgivet: 3/22/2006; Sprog: engelsk; Download Size: 22.4 MB)
Lokalt cachede version (kun til reference; potentielt forældede):
(Filnavnet er blevet ændret her fra den originale fil navn "dotnetfx.exe" at undgå forvirrende det med den version 1.1 installationsprogrammet også opkaldt "dotnetfx.exe".)
2.3 .NET Framework Version 2.0 Software Development Kit (SDK)
Den Software Development Kit (SDK) kræves af udviklere til at kompilere C# kildekoden til Intermediate Language (IL) program files.
Denne pakke indeholder forskellige udviklingsværktøjer og dokumentation.
De følgende Internet side er det vigtigste .NET download side:
Afsnittet navngivne ".NET Framework Version 2.0 Software Development Kit" har links til tre hardware-platforme: "Download x86 version", "Download x64 version", "Download IA64 version".
For eksempel at følge linket "Download x86 version", fører til en side med titlen ".NET Framework 2.0 Software Development Kit (SDK) (x86)"
(Filnavn: setup.exe; Version: 2.0; Udgivet: 11/7/2005; Sprog: engelsk; Download Size: 354.0 MB)
Lokalt cachede version (kun til reference; potentielt forældede):
(Filnavnet er blevet ændret her fra den originale fil navn "setup.exe" at undgå forvirrende det med alle andre installationsfilerne navngivne "setup.exe".)
3. Microsoft Visual C#: en Integrated Development Environment (IDE) program
3.1 Indledning
En Integrated Development Environment (IDE) program gør det muligt for en udvikler at redigere kildekoden og udføre forskellige værktøjer (eksempler: compiler, debugger, ...) inden for rammerne af et enkelt, samlende program, fyldt med nyttige visuelle indikationer og kontrol.
"Microsoft Visual C# 2005 Express Edition" er en no-pris (ingen betaling kræves) IDE hentes Microsoft.
For ikke-database udvikling, er det næsten umuligt at skelne denne no-cost produkt fra detailhandelen modstykke, "Microsoft Visual C# 2005".
Jeg bruger ofte både produkter, professionelt og rekreativt, og jeg har endnu ikke bemærket nogen praktisk forskel mellem produkterne.
3.2 Officielle links
The Internet site's forside:
Den side vedrørende "Visual C# Express Edition":
Klik på "Download Now" knappen på højre side af siden til at vælge en download mulighed.
(En metode er at starte en installer program, som vil hente filer fra Microsoft i hver installation.
En anden metode er at downloade en fuld CD-ROM "ISO" image, som tillader fremtidige offline-installation.
De ISO image, "VCS.iso" (451,837,952 bytes; CRC 55884F2C) for 32-bit x86 engelsk, kan brændes til en CD-ROM bruger "Nero 7 Ultra", f.eks. )
4. .NET ( FCL, IL, CLR ) gennemførelsen af Mono Project
4.1 Indledning
De .NET paradigme ( FCL, IL, CLR ) er blevet gennemført af deltagere i en gruppe kaldet Mono Project.
4.2 Officielle links
Projektets websted:
Software download side:
4.3 Lokalt cachede version
Lokalt cachede version af installationsprogrammet (kun for henvisningen; potentielt forældede):
4.4 .NET 2.0 udvikling med Mono
De "mcs" compiler, og den dokumentation, som i november 2006, for det meste vedrører C# 1.0 og FCL 1.1.
Men den "mcs" compiler er i stand til at kompilere C# 2.0 kode, der ikke indeholder generiske eller generiske-baserede funktioner, men begrænser API til 1.0.
For at gøre fuld C# 2.0 udvikling med FCL 2.0 biblioteker, skal du bruge "gmcs" compiler.
Se følgende side på Mono site:
5. SharpDevelop: en open-source Integrated Development Environment (IDE) program
5.1 Indledning
En Integrated Development Environment (IDE) program gør det muligt for en udvikler at redigere kildekoden og udføre forskellige værktøjer (eksempler: compiler, debugger, ...) inden for rammerne af et enkelt, samlende program, fyldt med nyttige visuelle indikationer og kontrol.
SharpDevelop er en glimrende open-source IDE program til C# / .NET udvikling.
Denne IDE nøje ligner Microsoft Visual C# IDE, og i nogle henseender den SharpDevelop IDE er forbedret efter Microsoft produkt.
Men Microsoft Visual C# har nogle funktioner (eksempel: debugging), at SharpDevelop programmet ikke har (i skrivende stund).
5.2 Officielle links
Det enkle internetside forside:
Den side vedrørende "The Open Source Development Environment for .NET":
Download siden, der har oplysninger om 1.1 og 2.0 versioner af SharpDevelop:
5.3 Lokalt cachede version
Lokalt cachede version af installationsprogrammet (kun for henvisningen; potentielt forældede):
6. Nyttige C# / .NET / IL værktøjer
6.1 SciTech Software ".NET Memory Profiler"
Denne profiler viser hukommelse tildelinger og andre ressourcetildeling, at en kompileret .NET program eller samling gør samtidig fuldbyrdelsesstaten.
De real-time graf giver mulighed for en person at se, i detaljer, hvordan aktionerne i programmet (såsom aktioner udløst af brugerinput eller andre begivenheder) påvirke hukommelse tildeling og affaldsstativ samling.
De real-tid tabellen notering opfattelse gør det muligt for en person at få oplysninger om hukommelse tildelinger.
Denne profiler øjeblikkeligt og dramatisk, afslørede spild hukommelse anvendes i en real-time Direct3D program jeg havde udviklet.
Et mønster i opadgående ramper og pludselige dråber (på grund af "affaldsstativ samling)" i hukommelsesanvendelse grafer passede perfekt med periodisk, meget-korte pauser i 3D-tegning af mit program.
De profiler gjort det muligt for mig at opdage, at hyppig tildeling af midlertidig objekter blev akkumulere megen hukommelse, udløser affaldsstativ indsamling hyppigt, og tage nok tid til hver affaldsstativ indsamling til at forårsage et par tegning perioder at være forpasset.
De profiler's real-tid tabellen over tildelte objekt typer afslørede de typer af objekter, der forbruges mest hukommelse, og som tildelinger forbrugt hukommelse på højeste sats (bytes per second), og som tildelinger havde den højeste bortskaffelse sats.
Undersøgelse af real-time grafer, og real-time borde, gjort det muligt for mig at fokusere på at studere den måde, hvorpå visse datatyper som bruges i min kode.
Ændre kode for at undgå hyppige tildelinger af midlertidige objekter i høj grad kan reducere den samlede sats hukommelse tildeling og bortskaffelse, og derfor kan reducere hyppigheden af affaldsstativ indsamling udløsning.
(Jeg tror "Bytes/sec" er en meget afslørende statistik for realtids-hukommelse bruger, ud over at "Live instances".
) At se alle disse bliver opdateret meget hurtigt i en tabel format, og er i stand til at vælge, hvordan rækker er sorteret, og ændre sortering parameter til enhver tid gør erfaring med at studere en real-time-program meget spændende og informative.
Memory tildeling svar på brugerens interaktion med et kørende program kan studeres, og testning hurtigt kan tilpasse sig til den feedback til indsnævre de mest interessante aspekt.
(For eksempel det 2006 July version havde følgende attributter: version 2.6.89; 4.3 MB; USA $127.00; Hent 14-dages-grænse version, uden omkostninger, for evalueringen.)
6.2 FxCop: .NET kode Analyzer / kritiker
FxCop analyserer en kompileret .NET program (eller sammenstillet forsamling) og genererer en oversigt over mulige problemer med den originale kildekode.
Mulige resultater problemer og sikkerhedsmæssige problemer er identificeret.
Mulige kodningskonvention krænkelser er identificeret.
FxCop ikke kræver adgang til den originale kildekode til at udføre analysen.
Kun den kompileret .NET program (som indeholder IL) er påkrævet.
Alligevel er de FxCop rapport giver hyperlinks til specifikke linje numre i den originale kildekode.
Hvis Microsoft Visual C# 2005 IDE er aktiv, ved at klikke på hyperlinket i FxCop rapport vil medføre, at IDE at kæde til den relevante kilde filen og linje nummer.
FxCop har efter min mening en lidt akavet måde at integrere med Microsoft Visual C# 2005 IDE.
Men når det først er oprettet, FxCop producerer en meget interessant og potentielt værdifulde betænkning.
Rapporten indeholder detaljerede råd om, hvordan man kan forbedre den originale kildekode.
Jeg synes, det er umagen værd at analysere et program ved hjælp FxCop med regelmæssige mellemrum.
Jeg ville ikke blive overrasket, hvis nogle softwareudvikling projekter eller virksomheder krævede hele koden er skrevet af udviklere at give nogen advarsler eller kritik af FxCop.
Regler kan tilføjes eller fjernes fra FxCop database, alt efter behov.
FxCop er en open-source, gratis program.
6.3 "Reflector for .NET": decompiler / analysator
Fra Lutz Roeder's Internet site:
"Reflector is the class browser, explorer, analyzer and documentation viewer for .NET. Reflector allows to easily view, navigate, search, decompile and analyze .NET assemblies in C#, Visual Basic and IL."
"Reflector" kan hjælpe en person undersøge, hvordan tredjepart biblioteker er skrevet.
Nogle gange ville det være meget nyttigt at vide nøjagtigt, hvordan en metode i en forsamling er gennemført.
Hvis en metode opfører sig i en uventet eller mystisk måde, så "Reflector" kan bruges til at se implementeringen.
Ved at se gennemførelse, programmør kan løse problemer forårsaget af konkrete implementeringer af biblioteks metoder.
En ven fortalte mig, at "Reflector" hjulpet ham lære mere om funktionsmåden af dårligt dokumenterede metoder i Microsoft gennemførelsen af Framework Class Libraries (FCL).
"Reflector" kan være nyttige, når dokumentation for et bibliotek metode består af kun et par ord, som "beskriver den værdi" eller "hændelseshandler."
Hvis et bibliotek funktion aktiveringen er fejlfrit en ukendt årsag (når alle de parametre, synes gyldigt), og derefter bruge "Reflector" at se på gennemførelsen af bibliotekets funktion kan afsløre årsagen til fiasko.
"Reflector" udfører nogle "reverse engineering" af en .NET program eller forsamling.
Andre forsyningsselskaber, herunder eventuelt "Reflector" selv, kan give kildekoden til programmer eller forsamlinger bygget baseret på uklar kildekode.
Dette er naturligvis en kilde til bekymring for nogle udviklere og deres investorer.
(2006 July: Reflector.zip var version 4.2.45.0)
7. Internet diskussionsfora
Google søgning er den bedste måde at finde svar på specifikke spørgsmål om ethvert emne, men de websteder nedenfor gentagne gange vist i søgeresultaterne for C# og .NET spørgsmål.
Webstederne nedenfor er awesome til at udforske de mange cool ting, folk har gjort det med C# og .NET.
"The Code Project" websted har tusindvis af interessante og nyttige artikler, for C#, C++ og andre sprog og programmering paradigmer.
De "MSDN Code Gallery" websted har mange interessante artikler og kode prøver relateret til Microsoft teknologier.
Andre internetsider relateret til C# og .NET:
8. Generelle noter
8.1 Platform uafhængighed
De Intermediate Language (IL), ligesom Java "byte kode," er platform uafhængig.
Enhver .NET-kompatibel compiler vil generere platform uafhængig Intermediate Language (IL) kode til at danne programmer eller forsamlinger.
Programmer emballeret som eksekverbare filer ("*.exe" filer), skal have nogle platform-afhængig kode er specifik for et operativsystem, med henblik på at blive korrekt fortolket og lanceret som eksekverbare software i forbindelse med bl.a. operativsystemet.
Men de indfødte eksekverbare del af software-filen kun tjener til at påberåbe sig en .NET CLR motor, der indgiver IL kode indeholdt i softwaren fil for udførelsen af CLR motor.
Microsoft tilbyder en gennemførelse af .NET forsyningsselskaber (compiler, ...), og en gennemførelse af Framework Class Library (FCL), kun for Windows operativsystemet.
De Mono Project tilbyder implementeringer af .NET forsyningsselskaber (compiler, ...), og implementeringer af Framework Class Library (FCL) for følgende operativsystemer: Windows, Linux, MacOS X, og BSD.
8.2 Fart sammenlignet med non-CLR C / C++
De Common Language Runtime (CLR) aspekt af .NET er den sammenhæng, hvori en C# program udfører.
De CLR udfører "affaldsstativ indsamling" og gør det muligt for programmer at aktivere funktioner i "uforvaltet" biblioteker (alle de biblioteker der ikke gennemføres i Intermediate Language (IL)).
Enhver funktion de gør mere end ren matematik, ren string manipulation, eller rene hukommelse kopiering, vil påberåbe funktioner i "uforvaltet" biblioteker.
Alle fil operationer, Socket operationer, tegning operationer, input (mus, tastatur), output operationer (konsol), platform thread operationer, præcision timer operationer, vinduessystem operationer osv., vil påberåbe funktioner i "uforvaltet biblioteker."
Desværre er den mekanisme for at påkalde "uforvaltet" funktioner fra CLR kræver en betydelig mængde tid.
Derfor skal den samlede hastighed af et program udfører i forbindelse med CLR er noticably langsommere end et program, der kan påberåbe "uforvaltet" funktioner direkte.
For visse typer af software, hastighed kan være vigtige.
For visse typer af software, hastighed kan gøre en vigtig forskel i den subjektive eller psykologiske oplevelse for en person, der anvender softwaren.
For visse typer af software, hastighed kan betyde forskellen mellem at nå et mål og fiasko.
Multithreading, øget CPU hastigheder, og forbedringer til CLR kode generering af anlægget, vil hjælpe software fuldbyrdelsesstaten i forbindelse med CLR fuldbyrde hurtigere.
Men enhver kode, der henretter uden for CLR, og påberåber sig platform biblioteker direkte, vil uundgåeligt fuldbyrde betydeligt hurtigere end den software, der udfører inden for rammerne af den CLR.
De forsikringer, som CLR til C# software, som sikkert at bygge bro mellem administreret kode og uforvaltet kode, kommer på en omkostning, der næppe vil blive reduceret.
Derfor vil ethvert program, som er meget platform intensiv (eksempler: 3D-simulation eller spil, fil-processor, netværksserver osv.) må forventes at udføre en ordre størrelsesorden hurtigere uden for CLR end når gennemføres inden for de CLR.
Forskellen er enorm.
Også et program, der udfører en betydelig del af lavniveau-manipulation af dataene vil fuldbyrde betydeligt hurtigere uden for CLR end i CLR.
Programmer fuldbyrdelsesstaten i forbindelse med CLR fuldbyrde hurtigt nok til at være nyttig for mange praktiske formål.
Som CPU hastigheder stige, og så kode tager bedre brug af flere CPUs, programmer fuldbyrdelsesstaten i forbindelse med CLR vil kunne anvendes til flere opgaver, der kræver en høj beregning.
Men i midten af 2008 de CLR stadig ikke er egnet til 3D-spil af enhver sofistikerede, medmindre en meget aggressiv bestræbelser der gøres for at reducere antallet af funktion opkald til 3D-bibliotek (OpenGL eller Direct3D), eventuelt ved at bruge begreber som "shader programmer" og "vise lister;" noget for at reducere antallet af funktion opkald.
