NO328434B1

NO328434B1 - Formateringssprak og objektmodell for vektorgrafikk

Info

Publication number: NO328434B1
Application number: NO20032205A
Authority: NO
Inventors: Joseph S Beda; Kevin T Gallo; Adam M Smith; Gilman K Wong; Sriram Subramanian
Original assignee: Microsoft Corp
Priority date: 2003-03-27
Filing date: 2003-05-15
Publication date: 2010-02-15
Also published as: NO20032205L; US7486294B2; ECSP034609A; ZA200303553B; HRP20030389A2; HU0301289D0; EP1462998A3; GT200300184A; AU2003204007A1; CA2428471A1; RO123609B1; JP2004295857A; HUP0301289A3; HUP0301289A2; US20040189667A1; EP1462998A2; ATE403198T1; MY143630A; IL155881A0; NZ525857A

Description

Foreliggende oppfinnelse er beslektet med de følgende samtidige US-patent-søknadene: 10/184,795 med tittelen "Multiple-Level Graphics Processing System and Method; 10/184,796 med tittelen "Generic Parameterization for a Scene Graph; 10/185,775 med tittelen "Intelligent Caching Data Structure for Immediate Mode Graphics"; alle innlevert 27. juni 2002; samt US-patentsøknaden med tittelen "Visual and Scene Graph Interfaces" (Attorney Docket No. 3470), innlevert samtidig med denne. Hver beslektede søknad er overdratt til samme som foreliggende patent-søknad og innlemmes med dette ved referanse i sin helhet.

Oppfinnelsen vedrører generelt databehandlingssystemer, og mer spesielt prosessering av grafikk og annen videoinformasjon for fremvisning i datasystemer.

Begrensningene ved den tradisjonelle direktemodus modellen for å aksessere grafikk i databehandlingssystemer er nådd, delvis fordi minne og busshastigheter ikke har holdt tritt med fremskrittene for hovedprosessorer og/eller grafikkprosesso-rer. Generelt krever den nåværende (f.eks. WM_PAINT) modellen for klargjøring av en ramme for mye dataprosessering til at en kan holde tritt med maskinvarens opp-dateringsfrekvens når en ønsker komplekse grafikkeffekter. Som følge av dette, når komplekse grafikkeffekter blir forsøkt med konvensjonelle grafikkmodeller, istedenfor å fullende de endringene som resulterer i de oppfattede visuelle effektene i tide før den neste rammen, kan endringene bli lagt til i ulike rammer, hvilket produserer resultater som er visuelt og merkbart uønskede.

En ny modell for å styre grafikkutmating er beskrevet i de ovennevnte US-patentsøknadene 10/184,795, 10/184,796 og 10/185,775. Denne nye modellen tilveiebringer et antall betydelige forbedringer innenfor grafikkprosesseringsteknologi. For eksempel er 10/184,795 generelt rettet mot et system og en fremgangsmåte for flernivå grafikkprosessering, der en høynivå-komponent (f.eks. av et operativsystem) utfører beregningstunge aspekter ved det å bygge en scenegrafikkfremstilling, oppdatere animeringsparametere og traversere scenegrafikkfremstillingens datastrukturer, ved en relativt lav operasjonsfrekvens, for å sende forenklede datastrukturer og/eller grafikk-kommandoer til en lavnivå-komponent. Fordi høynivåprosesseringen forenkler dataene i betydelig grad, kan lavnivå-komponenten operere med en høyere frekvens (i forhold til høynivå-komponenten), for eksempel en frekvens som svarer til rammeoppdateringsfrekvensen til grafikk-undersystemet, for å prosessere dataene til konstante utgangsdata for grafikk-undersystemet. Når det anvendes animering, istedenfor å måtte omtegne et helt bilde med endringer, kan lavnivåprosesseringen interpolere parameterintervaller som nødvendig for å oppnå øyeblikkelige verdier som når de rendres gir et litt endret bilde for hver ramme, hvilket tilveiebringer en jevntflytende animering.

U.S.-søknaden 10/184,796 beskriver en parametrisert scenegrafikkfremstilling som tilveiebringer foranderlige (animerte) verdier og parametriserte grafikkfremstilling-containere slik at programkode som ønsker å tegne grafikk (f.eks. et applikasjonsprogram eller en komponent i et operativsystem) selektivt kan endre visse aspekter ved scenegrafikkfremstilling-beskrivelsen mens den etterlater andre aspekter uforandret. Programkoden kan også gjenbruke allerede byggede deler av scenegrafikkfremstillingen, muligens med ulike parametere. Som en forstår gir muligheten for på en enkel måte å endre utseended for viste elementer via para-metrisering og/eller gjenbruk av eksisterende deler av en scenegrafikkfremstilling vesentlige gevinster i den totale grafikkprosesseringseffektiviteten.

U.S.-søknaden 10/185,775 beskriver generelt en bufrings-datastruktur og relaterte mekanismer for lagring av visuell informasjon via objekter og data i en scenegrafikkfremstilling. Datastrukturen er generelt assosiert med mekanismer som på en intelligent måte styrer hvorledes den visuelle informasjonen deri blir bygget opp og anvendt. For eksempel, dersom den ikke spesifikt etterspørres av applikasjonspro-grammet, har mesteparten av informasjonen som er lagret i datastrukturen ingen ekstern referanse til seg, hvilket gjør at denne informasjonen kan optimaliseres eller prosesseres på annen måte. Som en kan forstå tilveiebringer dette effektivitet og sparing av ressurser, idet dataene i bufrings-datastrukturen for eksempel kan bli prosessert til et ulik format som er mer kompakt, og/eller reduserer behovet for påfølgende, gjentatt prosessering, så som en bitmap-avbildning eller et annet post-prosesseringsresultat.

Den internasjonale patentsøknaden WO 98/10356 A beskriver et system og en fremgangsmåte relatert til databehandlingssystemer, hvor fremgangsmåten omfatter automatisk prosessering, tolking og fremføring av multi-format media, der mediene kan behandles og fremvises separat uten å påvirke forbindelser mellom disse mediene.

Selv om forbedringene angitt ovenfor gir vesentlige fordeler for grafikkprosesseringsteknologi trengs det fortsatt en måte for programmer på en effektiv måte å anvende denne forbedrede grafikkmodellen og dens andre relaterte forbedringer på en enkel måte. Det som trengs er en omfattende, men likevel enkel måte for programmer å dra nytte av de mange særtrekkene og grafikkprosesseringsmulighetene som tilveiebringes av den forbedrede grafikkmodellen, og med det produsere kompleks grafikk på en effektiv måte.

Kort beskrevet tilveiebringer foreliggende oppfinnelse en element-objektmodell og et vektorgrafikk-formateringsspråk for å aksessere denne element-objektmodellen på en måte som gjør det mulig for programkodeutviklere på en konsekvent måte å grensesnitte med en grafikkfremstilling-datastruktur for å produsere grafikk. Vektorgrafikk-formateringsspråket omfatter et utvekslingsformat for å uttrykke vektorgrafikk via element-objektmodellen. Når den interpreteres, blir formatkoden parset til data som omfatter elementer i et elementtre som blir oversatt til objektene i en scenegrafikk-datastruktur. På elementtrenivå er det tilveiebrakt et egenskapsystem og et presenteringssystem som tilveiebringer rike programmerbarhetsegenskaper, omfattende arv-karakteristika og hendelsesbehandling, som gjør det enkelt for scenedesignere å konstruere muligens komplekse scener. Generelt svarer vektorgrafikk-elementene til form-elementer og andre elementer omfattende bilde- og video-elementer som korrelerer med scenegrafikk-objekter i scenegrafikk-objektmodellen. Egenskapene og andre ressurser for vektorgrafikk-elementene korrelerer også med tilsvarende egenskaper og ressurser i scenegrafikk-objektmodellen.

Vektorgrafikksystemet kan således programmere til et elementnivå, der hver av tegneformene er illustrert som et element på samme nivå som resten av de programmerbare elementene på en side/ i et skjermbilde, hvilket muliggjør interaksjon med presenteringssystemet, hendelser og egenskaper. Vektorgrafikksystemet tilveiebringer også en mekanisme for å programmere til ressursnivå, med hvilken scenedesignere kan forenkle elementtreet og presenteringssystemet i vesentlig grad og programmere direkte til visual-API laget som grensesnitter mot scenegrafikkfremstilling-datastrukturen. Dette tilveiebringer en mer effektiv og lettvekt måte å produsere det ønskede objektet, selv om en mister noe av programmerbarheten på elementnivået. I én implementasjon, når en bildefylling av typen "visuell børste" blir programmert, kan parseren direkte kalle API-laget med ressursnivådata for å skape et motsvarende visuelt penselobjekt (som også er en korrelasjon mellom element-objektmodellen og scenegrafikk-objektmodellen). I dette to-delte systemet blir elementnivå vektorgrafikk parset til opprettede elementer som senere må konverteres til objektene, mens ressursnivå vektorgrafikk blir parset og lagret direkte på en effektiv måte. Samtidig kan ressursnivådata eller objektene som er opprettet fra disse refereres til av elementer og deler av elementtreet. For dette formål kan elementer som omfatter visuelle penselelementer være navngitt. Scenedesigneren har således mulighet for å balansere effektivitet mot programmerbarhet etter behov.

Element-klassehierarkiet omfatter en form-klasse (Shape), en bilde-klasse (Image), en video-klasse (Video) og en kanvas-klasse (Canvas). Elementer av form-klassen omfatter rektangel (Rectangle), polylinje (Polyline), polygon (Polygon), vei (Path), linje (Line) og ellipse (Ellipse). Hvert element kan omfatte eller være assosiert med fylling(egenskap)-data, strek-data, klippingsdata, transformasjonsdata, filtereffektdata og maskedata. Former svarer til geometri (i scenegrafikk-objektmodellen) som blir tegnet med arvede og kaskadede presenteringsegenskaper som blir anvendt for konstruksjon av pennen og børsten som er nødvendig for å tegne formene. Klassen Image er mer spesifikk enn Shape og kan omfatte mer rastergrafikkdata, mens klassen Video muliggjør avspilling av video (eller liknende multimedia) i et vist element. Klassen Canvas kan tjene som en container for former for å holde form-klassen enkel.

I én implementasjon blir formatkoden interpretert av en parser / oversetter som generelt legger til elementnivå-elementer i et elementtre / egenskapsystem og tilknytter presenteringsenheter til disse elementene. Presenteringssystemet tar deretter elementtreet med de tilknyttede presenteringsenhetene og oversetter dataene til objekter (via en bygger-klasse) og kaller et visual-API lag som grensesnitter mot scenegrafikkfremstillingen og oppretter scenegrafikk-objektene.

Formateringsspråket tilveiebringer ulike måter for å beskrive et element, omfattende et enkelt datastreng-format eller en kompleks objektnotasjon (en kompleks egenskapsyntaks). For et enkelt datastreng-format anvender parseren/oversetteren og/eller presenteringssystemet en typeomformer for å konvertere en datastreng til et ønsket objekt i visual-API grensesnittet. Når fyllingsattributen er for kompleks til å passe i én enkelt streng, blir den komplekse egenskapsyntaksen, som kan være in-line i formatkoden, anvendt for å beskrive egenskapsettet. Ettersom samme rendringsmodell deles mellom elementnivået og API-nivået, er mange av objektene de samme, hvilket gjør parsingen / oversettingen meget effektiv og gir andre fordeler. En ressurs-instans kan også befinne seg et annet sted (f.eks. i formatkoden eller i en fil) og refereres til ved et navn. På denne måten kan en scenedesigner gjenbruke et element i elementtreet gjennom en hel scene, inklusive elementer som er beskrevet med den komplekse egenskapsyntaksen.

Andre gevinster og fordeler vil åpenbares av den følgende detaljerte beskrivelsen, sett sammen med figurene, der: Figur 1 er et blokkdiagram som illustrerer et eksempel på databehandlings-system i hvilket foreliggende oppfinnelse kan innlemmes; Figur 2 er et blokkdiagram som illustrerer generelt en grafikklagarkitektur i hvilken foreliggende oppfinnelse kan innlemmes; Figur 3 er en illustrasjon av en scenegrafikkfremstilling av visuelle enheter og assosierte komponenter for prosessering av scenegrafikkfremstillingen for eksempel ved å traversere scenegrafikkfremstillingen for å tilveiebringe grafikk-kommandoer og andre data i henhold til et aspekt ved foreliggende oppfinnelse; Figur 4 er en illustrasjon av en scenegrafikkfremstilling med ContainerVisual-objekter, DrawingVisual-objekter og assosierte tegneprimitiver konstruert i henhold til et aspekt ved foreliggende oppfinnelse; Figur 5 er en illustrasjon av en klasse Visual, i en objektmodell, i henhold til et aspekt ved foreliggende oppfinnelse; Figur 6 er en illustrasjon av ulike andre objekter i objektmodellen, i henhold til et aspekt ved foreliggende oppfinnelse; Figur 7 er et diagram som illustrerer en transformasjon av et Visual-objekt sine data i henhold til et aspekt ved foreliggende oppfinnelse; Figurene 8A og 8B er illustrasjoner av transformasjoner av et Visual-objekt sine data henholdsvis i en geometrisk skala og en ikke-uniform skala, i henhold til et aspekt ved foreliggende oppfinnelse; Figurene 9A-9C er blokkdiagrammer av SurfaceVisual objekter og andre Visual-objekter og komponenter i henhold til et aspekt ved foreliggende oppfinnelse; Figurene 10A og 10B er diagrammer som illustrerer HWnd Visual-objekter i henhold til et aspekt ved foreliggende oppfinnelse; Figur 11 er et diagram som illustrerer et lagdelt Visual-objekt i henhold til et aspekt ved foreliggende oppfinnelse; Figur 12 er en illustrasjon av Geometry-klasser i objektmodellen, i henhold til et aspekt ved foreliggende oppfinnelse; Figur 13 er en illustrasjon av en PathGeometry-struktur, i henhold til et aspekt ved foreliggende oppfinnelse; Figur 14 er en illustrasjon av en scenegrafikkfremstilling av Visual-objekter og tegneprimitiver og viser eksempler på grafikk produsert av primitivene, i henhold til et aspekt ved foreliggende oppfinnelse; Figur 15 er en illustrasjon avet Brush klassehierarki i objektmodellen, i henhold til et aspekt ved foreliggende oppfinnelse; Figur 16 er en illustrasjon av rendret grafikk som er resultat av data i et LinearGradientBrush-objekt, i henhold til et aspekt ved foreliggende oppfinnelse; Figur 17 er en illustrasjon av rendret grafikk som er resultat av data i et RadialGradientBrush-objekt, i henhold til et aspekt ved foreliggende oppfinnelse; Figur 18 er en illustrasjon av rendret grafikk som er resultat av det å ha ulike strekk-verdier, i henhold til et aspekt ved foreliggende oppfinnelse; Figur 19 er en illustrasjon av rendret grafikk som er resultat av det å ha ulike tegl-verdier, i henhold til et aspekt ved foreliggende oppfinnelse; Figur 20 er et flytdiagram som illustrerer generelt logikk for å interpretere et Visual-objekt, som omfatter et Brush-objekt, for å generere grafikk i henhold til et aspekt ved foreliggende oppfinnelse; Figur 21 er en illustrasjon av et gridd og et transformert gridd, som er resultat av data i et VisualBrush-objekt, i henhold til et aspekt ved foreliggende oppfinnelse; Figur 22 er en illustrasjon av griddet og det transformerte griddet, inneholdende rendret grafikk deri tegnet fra et Visual-objekt, i henhold til et aspekt ved foreliggende oppfinnelse; Figur 23 er en illustrasjon av et rendret NineGridBrush-objekt i henhold til et aspekt ved foreliggende oppfinnelse; Figur 24 er en illustrasjon av Transform-klasser i objektmodellen, i henhold til et aspekt ved foreliggende oppfinnelse; Figur 25 er en illustrasjon av Element-klasser i element-objektmodellen, i henhold til et aspekt ved foreliggende oppfinnelse; Figur 26 er en illustrasjon av komponenter for å interpretere formateringsspråk-kode for å grensesnitte mot visual-API laget, i henhold til et aspekt ved foreliggende oppfinnelse; og Figur 27 er en illustrasjon av klipping langs en geometrisk bane i henhold til et aspekt ved foreliggende oppfinnelse.

Eksempel på driftsmiljø

Figur 1 illustrerer et eksempel på et egnet datasystemmiljø 100 i hvilket oppfinnelsen kan implementeres. Datasystemmiljøet 100 er kun ett eksempel på et

egnet datamaskinmiljø, og er ikke ment å legge begrensninger vedrørende omfanget av oppfinnelsens bruksområde eller funksjonalitet. Heller ikke skal datamaskinmiljøet 100 forstås å ha noen som helst avhengighet av eller krav vedrørende noen komponent eller kombinasjon av komponenter som er illustrert i det eksempelvise driftsmiljøet 100.

Oppfinnelsen kan operere i ulike andre generelle eller spesialiserte datasystemmiljøer eller -konstruksjoner. Eksempler på velkjente databehandlingssystemer, -miljøer og/eller -konstruksjoner som kan være egnet for anvbendelse med oppfinnelsen omfatter, men er ikke begrenset til, personlige datamaskiner, tjener-datamaskiner, håndholdte anordninger eller laptop-anordninger, digitaliseringsbord, flerprosessorsystemer, mikroprosessorbaserte systemer, set-top bokser, pro-grammerbar forbrukerelektronikk, personlige datamaskiner i nettverk, minidata-maskiner, stormaskiner, distribuerte databehandlingsmiljøer som omfatter hvilke som helst av de ovennevnte systemene eller anordningene, og liknende.

Oppfinnelsen kan beskrives i den generelle sammenhengen datamaskin-eksekverbare instruksjoner, så som programmoduler, som eksekveres av en datamaskin. Programmoduler omfatter generelt rutiner, programmer, objekter, komponenter, datastrukturer, etc. som utfører konkrete oppgaver eller implementerer spesifikke abstrakte datatyper. Oppfinnelsen kan også tilpasses for distribuerte databehandlingsmiljøer der oppgaver blir utført av fjernprosesseringsanordninger som er forbundet via et kommunikasjonsnettverk. I et distribuert datamaskinmiljø kan progamvaremoduler være lokalisert i både lokale og fjerntliggende datalagringsmedi-er, inklusive minnelagringsanordninger.

Med henvisning til figur 1 omfatter et eksempel på system for å implementere oppfinnelsen en generell databehandlingsanordning i form aven datamaskin 110. Komponenter av datamaskinen 110 kan omfatte, men er ikke begrenset til, en pro-sesseringsenhet 120, et systemminne 130 og en systembuss 121 som forbinder ulike systemkomponenter inklusive systemminnet med prosesseringsenheten 120. Systembussen 121 kan være en hvilken som helst blant flere typer busstrukturer, inklusive en minnebuss eller minnekontroller, en periferienhet-buss og en lokal buss, som anvender en hvilken som helst blant ulike bussarkitekturer. Som eksempler, og uten begrensning, omfatter slike arkitekturer en ISA (Industry-Standard-Arkitektur)-buss, en MCA (Micro-Channel-Arkitektur)-buss, en EISA (Enhanced ISA)-buss, en lokal VESA (Video-Electronics-Standards-Associate)-buss, en AGP (Accelerated Graphics Port)-buss og en PCI (Peripheral-Component-lnterconnect)-buss, også kjent som en Mezzanine-buss.

Datamaskinen 110 omfatter typisk flere datamaskinlesbare medier. Datamaskinlesbare medier kan være et hvilket som helst tilgjengelig medium som kan

aksesseres av en datamaskin 110, og omfatter både flyktige og ikke-flyktige medier samt flyttbare og ikke-flyttbare medier. Som eksempler, uten begrensning, kan datamaskinlesbare medier omfatte datamaskin-lagringsmedier og kommunikasjonsmedier. Datamaskin-lagringsmedier omfatter både flyktige og ikke-flyktige, flyttbare og

ikke-flyttbare medier som er realisert med en hvilken som helst metode eller teknolo-gi for lagring av informasjon så som datamaskinlesbare instruksjoner, datastrukturer, programmoduler eller andre data. Datamaskin-lagringsmedier omfatter, men er ikke begrenset til, RAM, ROM, EEPROM, flash-minne eller annen minneteknologi, CD-ROM, DVD (digital-versatile-disk) eller andre optisk-disk lagre, magnetkassetter, magnetbånd, magnetdisklagre eller andre magnetiske lagringsanordninger, eller et hvilket som helst annet medium som kan anvendes for å lagre den ønskede informasjonen og som kan aksesseres av datamaskinen 110. Kommunikasjonsmedier inneholder typisk datamaskinlesbare instruksjoner, datastrukturer, programmoduler eller andre data i et modulert datasignal så som en bærebølge eller en annen trans-portmekanisme og omfatter ethvert informasjonsleveringsmedium. Med betegnelsen "modulert datasignal" menes et signal som får én eller flere av sine karakteristika satt eller endret for det formål å innkode informasjon i signalet. Som et eksempel, og uten begrensning, omfatter kommunikasjonsmedier ledningsbaserte medier, så som et kabelnettverk eller en direkte ledningsforbindelse, og trådløse medier så som akustiske, RF-baserte, infrarøde og andre trådløse medier. Enhver kombinasjon av det ovennevnte er også omfattet innenfor rammen av datamaskinlesbare medier.

Systemminnet 130 omfatter datamaskin-lagringsmedier i form avflyktigt og/eller ikke-flyktigt minne så som et leseminne (ROM) 131 og et direkteaksess-minne (RAM) 132. Et BIOS (basic input/output system) 133, som inneholder de grunnleggende rutinene som overfører informasjon mellom elementer i datamaskinen 110, for eksempel under oppstart, er typisk lagret i ROM 131. RAM 132 inneholder typisk data og/eller programmoduler som er umiddelbart tilgjengelige for og/eller som opereres på av prosesseringsenheten 120. Som et eksempel, uten begrensning, illustrerer figur 1 et operativsystem 134, applikasjonsprogrammer 135, andre programmoduler 136 og programdata 137.

Datamaskinen 110 kan også omfatte andre flyttbare/ikke-flyttbare, flyktige/ikke-flyktige datamaskin-lagringsmedier. Kun som et eksempel illustrerer figur 1 en harddiskstasjon 141 som leser fra eller skriver til ikke-flyttbare, ikke-flyktige magnetiske medier, en magnetdiskstasjon 151 som leser fra eller skriver til en flyttbar, ikke-flyktig magnetdisk 152 og en optisk-disk stasjon 155 som leser fra eller skriver til en flyttbar, ikke-flyktig optisk disk 156 så som et CD-ROM eller et annet optisk medium. Andre typer flyttbare/ikke-flyttbare, flyktige/ikke-flyktige datamaskin-lagringsmedier som kan anvendes i det eksemplifiserte driftsmiljøet omfatter, men er ikke begrenset til, magnetbåndkassetter, flashminnekort, DVD-plater, digitale bildebånd, solit state RAM, solid state ROM og liknende. Harddiskstasjonen 141 er typisk koplet til systembussen 121 via et ikke-flyttbart minne-grensesnitt, så som grensesnittet 140, og magnetdiskstasjonen 151 og optisk-disk stasjonen 155 er typisk koplet til systembussen 121 via et flyttbart minne-grensesnitt, så som grensesnittet 150.

De stasjonene og deres assosierte datamaskin-lagringsmedier som er diskutert ovenfor og illustrert i figur 1 tilveiebringer lagring av datamaskinlesbare instruksjoner, datastrukturer, programmoduler og andre data for datamaskinen 110. I figur 1 er for eksempel harddiskstasjonen 141 vist som lagrende et operativsystem 144, applikasjonsprogrammer 145, andre programmoduler 146 og programdata 147. Merk at disse komponentene enten kan være de samme som eller ulike fra operativsystem 134, applikasjonsprogrammer 135, andre programmoduler 136 og programdata 137. Operativsystem 144, applikasjonsprogrammer 145, andre programmoduler 146 og programdata 147 er gitt ulike referansenummer her for å illustrere det at de i det minste er ulike kopier. En bruker kan sende inn kommandoer og informasjon til datamaskinen 110 via inndataanordninger så som et digitaliseringsbord (elektronisk digitalisator) 164, en mikrofon 163, et tastatur 162 og en pekeranordning 161, vanligvis omfattende en mus, en styreball eller en berøringsmatte. Andre inndataanordninger (ikke vist) kan omfatte en styrespak, en spillkontroll, en parabolantenne, en skanner eller liknende. Disse og andre inndataanordninger er ofte koplet til prosesseringsenheten 120 via et bru-kerinndatagrensesnitt 160 som er koplet til systembussen, men kan også være tilkoplet via andre grensesnitts- eller busstrukturer, så som en parallellport, en spillutgang eller en universell seriell buss (USB). En monitor 191 eller en annen type skjermanordning er også koplet til systembussen 121 via et grensesnitt, så som et skjermkort 190. Monitoren 191 kan også være integrert med et berøringsskjermpanel 193 eller liknende som kan mate inn digitaliserte inndata så som håndskrift i databe-handlingssystemet 110 via et grensesnitt, så som et berøringsskjerm-grensesnitt 192. Merk at monitoren og/eller berøringsskjermpanelet kan være fysisk koplet til et hus i hvilket databehandlingsanordningen 110 er innlemmet, så som en digitaliseringsbord-type personlig datamaskin, der berøringsskjermpanelet 193 essensielt tjener som digitaliseringsbordet 164.1 tillegg kan datamaskiner så som databehandlingsanordningen 110 også omfatte andre periferi-utmatingsanordninger så som høyttalere 195 og en skriver 196, som kan være tilkoplet via et periferienhet-utmatingsgrensesnitt 194 eller liknende.

Datamaskinen 110 kan operere i et nettverksmiljø via logiske forbindelser til én eller flere fjerndatamaskiner, så som en fjemdatamaskin 180. Fjerndatamaskinen 180 kan være en personlig datamaskin, en tjener, en ruter, en nettverks-PC, en peer-anordning eller en annen vanlig nettverksnode, og omfatter typisk mange av eller alle de elementene som er beskrevet ovenfor i forbindelse med datamaskinen 110, selv om kun en minnelagringsanordning 181 er illustrert i figur 1. De logiske for-bindelsene som er vist i figur 1 omfatter et lokalt nettverk (LAN) 171 og et fjernaksessnett (WAN) 173, men kan også omfatte andre typer nettverk. Slike nettverksmiljøer er vanlige i kontorer, bedriftsomspennende datanettverk, intranett og Internett.

Når den anvendes i et LAN, er datamaskinen 110 forbundet til LAN 171 via et nettverksgrensesnitt eller nettverkskort 170. Når den anvendes i et WAN, omfatter datamaskinen 110 typisk et modem 172 eller andre anordninger for å etablere kom-munikasjon over WAN 173, for eksempel Internett. Modemet 172, som kan være internt eller eksternt, kan være koplet til systembussen 121 via brukerinndatagren-sesnittet 160 eller en annen egnet mekanisme. I et nettverksmiljø kan programmoduler som er vist i forbindelse med datamaskinen 110, eller deler av disse, være lagret i den fjernlokaliserte minnelagringsanordningen. Som et eksempel, og uten begrensning, illustrerer figur 1 fjern-applikasjonsprogrammer 185 som lagret i minneanordningen 181. En må forstå at de viste nettverksforbindelsene kun er eksempler, og at det kan anvendes andre mekanismer for å etablere en kommunika-sjonslink mellom datamaskinene.

G raf ikk- a rkitektu r

Ett aspekt ved foreliggende oppfinnelse er generelt rettet mot det å gjøre det mulig for programkode, så som en applikasjon eller en komponent av et operativsystem, å kommunisere tegneinstruksjoner og annen informasjon (f.eks. bitmap-avbildninger) til grafikk-komponenter for å rendre grafikkdata på systemdisplayet. For dette formål tilveiebringer foreliggende oppfinnelse et formateringsspråk sammen med et sett av form-elementer (shape) og andre elementer, et grupperings- og sammensettingssystem, samt integrasjon med et generelt egenskapsystem i en objektmodell for å gjøre det mulig for programmer å bygge opp en scenegrafikkfremstilling med datastrukturer, tegneprimitiver (kommandoer) og andre grafikkrelaterte data. Når det blir prosessert, resulterer scenegrafikkfremstillingen i at det vises grafikk på skjermen.

Figur 2 illustrerer en generell, lagdelt arkitektur 200 i hvilken foreliggende oppfinnelse kan bli implementert. Som vist i figur 2 kan det utvikles programkode 202 (f.eks. et applikasjonsprogram eller en operativsystemkomponent eller liknende) som mater ut grafikkdata på én eller flere ulike måter, omfattende via en billedbehandling 204, via vektorgrafikk-elementer 206 og/eller via funksjons/metodekall rettet direkte til et visual-API lag 212. Direkte vekselvirkning med API-laget er ytterligere beskrevet i den ovennevnte, samtidige patentsøknaden med tittel "Visual and Scene Graph Interfaces".

Generelt tilveiebringer billedbehandlingen 204 programkoden 202 med en mekanisme for å laste, editere og lagre bilder, f.eks. i bitmap-format. Disse bildene kan anvendes av andre deler av systemet, og det eksisterer også en måte for å anvende den primitive tegnekoden til å tegne direkte på et bilde.

I henhold til et aspekt ved foreliggende oppfinnelse tilveiebringer vektorgrafikk-elementene 206 en annen måte for å tegne grafikk, i overensstemmelse med resten av objektmodellen (som beskrevet nedenfor). Vektorgrafikk-elementer 206 kan genereres via et formateringsspråk, som et element / egenskapsystem 208 og et presenteringssystem 210 prosesserer for å gjøre passende kall til visual-API laget 212. Som beskrevet nedenfor med henvisning til figur 26 blir vektorgrafi-elementene 206 generelt parset til objekter fra den objektmodellen fra hvilken en scenegrafikkfremstilling blir tegnet, som kan tilveiebringes til scenegrafikkfremstillingen via et elementnivå via element / egenskap systemet 208 og presenteringssystemet 210, eller kan tilveiebringes på en mer effektiv måte på et ressursnivå, som også beskrevet nedenfor.

I én implementasjon omfatter grafikklagarkitekturen 200 omfatter en høynivå sammensettings- og animeringsmotor 214 som omfatter eller på annen måte er assosiert med en bufrings-datastruktur216. Bufrings-datastrukturen 216 inneholder en scenegrafikkfremstilling som omfatter hierarkisk innrettede objekter som administreres i henhold til en definert objektmodell, som beskrevet nedenfor. Generelt tilveiebringer visual-API laget 212 programkoden 202 (og presenteringssystemet 210) med et grensesnitt mot bufrings-datastrukturen 216, omfattende mulighet for å instansiere objekter, åpne og lukke objekter for å sende data til dem, osv. Med andre ord eksponerer høynivå sammensettings- og animeringsmotoren 214 et ensrettet media API-lag 212 med hvilket utviklere kan angi intensjoner ved-rørende grafikk og media for å vise grafikkinformasjon og tilveiebringe en underliggende plattform med tilstrekkelig informasjon slik at plattformen kan optimere bruken av maskinvaren for programkoden. For eksempel vil den underliggende plattformen være ansvarlig for bufring, ressursinnhenting og mediaintegrasjon.

I én implementasjon sender høynivå sammensettings- og animeringsmotoren 214 en strøm av instruksjoner og eventuelt andre data (f.eks. pekere til bitmap-bilder) til en hurtig lavnivå sammensettings- og animeringsmotor 218. Som anvendt her er betegnelsene "høynivå" og "lavnivå" tilsvarende de som anvendes i andre databehandlings-scenarier, der det generelt er slik at jo lavere en programvare-komponent er i forhold til høyere komponenter, desto nærmere er denne komponenten maskinvaren. For eksempel kan således grafikkinformasjon sendt fra høynivå sammensettings- og animeringsmotoren 214 mottas ved lavnivå sammensettings- og animeringsmotoren 218, der informasjonen blir anvendt for å sende grafikkdata til grafikk-undersystemet, som omfatter maskinvaren 222.

Høynivå sammensettings- og animeringsmotoren 214 sammen med programkoden 202 bygger opp en scenegrafikkfremstilling for å representere en grafikkscene som tilveiebringes av programkoden 202. For eksempel kan hvert element som skal tegnes være lastet med tegneinstruksjoner som systemet kan bufre i scenegrafikk-datastrukturen 216. Som vil bli beskrevet nedenfor finnes det et antall ulike måter å spesifisere denne datastrukturen 216, og hva som tegnes. Videre er høynivå sammensettings- og animeringsmotor 214 integrert med tidsmåler- og animeringssystemer 220 for å tilveiebringe deklarativ (eller annen) animeringsstyring (f.eks. animeringsintervaller) og tidmålingsstyring. Merk at animeringssystemet gjør det mulig å sende animerte verdier i det vesentlige hvor som helst i systemet, omfattende for eksempel på element-egenskapnivå 208, inne i visual-API laget 212 og i hvilke som helst av de andre ressursene. Tidmålingssystemet er eksponert på element- og visualnivåene.

Lavnivå sammensettings- og animeringsmotor 218 styrer sammensettingen, animeringen og rendringen av scenen, som deretter blir levert til grafikk-undersystemet 222. Lavnivåmotoren 218 anordner rendringene for scenene fra flere applikasjoner, og omplementerer, med rendringskomponenter, den faktiske rendringen av grafikk til skjermen. Merk imidlertid at det til tider kan være nødvendig og/eller for-delaktig at noe av rendringen skjer på høyere nivåer. For eksempel, selv om de lavere lagene betjener forespørseler fra flere applikasjoner, blir de høyere lagene instansiert på en pr. applikasjon basis, slik at det er mulig via avbildningsmeka-nismene 204 å utføre tidkrevende eller applikasjons-spesifikk rendring på høyere nivåer og sende referanser til et bitmap-bilde til de lavere lagene.

Scenearafikk - obiektmodell

Som beskrevet nedenfor deles rendringsmodellen av de høynivå, kontroll-baserte vektorgrafikk-elementene 206 og de lavere-nivå objektene opprettet av visual-API laget 212 anvendt i scenegrafikk-datastrukturen 216. Dette gir en betydelig overensstemmelse mellom de høyere-nivå elementene ifølge foreliggende oppfinnelse og de lavere-nivå objektene. Det følgende beskriver én implementasjon av scenegrafikk-objektmodellen.

Figurene 3 og 4 viser eksempler på scenegrafikkfremstillinger, henholdsvis 300 og 400, som omfatter et baseobjekt referert til som et Visual-objekt. Generelt omfatter et Visual-objekt et objekt som representerer en virtuell overflate for brukeren og har en visuell representasjon på displayet. Som vist i figur 5 tilveiebringer en baseklasse Visual grunnfunksjonalitet for andre Visual-underklasser, det vil si at klassen Visual 500 er en abstrakt baseklasse fra hvilken Visual-underklasser (f.eks. 501-506) blir avledet.

Som vist i figur 3 er et toppnivå (eller rot) Visual-objekt 302 tilknyttet et VisualManager-objekt 304, som også har en relasjon (f.eks. via en peker) med et vindu (HWnd) 306 eller en tilsvarende enhet i hvilken grafikkdata blir utmatet for programkoden. VisualManager 304 styrer tegningen av toppnivå Visual-objektet (og eventuelle underelementer i dette Visual-objektet) til dette vinduet 306. Figur 6 viser VisualManager som ett av et sett av andre objekter 620 i objektmodellen for grafikksystemet som beskrives her.

For å tegne prosesserer VisualManager 304 (f.eks. traverserer eller overfører) scenegrafikkfremstillingen som fordelt av Dispatcher 308 og tilveiebringer grafikkinstruksjoner og andre data til lavnivå-komponenten 218 (figur 2) for dens tilhørende vindu 306, så som generelt beskrevet i U.S.-patentsøknadene 10/184,795, 10/184,796 og 10/185,775. Scenegrafikkprosesseringen vil vanligvis bli fordelt av Dispatcher 308 med en frekvens som er relativt sett lavere enn oppdateringsfrekvensen for lavnivå-komponenten 218 og/eller grafikk-undersystemet 222. Figur 3 viser et antall underelement Visual-objekter 310-315 innrettet hierarkisk nedenfor toppnivå (rot) Visual-objektet 302, noen av hvilke er representert som oppbygget via tegnekontekstene (Drawing Context) 316, 317 (vist som stiplede bokser for å angi deres midlertidige natur) henholdsvis med assosierte instruksjons-lister 318 og 319, f.eks. inneholdende tegneprimitiver og andre Visual-objekter. Visual-objektene kan også inneholde annen egenskapinformasjon, som vist i det følgende eksempel på klassen Visual:

En transformasjon, betemt av transform-egenskapen, definerer koordinatsystemet for delgrafikken for et Visual-objekt. Koordinatsystemet før transformasjonen er betegnet pre transformasjon-koordinatsystemet og det etter transformasjonen er betegnet post transform-koordinatsystemet, dvs. at et Visual-objekt med en transformasjon er ekvivalent med et Visual-objekt med en transformasjonsnode som forelder. Figur 7 viser generelt et eksempel på transformasjon, og identiserer pre transformasjon- og post transformasjon-koordinatsystemene i forhold til et Visual-objekt. For å oppnå eller sette transformasjonen av et Visual-objekt kan Transform-egenskapen anvendes.

Merk at koordinattransformasjonene kan anvendes på en uniform måte på alt, som om den var i en bitmap. Merk at dette ikke betyr at transformasjoner alltid blir anvendt på punktgrafikk, men at det som blir rendret blir likt påvirket av transformasjoner. For eksempel, dersom brukeren tegner en sirkel med en rund penn som er 2,54 cm (én tomme) bred og deretter anvender en skala i X-retningen på to på denne sirkelen, vil pennen være 5,08 cm bred til venstre og høyre og bare 2,54 cm bred i topp og bunn. Dette blir noen ganger referert til som en sammensetting- eller punktgrafikk-transformasjon (i motsetning til en skjelett- eller geometriskalering som kun påvirker geometrien). Figur 8A er en illustrasjon av en skaleringstransformasjon, med et ikke-transformert bilde 800 til venstre og et transformert bilde 802 med en ikke-uniform skala til høyre. Figur 8B er en illustrasjon av en skaleringstransformasjon med det ikke-transformerte bildet 800 til venstre og et transformert bilde 804 med geometriskalering til høyre.

Med hensyn til koordinattransformasjon av et Visual-objekt, transformerer TransformToDescendant et punkt fra referanse Visual-objektet til et etterkommer Visual-objekt. Punktet blir transformert fra post transformasjon-koordinatrommet for referanse Visual-objektet til post transformasjon-koordinatrommet til etterkommer Visual-objektet. TransformFromDescendant transformerer et punkt fra etterkommer Visual-objektet opp forelderkjeden til referanse Visual-objektet. Punktet blir transformert fra post transformasjon-koordinatrommet til etterkommer Visual-objektet til post transformasjon-koordinatrommet til referanse Visual-objektet. Metoden CalculateBounds returnerer avgrensningsboksen for innholdet i Visual-objektet i post transformasjon-koordinatrommet. Merk at det kan finnes en alternativ versjon av API-grensesnittet som tillater mer spesifikke spesifikasjoner vedrørende hvordan transformasjonen av et Visual-objekt skal interpreteres under en koordinattransformasjon. For eksempel kan, men trenger ikke transformasjonen av referanse og etterkommer Visual-objektet bli tatt i betraktning. I dette alternativet er det således fire muligheter, f.eks. kan koordinater transformeres fra pre-transformasjon til pre-transformasjon rommet, pre-transformasjon til post-transformasjon rommet, post-transformasjon til pre-transformasjon rommet og post-transformasjon til post-transformasjon rommet. Samme konsept kan anvendes for aktiveringstesting, f.eks. kan aktiveringstesting startes i pre transformasjons- eller post transformasjons-koordinatrommet og aktiveringstestresultatene vil kunne være i pre transformasjons- eller post transformasjons-koordinatrommet.

Klippings-egenskapen (Clip) setter (og oppnår) klippingsområdet for et Visual-objekt. Et hvilket som helst Geometry-objekt (klassen Geometry er beskrevet nedenfor med henvisning til figur 12) kan anvendes som et klippingsområde, og klippingsområdet blir anvendt i post transformasjon-koordinatrommet. I én implementasjon er standardsettingen for klippingsområdet null, dvs. ingen klipping, hvilket kan betraktes som et uendelig stort klippingsrektangel fra (-00, -00) til (+00, +00).

Opasitets-egenskapen (Opacity) oppnår/setter opasitetsverdien til Visual-objektet, slik at innholdet i Visual-objektet blir blendet på tegneoverflaten basert på opasitetsverdien og den valgte blendingsmodus. Blendemmodus-egenskapen (BlendMode) kan anvendes for å sette (eller oppnå) blendemodusen som anvendes. For eksempel kan en opasitets (alfa)-verdi bli satt mellom 0,0 og 1,0, med lineær alfablending satt som modus, f.eks. Farge = alfa <*> forgrunnsfarge + (1,0-alfa) <*> bak-grunnsfarge). Andre tjenester, så som spesialeffekt-egenskaper, kan være inkludert i et Visual-objekt, f.eks. skarphetsreduksjon (blur), ensfarget, osv.

De ulike tjenester (omfattende transformasjon, opasitet, klipping) kan bli aktivert eller lagt til (pushed) og deaktivert eller fjernet (popped) for en tegnekontekst, og aktiverings/deaktiveringsoperasjoner kan være nestede så lenge et deaktivering-kall motsvarer et aktivering-kall. For eksempel er sekvensen PushTransform(...); PushOpacity(...); PopTransform(...); ulovlig, fordi PopOpacity må kalles før kallet til PopTransform.

Metoden PushTransform legger til en transformasjon. Påfølgende tegneoperasjoner blir eksekvert med hensyn til den tillagte transformasjonen. Metoden PopTransform fjerner transformasjonen tillagt av det motsvarende PushTransform-kallet: void PushTransform(Transform transform);

void PushTransform(Matrix matrix);

void PopTransform();.

Tilsvarende legger metoden PushOpacity til en opasitetsverdi. Påfølgende tegneoperasjoner blir rendret på en midlertidig overflate med den spesifiserte opasitetsverdien og deretter kombinert inn i scenen. PopOpacity fjerner den opasiteten som ble tillagt av det tilhørende PushOpacity-kallet: void PushOpacity(float opacity);

void PushOpacity(NumberAnimationBase opacity);

void PopOpacityO;.

Metoden PushClip legger til en klippingsgeometri. Påfølgende tegneoperasjoner blir klippet etter denne geometrien. Klippingen blir anvendt i post transforma-sjonsrommet. PopClip fjerner klippingsområdet tillagt av det tilhørende PushClip-kallet: void PushClip(Geometry clip);

void PopClipO;.

Merk at tilleggingsoperasjonene kan bli vilkårlig nestet så lenge fjerningsope-rasjonene overensstemmer med en tilleggingsoperasjon. For eksempel er følgende gyldig:

Aktiveringstesting blir utført i post transformasjon-koordinatrommet, og returnerer en identitet for hvert aktiveringstestbare Visual-objekt som blir aktivert, f.eks. når en penn-aktivering eller et museklikk blir detektert. En alternativ versjon av grensesnittet kan tillate aktiveringstesting å starte i et pre transformasjon-koordinatrom relativt det Visual-objektet der aktiveringstesten startes. Visual-objekter som blir aktivert returneres i en høyre-mot-venstre, dybde-først rekkefølge. Aktiveringstestingen kan styres med ulike flagg, omfattende HitTestable, som bestemmer om Visual-objektet kan aktiveres (standardverdi er true) og HitTestFinal, som bestemmer om aktiveringstesting opphører når Visual-objektet blir aktivert, det vil si at dersom et Visual-objekt blir aktivert og HitTestFinal-egenskapen til Visual-objektet er sann, aktiveringstestingen avbrytes og returnerer de resultatene som er samlet inn inntil dette tidspunktet (standardverdi er false). Et annet flagg er HitTestlgnoreChildren, som bestemmer hvorvidt underelementer av et Visual-objekt skal tas i betraktning når aktiveringstestingen blir utført på et Visual-objekt (standardverdi er false).

Et ProxyVisual-objekt er et Visual-objekt som kan legges til mer enn én gang i scenegrafikkfremstillingen. Ettersom et hvilket som helst Visual-objekt som referers til av et ProxyVisual-objekt kan aksesseres via flere veier fra rot-objektet, jobber ikke lese-tjenester (TransformToDescendent, TransformFromDescendent og HitTest) gjennom et ProxyVisual-objekt. Essensielt er det én kanonisk bane fra et hvilket som helst Visual-objekt til rot-objektet i Visual-objekttreet, og denne banen omfatter ingen ProxyVisual-objekter.

Som illustrert i figur 5 er det definert ulike typer Visual-objekter i objektmodellen, omfattende ContainerVisual 501, DrawingVisual 502, ValidationVisual 503, SurfaceVisual 504 og HwndVisual 505. Tabellen nedenfor viser eksempler på metoder i en klasse DrawingVisual:

Klassen DrawingVisual er en container for grafisk innhold (f.eks. linjer, tekst, bilder, osv.). Merk at det er mulig å legge til et Visual-objekt i et DrawingVisual-objekt, men i noen implementeringer er ikke dette tillatt. Klassen DrawingVisual 502 omfatter en metode Open som returnerer et IDrawingContext-objekt som kan anvendes for å fylle opp DrawingVisual-objektet, f.eks. med andre Visual-objekter og tegneprimitiver, som beskrevet nedenfor. I én implementasjon, av ulike årsaker som også er beskrevet nedenfor, kan et DrawingVisual-objekt kun åpnes én gang for å bygge opp dens tegnekontekst; med andre ord er et slikt DrawingVisual-objekt uforanderlig. Etter at DrawingVisual-objekt er fylt lukkes DrawingVisual-objektet ved anvendelse av en metode Close, f.eks. på tegnekonteksten. Merk at et Open-kall kan slette eventuelt innhold (underelementer) i et Visual-objekt, men i én alternativ implementasjon er det tilveiebrakt en metode Append for å åpne et eksisterende Visual-objekt på en måte legger til i dette Visual-objektet. Med andre ord fungerer et kall til en metode OpenForAppend på samme måte som Open, bortsett fra at det eksisterende innholdet i DrawingVisual-objektet ikke blir slettet ved åpningen.

Det følgende er et eksempel på hvorledes en tegnekontekst blir anvendt for å fylle et Visual-objekt:

Generelt er klassen ValidationVisual 503 konseptuelt tilsvarende DrawingVisual, bortsett fra at et ValidationVisual-objekt blir bygget opp når systemet ber om at det blir bygget opp, heller enn når programkoden ønsker å bygge det opp.

Foreksempel, som beskrevet i U.S.-søknaden 10/185,775, kan høynivå

sammensettings- og animeringsmotoren 214 (figur 2) ugyldiggjøre scenegrafikk-data når det er behov for ressurser, for eksempel når deler av en scenegrafikkfremstilling ikke er synlig. For eksempel dersom deler blir scrollet ut av skjermbildet, klippet vekk, osv. Dersom det senere blir behov for de ugyldiggjorte scenegrafikk-dataene, vil den kallede programkoden 202 bli kalt på nytt for å tegne på nytt (gyldiggjøre) den ugyldiggjorte delen av scenegrafikkfremstillingen. For dette formål er ett typisk an-vendelses-scenario at programkode oppretter en underklasse av ValidationVisual og redefinerer metoden OnValidate. Når systemet kaller metoden OnValidate, blir det sendt med en tegnekontekst, og programmet anvender tegnekonteksten for å gjenoppbygge ValidationVisual-objektet.

Eksempelet nedenfor viser én måte å implementere en enkel ValidationVisual-underklasse, f.eks. en som tegner en linje med en gitt farge. Linjens farge kan endres ved å kalle metoden SetColor. For å tvinge oppdateringen av ValidationVisual-objektet, kaller SetColor på Invalidate for å tvinge grafikk-undersystemet til å revalidere ValidationVisual-objektet:

Dette eksemplet viser hvorledes en kan anvende ValidationVisual-under klassen: Figur 4 viser et eksempel på scenegrafikkfremstilling 400 der ContainerVisual-objekter og DrawingVisual-objekter er relatert i en scenegrafikkfremstilling og har assosierte data i form av tegneprimitiver (f.eks. i tilhørende tegnekontekster). Klassen ContainerVisual er en container for Visual-objekter, og ContainerVisual-objekter kan være nestet inn i hverandre. Underelementene i et ContainerVisual-objekt kan manipuleres med et VisualCollection-objekt returnert fra en underelement(Children)-egenskap i VisualContainer. Rekkefølgen til Visual-objektene i VisualCollection bestemmer i hvilken rekkefølge Visual-objektene blir rendret, det vil si at Visual-objektene blir rendret fra den laveste indeksen til den høyeste indeksen fra bakgrunnen til forgrunnen (tegnerekkefølgen). For eksempel, med passende parametere med tre DravingVisual-objekter som representerer et rødt, et grønt og et blått rektangel hierarkisk under et ContainerVisual-objekt, vil følgende kode resultere i at det blir tegnet tre rektangler (translatert fra høyre og ned), et rødt rektangel bakerst, et grønt rektangel i midten og et blått rektangel foran:

Som illustrert i figur 5 er en annen type Visual-objekt SurfaceVisual 504. Generelt, som illustrert i figur 3, refererer et SurfaceVisual-objekt 315 en i-minne overflate (bitmap) 322 som programkoden 202 (figur 2) kan aksessere. Klient-programkoden 202 kan tilveiebringe sitt eget overflate-minne, eller den kan be om at minnet blir allokert av overflate-objektet.

Programkoden 202 har mulighet for å åpne et SurfaceVisual-objekt og oppnå en tegnekontekst 323 inn i hvilken programkoden 202 kan skrive pikseldata 324 eller liknende og direkte legge til disse pikselene på overflaten. Dette er illustrert i figur 3 ved den stiplede linjen mellom overflate-objektet 322, tegnekonteksten 323 (vist som en boks med stiplet ramme for å angi dens midlertidige natur) og pikseldataene 324.

Programkoden 202 også har mulighet til å opprette SurfaceVisualManager

330 og assosiere et Visual-objekt del-grafikkfremstilling 332 med SurfaceVisual 315. Denne muligheten er illustrert i figur 3 ved den stiplede linjen mellom Surface-objktet 322 og SurfaceVisualManager 330. Merk at Visual-objekt del-grafikkfremstillingen 332 også kan neste andre SurfaceVisual-objekter, som også vist i figur 3. SurfaceVisualManager-objektet 330 (også vist som en annen type objekt i settet 620 i figur 6) traverserer Visual-objekt del-grafikkfremstillingen 332 for å oppdatere SurfaceVisual-bitmap 322. Merk videre at denne traverseringen blir styrt av Dispatcher 308, og kan for effektivitet bli bremset for å styre hvor ofte bitmap 322 blir oppdatert. SurfaceVisualManager 330 trenger ikke traversere Visual-objekt del-grafikkfremstillingen 322 hver gang og/eller med samme frekvens som toppnivå VisualManager 302 traverserer resten av scenegrafikkfremstillingen.

Med hensyn til overflater, som ytterligere beskrevet med henvisning til figurene 9A-9C, muliggjør således den foreliggende grafikkmodellen generelt sammensetting av et sett av Visual-objekter til en overflate, direktemodus rendring av vektor- og bitmap-primitiver til en overflate, setting av en overflate til skjermskrivebordet eller til en annen overflate og styring av hvilken overflate i en overflateliste som blir anvendt for setting eller tegning. En overflateliste er definert som en samling av én eller flere overflater (dvs. rammer/buffere) av fysisk (system-eller bilde-) minne som blir anvendt for å lagre sammensettinger av Visual-objekter eller grafiske tegninger eller begge deler. Én av overflatene i overflatelisten kan bli satt som aktivt bakbuffer der tegning og/eller setting blir utført og én av overflatene i overflatenlisten er satt som aktiv primæroverflate, eller frontbuffer, som blir anvendt for sammensetning til et annet rendringsmål.

Overflater kan anvendes på flere måter. Som et eksempel viser figur 9A sammensetting til en overflate. I figur 9A tilknytter SurfaceVisualManager 900 en overflateliste 902 som rendringsmål for et tre 904 av Visual-objekter. Under hver sammensettingssyklus blir Visual-objektene kombinert inn i den overflaten i overflatelisten som for tiden tjener som aktivt bakbufferfor overflatelisten. Den overflaten som det settes til kan omfatte en overflate som eies av klienten/høynivå-sammensettingsmotoren 214 (figur 2) for i-prosess sammensettingsscenarier, en overflate som eies av lavnivå-sammensettingsmotoren 218 for scenarier der klienten ikke trenger bit-verdiene men lavnivå-sammensettingsmotoren 218 trenger dem for å sette overflaten på et annet rendringsmål eller en inter-prosess overflate for scenarier der klienten trenger tilgang til overflate-bitveriene, men lavnivå-sammensettingsmotoren 218 også trenger overflaten for andre setteoppgaver.

Sammensettingen styres av en tidmålingstjeneste som er tilknyttet VisualManager-objektet. Ett eksempel på en tidmålingstjeneste er en manuell modus som vil kunne anvendes som i eksempelet nedenfor:

En annen måte å anvende en overflate er med direktemodus rendring til en overflate, via en kontekst. Det å knytte en overflateliste til et Visual-objekt (et SurfaceVisual-objekt) muliggjør direktemodus rendring til den overflaten i overflatelisten som for tiden tjener som aktivt bakbuffer for overflatelisten. Denne rendringen blir utført ved å oppnå en tegnekontekst fra SurfaceVisual-objektet og eksekvere tegnekommandoer på den konteksten, som beskrevet ovenfor. Merk at det å oppnå en tegnekontekst låser overflaten, slik at ikke andre setteoperasjoner kan utføres på den. Hver tegnekommando blir utført umiddelbart, og vektorer og andre overflater kan bli tegnet (blendet) på overflaten. Andre Visual-objekter kan imidlertid ikke bli tegnet på overflaten, men kan istedet bli kombinert inn i overflaten ved å assosiere det med et VisualManager-objekt, som beskrevet tidligere (f.eks. i figur 9A).

En annen anvendelse av overflater er ved setting av en overflate på et annet rendringsmål. For dette formål, når en overflateliste er knyttet til et SurfaceVisual-objekt, kan overflaten deretter bli tilknyttet som en node i et Visual-tre, og den overflaten i overflatelisten som på det angjeldende tidspunkt tjener som primæroverflate eller frontbuffer kan bli satt til en annen overflate eller til skjermskrivebordet. Dette er illustrert i figur 9B og i eksempelet nedenfor:

Direkte setting til/fra en overflate er illustrert i figur 9C, der de ovenfor beskrevne mulighetene er kombinert slik at setting til bakbuffer-overflaten i en overflateliste og setting fra frontbuffer-overflaten i en overflateliste (f.eks. til skjermskrivebordet) utføres samtidig. Merk at for å fjerne den uønskede bildeeffekten kjent som "tearing", så bør overflatelisten omfatte minst to overflater, en front- og en bakbufferoverflate. En overflate som blir anvendt som i figur 9C vil sannsynligvis eies av lavnivå-motoren 218, eller være en inter-prosess overflate for å gjøte at sammensettingen lavnivå-motoren 218 skal yte bedre.

Overflater blir konstruert som uavhengige objekter, som angitt i eksemplene på instansieringsfunksjoner nedenfor:

Når den er generert, kan en overflate og/eller en overflateliste bli tilknyttet et SurfaceVisual-objekt eller til et VisualManager-objekt.

Videre kan en overflate få data fra en dekoder og/eller sende sine data til en innkoder for å skrive på et spesifikt filformat. Overflater kan også motta/sende data fra/til effekt-grensesnitt. En overflate kan bli konstruert for et hvilket som helst pikselformat fra det fulle settet av støttede overflate-formattyper. Det kan imidlertid bli gjort noen justeringer av det spesifiserte pikselformatet, f.eks. dersom det spesifiserte pikselformatet er mindre enn 32 bit pr. piksel, vil formatet blir satt til 32 bit pr. piksel. Når det anmodes om bits fra en overflate i det opprinnelige formatet, vil overflaten bli kopiert til et buffer i det etterspurte pikselformatet ved anvendelse av et formatkonverteringsfilter.

Idet vi går til figur 5 er nok en annen Visual-underklasse HwndVisual 505, som innretter et Win32 underelement HWnd i scenegrafikkfremstillingen. Mer spesifikt vil eksisterende programmer fortsatt operere via metoden WM_PAINT (eller liknende) som tegner til et underelement-HWnd (eller liknende) basert på tidligere grafikk-tek-nologi. For å støtte slike programmer i den nye grafikkprosesseringsmodellen, tillater HwndVisual at Hwnd kan være inneholdt i en scenegrafikkfremstilling og beveges når forelder Visual-objektet blir reposisjonert, som illustrert i figur 10A. Som følge av begrensninger ved de eksisterende Hwnd-enheter, kan imidlertid en underelement-Hwnd, når den rendres, bare være på topp av andre vinduer, og kan ikke roteres eller skaleres som andre Visual-objekter beskrevet ovenfor. En viss klipping er mulig, som illustrert i figur 10B der en stiplet linje angir at HWnd-objektets viste rektangel blir klippet under relativ bevegelse i forhold til dens forelder Visual-objekt.

Andre typer Visual-objekter 506 er også mulige, og den foreliggende objektmodellen kan utvides til å muliggjøre utvikling av andre. For eksempel, som illustrert i figur 11, gjør et lagdelt Visual-objekt 1100 det mulig for en applikasjonsutvikler å på en separat måte styre informasjonen i et Visual-objekt via flere datastreamer, hvilket tilveiebringer en finere kontrollgranularitet i forhold til Visual-objekter som har én enkelt datastream. Merk at tilsvarende styringsgranularitet kan oppnås ved å ha (f.eks. tre) separate underelement Visual-objekter under ett enkelt forelder Visual-objekt, men dette krever imidlertid at programkoden jobber med flere Visual-objekter, noe som er mer komplisert enn å jobbe med ett enkelt, lagdelt Visual-objekt som har indekser til flere lag.

Eksempelvis, i figur 11, er bakgrunnsdata, innholdsdata og kantlinjedata inneholdt i ett enkelt lagdelt Visual-objekt, men er separert fra hverandre og indeksert

med en lag-verdi, f.eks. henholdsvis 0, 1 eller 2. Lag kan bli lagt til, inklusive tilknyttet i den ene eller den andre enden, og/eller slettet, idet lagrekkefølgen (f.eks. venstre-mot-høyre som vist) definerer en implisert Z-rekkefølge for fremvisning. Merk at, for

sikkerhet, innhold i underelementer og andre data i et lagdelt Visual-objekt ikke kan bli spesifisert (eng. enumeratet).

Andre typer Visual-objekter omfatter ContainerVisual-objekter og konverterte underelement HWndVisual-objekter, i hvilke innhold blir tegnet til en bitmap og innlemmet i et SurfaceVisual-objekt. Tredimensjonale Visual-objekter muliggjør en kopling mellom todimensjonale og tredimensjonale verdener, f.eks. er en kamera-liknende visning mulig via et todimensjonalt Visual-objekt som har en dimensjon inn i en tredimensjonal verden.

Mange av ressursobjektene er uforanderlige etter at de er instansiert, dvs. at de etter at de er opprettet ikke kan endres av ulike årsaker, omfattende for å forenkle prosesstråd-implementasjonen, for å hindre korruptering av andre og for å forenkle interaksjonen med elementer og API-funksjoner. Merk at dette generelt forenkler systemet. Det skal imidlertid bemerkes at det er mulig å ha et system der slike objekter er foranderlige, men dette vil for eksempel kreve administrering av et av-hengighetsdiagram. For eksempel, selv om det er mulig å ha et system der slike objekter er foranderlige, dersom programkoden endrer klippesettet i et Visual-objekt, vil Visual-objektet måtte rendres på nytt, noe som således krever en varslings / registrenngsmekanisme, f.eks. dersom en ny klippingsenhet blir tilordnet et Visual-objekt, registrerer Visual-objektet seg hos klippingsenheten for varsling (f.eks. en klipping-endret varsling). I én implementasjon, for å forenkle, er således ressursobjekter uforanderlige.

Disse ressursobjektene kan bli definert med en instansieringsfunksjon, som er en enkel, generisk måte for å opprette et objekt, eller ved anvendelse av et ledsagende bygger-objekt, som beskrevet nedenfor. For eksempel, for å instansiere et SolidColorBrush-objekt, (børste-objekter (Brush) er beskrevet nedenfor), kan det anvendes en instansieringsfunksjon: Brush MyBrush = new SolidColorBrush(Colors.Red);

Brukeren kan også anvende de statiske medlemsvariablene i Brush-klassen for å oppnå et sett av predefinerte farger.

Ettersom uforanderlige objekter ikke kan endres, må brukeren, for effektivt sett å endre et objekt, instansiere et nytt objekt og erstatte det gamle med dette. For dette formål kan mange av ressursobjektene i systemet anvende builder-mønsteret, der uforanderlige objekter blir instansiert med en bygger-klasse, som er en ledsagende klasse som er foranderlig. Brukeren instansierer et uforanderlig objekt for å avspeile parametrene som er satt i bygger-objektet, oppretter et nytt bygger-objekt for dette objektet og initialiserer det fra det uforanderlige objektet. Brukeren endrer deretter bygger-objektet som nødvendig. Når dette er utført, kan brukeren bygge et nytt objekt ved å endre bygger-objektet og gjenbruke det for å skape et annet uforanderlig objekt. Merk at det å ha uforanderlige objekter med fikserte egenskaper er ønskelig, og at uforanderlige objekter ikke kan endres, men bare erstattes ved å trigge en egenskap-endret hendelse.

Istedenfor å anvende en instansieringsfunksjon for å instansiere et SolidColorBrush-objekt som beskrevet ovenfor, kan en således anvende et SolidColorBrushBuilder-objekt: SolidColorBrushBuilder MyBuilder = new SolidColorBrushBuilder();

SolidColorBrushBuilderO;

MyBuilder.Color= Colors.Red;

Brush MyBrush = MyBuilder.ToBrush();

De fleste objekter som tar statiske verdier kan også ta animeringsobjekter.

For eksempel er det i klassen DrawingContext en redefinert metode DrawCircle som tar et PointAnimationBase-objekt som definerer sirkelens sentrum. På denne måten kan brukeren spesifisere omfattende animeringsinformasjon på det primitive nivået. For ressursobjekter eksisterer det en animeringssamling i tillegg til baseverdien. Disse blir kombinert, hvorved, dersom brukeren ønsker å animere eksempelet ovenfor, brukeren kan legge inn den følgende eksempelvise linjen før børsten blir bygget: MyBuilder.ColorAnimations.Add(new ColorAnimation(...));

Merk at et objekt med animeringsparametere fortsatt er uforanderlig ettersom dets animeringsparametere er statiske. Når scenegrafikkfremstillingen blir prosessert (f.eks. traversert), endres imidlertid betydningen til animeringsparametere overtid, hvilket gir inntrykk av animerte, ikke statiske, data.

Som beskrevet ovenfor kan Visual-objekter bli tegnet på ved å fylle deres tegnekontekster med ulike tegneprimitiver, omfattende Geometry-objekter, ImageData-objekter og VideoData-objekter. Videre finnes det et sett av ressurser og klasser som er delt gjennom hele denne stakken. Dette omfatter Pen-objekter, Brush-objekter, Geometry-objekter, Transform-objekter og Effect-objekter. IDrawingContext definerer et sett av tegneoperasjoner som kan anvendes for å fylle et DrawingVisual-objekt, et ValidationVisual-objekt. ISurfaceDrawingContext, et base-grensesnitt for IDrawing-konteksten, kan anvendes for å fylle et SurfaceVisual-objekt. Med andre ord definerer tegnekonteksten et sett av tegneoperasjoner; idet det for hver tegnoperasjon er to metoder, én som tar konstanter som argumenter og én som tar animator-objekter som argumenter.

Metoden DrawLine tegner en linje med den spesifiserte pennen fra startpunktet til endepunktet.

Metoden DrawRoundedRectangle regner et avrundet rektangel med den spesifiserte Brush-objektet og Pen-objektet; idet Brush-objektet og Pen-objektet kan være null.

Metoden DrawGeometry tegner en bane med det spesifiserte Brush-objektet og Pen-objektet; idet Brush-objektet og Pen-objektet kan være null.

Metoden DrawRectangle tegner et rektangel med det spesifiserte Brush-objektet og Pen-objektet; idet Brush-objektet og Pen-objektet kan være null.

Metoden DrawSurface tegner en overflate.

Geometry er en type klasse (figur 12) som definerer et vektorgrafikk-skjelett uten streker eller fyll. Hvert geometriobjekt er en enkel form (LineGeometry, EllipseGeometry, RectangleGeometry), en kompleks enkeltstående form (PathGeometry) eller en liste av slike former, GeometryList, med en spesifisert kombineringsoperasjon (f.eks. union, snitt, osv.). Disse objektene danner et klassehierarki, som vist i figur 12.

Som vist i figur 13 er PathGeometry er en samling av Figure-objekter. I sin tur er hvert av Figure-objektene sammensatt av ett eller flere Segment-objekter som definerer figurens form. Et Figure-objekt er en delseksjon av et Geometry-objekt som definerer en samling av segmenter. Denne segmentsamlingen er en enkeltstående forbundet serie av todimensjonale Segment-objekter. Figure-objektet kan enten være en lukket form med et definert område eller bare en forbundet serie av Segment-objekter som definerer en kurve, men ikke noe innelukket område.

Det fylte området av PathGeometry-objektet blir definert å ta de inneholdte

Figure-objektene som har sin Filled-egenskap satt til true og anvende en FillMode-verdi for å bestemme det innelukkede området. Merk at FillMode-listen spesifiserer hvordan de snittende områdene i Figure-objekter inneholdt i et Geometry-objekt er kombinert for å danne det resulterende området for Geometry-objektet. En "alterneringsregel" bestemmer hvorvidt et punkt ligger innenfor kanvasen ved konseptuelt å tegne en stråle fra det punktet til uendelig i en hvilken som helst retning og deretter undersøke de stedene der et segment av formen krysser strålen. Ved å starte med verdien null og legge til 1 hver gang et Segment krysser strålen fra venstre mot høyre og trekke fra 1 hver gang et banesegment krysser strålen fra høyre mot venstre, etter å ha talt kryssingene, dersom resultatet er null, er da punktet utenfor banen. I motsatt fall er det innenfor. En "vindingsregel" bestemmer hvorvidt et punkt på kanvasen er innenfor, og fungerer ved konseptuelt å tegne en stråle fra dette punktet til uendelig i en hvilken som helst retning og telle antallet banesegmenter fra den gitte formen som strålen krysser. Dersom dette antallet er et oddetall, er punktet innenfor; dersom det er et partall, er punktet utenfor.

Som vist i figur 14, når en geometri (f.eks. et rektangel) blir tegnet, kan det være spesifisert en børste (Brush) eller en pen (Pen), som beskrevet nedenfor. Videre har et Pen-objekt også et Brush-objekt. Et børsteobjekt definerer hvorledes et plan skal fylles grafisk, og det eksisterer et klassehierarki av børsteobjekter. Dette er illustrert i figur 14 ved det fylte rektangelet 1402 som er resultatet når det Visual-objektet som omfatter rektangel- og børste-instruksjoner og parametere blir prosessert.

Som beskrevet nedenfor setter noen typer Brush-objekter (så som GradientBrush og NineGridBrush) sin egen størrelse. Når de blir anvendt, oppnås størrelsen til disse børstene fra avgrensningsboksen. Foreksempel, når GradientUnits/DestinationUnits i Brush-objektet er satt til ObjectBoundingBox, anvendes avgrensningsboksen til det primitivet som blir tegnet. Dersom disse egenskapene er satt til UserSpaceOnUse, blir koordinatrommet anvendt.

Et Pen-objekt inneholder et Brush-objekt sammen med egenskaper for Width, LineJoin, LineCap, MiterLimit, DashArray og DashOffset, som illustrert i eksempelet nedenfor:

Som nevnt ovenfor omfatter grafikk-objektmodellen ifølge foreliggende oppfinnelse en Brush-objektmodell, som generelt er rettet mot det konsept å dekke et plan med piksler. Eksempler på typer børster er representert i hierarkiet i figur 15 og omfatter, under en baseklasse Brush, underklassene SolidColorBrush, GradientBrush, ImageBrush, VisualBrush (som kan referere et Visual-objekt) og NineGridBrush. Klassen GradientBrush omfatter LinearGradient- og RadialGradient-objekter. Som beskrevet ovenfor er Brush-objekter uforanderlige.

Det følgende viser et eksempel på BrushBuilder-klasse:

Merk at Brush-objekter kan gjenkjenne hvordan de er relatert til koordinatsystemet når de blir anvendt, og/eller hvordan de er relatert til avgrensningsboksen til den formen på hvilken de blir anvendt. Generelt kan informasjon så som størrelse oppnås fra det objektet på hvilket børsten blir tegnet. Mer spesifikt anvender mange av børste-typene et koordinatsystem for å spesifisere noen av sine parametere. Dette koordinatsystemet kan enten være definert som i forhold til den enkle avgrensningsboksen til den formen på hvilken børsten blir anvendt eller det kan være i forhold til det koordinatrommet som er aktivt på det tidspunktet børsten blir anvendt. Disse er henholdsvis kjent som ObjectBoundingBox-modus og UserSpaceOnUse-modus.

Et SolidColorBrush-objekt fyller det identifiserte planet med en heldekkende farge. Dersom det finnes en alfakomponent i fargen, blir den kombinert på en multi-plikativ måte med den motsvarende opasitets-attributen i baseklassen Brush. Det følgende viser et eksempel på SolidColorBrush-objekt:

GradientBrush-objekter, eller ganske enkelt gradienter, tilveiebringer et gradientfylling, og blir tegnet ved å spesifisere et sett av gradientstoppere som spesifiserer fargene langs en eller annen form for utvikling. Gradienten blir tegnet ved lineær interpolasjon mellom gradientstoppene i et gamma 2.2 RGB fargerom; men interpolasjon via andre gamma-fargerom eller andre fargerom (HSB, CMYK, osv., er også mulige alternativer. To typer gradient-objekter omfatter lineære og radielle gradienter.

Generelt består gradienter av en liste av gradientstopper. Hver av disse gradientstoppene inneholder en farge (med den inkluderte alfaverdien) og en forskyvning. Dersom det ikke er spesifisert noen gradientstoppere, blir børsten tegnet som ensfarget, gjennomsiktig sort, som om det ikke var spesifisert noen børste i det hele tatt. Dersom det kun er spesifisert én gradientstopp, blir børsten tegnet ensfarget i den ene fargen som er spesifisert. I likhet med andre ressurs-klasser, er klassen GradientStop (eksempelet i tabellen nedenfor) uforanderlig

Det eksisterer også en samleklasse GradientStopCollection, som angitt i det følgende eksempel:

Som representert i tabellen nedenfor spesifiserer GradientSpreadMethod hvordan gradienten skal tegnes utenfor den spesifiserte vektoren eller det spesifiserte rommet. Det er tre verdier, omfattende Pad, der kantfargene (først og sist) blir anvendt for å fylle det gjenværende rommet, Reflect, der stoppene repeteres i reversert rekkefølge gjentagelsesvis for å fylle rommet, samt Repeat, der stoppene blir gjentatt i rekkefølge inntil rommet er fylt:

Figur 16 viser eksempler på GradientSpreadMethod. Hver form har en lineær gradient som går fra hvitt til grått. Den heltrukne linjen representerer gradientvektoren.

LinearGradient spesifiserer en lineær gradientbørste langs en vektor. De individuelle stoppene spesifiserer fargestopper langs denne vektoren. Et eksempel er vist i tabellen nedenfor:

RadialGradient er tilsvarende den lineære gradienten med tanke på pro-grammeringsmodell. Men mens den lineære gradienten har et start- og et endepunkt for å definere gradientvektoren, har imidlertid den radielle gradienten en sirkel sammen med et fokuspunkt for å definere gradientens oppførsel. Sirkelen definerer gradientens endepunkt, det vil si at en gradientstopp ved 1,0 definerer fargen rundt sirkelen. Fokuspunktet definerer gradientens senter. En gradientstopp ved 0,0 definerer fargen ved fokuspunktet.

Figur 17 viser en radiell gradient som går fra hvitt til grått. Den utvendige sirkelen representerer gradientsirkelen mens prikken angir fokuspunktet. Dette eksemplet på gradient har sin SpreadMethod satt til Pad:

Et annet børsteobjekt illustrert i figur 15 er et VisualBrush-objekt. Konseptuelt tilveiebringer klassen VisualBrush en måte for å få et Visual-objekt tegnet på en gjentatt, teglet måte som en fylling. Visuelle tegneobjekter tilveiebringer også en mekanisme for formateringsspråk å jobbe direkte mot API-laget på ressursnivå, som beskrevet nedenfor. Et eksempel på et slikt fyll er illustrert i figur 14 ved den visuelle børsten som omfatter en referanse til et Visual-objekt (og eventuelle inneholdte Visual-objekter) og som spesifiserer en enkeltstående sirkulær form 1420, idet denne sirkulære formen fyller et rektangel 1422. VisualBrush-objektet kan således referere til et Visual-objekt for å definere hvordan denne børsten skal tegnes, hvilket introduserer en type flerbruk for Visual-objekter. På denne måten kan et program anvende en vilkårlig "grafikk-metafil" for å fylle et område via en børste eller en penn. Siden dette er en komprimert form for lagring og anvendelse av vilkårlig grafikk, tjener den en grafikkressurs. Det følgende illustrerer et eksempel på klassen VisualBrush:

Et VisualBrush-objekt sitt innhold har ingen iboende grenser, og beskriver effektivt et uendelig plan. Dette innholdet eksisterer i sitt eget koordinatrom, og det rommet som blir fylt av VisualBrush-objektet er det lokale koordinatrommet på det tidspunktet det blir anvendt. Innholdsrommet blir avbildet inn i det lokale rommet basert på egenskapene ViewBox, ViewPort, Alignments og Stretch. ViewBox er spesifisert i innholdsrommet, og dette rektangelet blir avbildet inn i ViewPort (som spesifisert via egenskapene Origin og Size)-rektangelet.

ViewPort definerer den posisjon hvor innholdet til slutt vil bli tegnet, hvilket definerer base-teglen for dette Brush-objektet. Dersom verdien til DestinationUnits er UserSpaceOnUse, blir egenskapene Origin og Size tatt i forhold til det lokale rommet ved anvendelsestidspunktet. Dersom istedet verdien til DestinationUnits er ObjectBoundingBox, blir da Origin og Size tatt i forhold til koordinatrommet, der 0,0 er det øvre venstre hjørnet av avgrensningsboksen til det objektet som tegnes og 1,1 er det nedre høyre hjørnet av samme boks. Betrakte for eksempel at et RectangleGeometry blir fylt som er tegnet fra 100,100 til 200,200.1 et slikt eksempel, dersom DestinationUnits har verdien UserSpaceOnUse, vil Origin 100,100 og Size 100,100 beskrive hele innholdsområdet. Dersom DestinationUnits har verdien ObjectBoundingBox, vil Origin 0,0 og Size 1,1 beskrive hele innholdsområdet. Dersom Size-egenskapen er tom vil ikke dette Brush-objektet rendre noe som helst.

ViewBox er spesifisert i innholdsrommet. Dette rektangelet blir transformert slik at det passer innenfor ViewPort som bestemt ved Alignments-egenskapene og Stretch-egenskapen. Dersom Stretch har verdien None, blir det ikke anvendt noen skalering på innholdet. Dersom Stretch har verdien Fill, blir da ViewBox skalert uav-hengig i både X og Y til samme størrelse som ViewPort. Dersom Stretch har verdien Uniform eller UniformToFill, er logikken tilsvarende, men X og Y dimensjonene blir skalert likt, hvilket bevarer innholdets høyde/breddeforhold. Dersom Stretch har verdien Uniform, blir ViewBox skalert til å ha den mer restrikterte dimensjonen lik ViewPort sin størrelse. Dersom Stretch har verdien UniformToFill, blir ViewBox skalert til å ha den mindre restrikterte dimensjonen lik ViewPort sin størrelse. Med andre ord bevarer både Uniform og UniformToFill høyde/breddeforholdet, men Uniform sikrer at hele ViewBox ligger innenfor ViewPort (muligens med deler av ViewPort etterlatt utildekket av ViewBox) og UniformToFill sikrer at hele ViewPort blir fylt av ViewBox (og forårsaker muligens at deler av ViewBox ligger utenfor ViewPort). Dersom ViewBox er tom, vil ikke Stretch bli anvendt. Merk at oppstillingen (alignment) fortsatt vil bli utført, og den vil posisjonere den "punktformige" ViewBox-enheten.

Figur 18 viser illustrasjoner av en enkelt tegl 1800 av grafikk rendret med ulike Stretch-settinger, omfattende en tegl 800 når stretch er satt til "None". Teglen 1802 illustrerer når Stretch-verdien er satt til "Uniform", teglen 1804 når Stretch-verdien er satt til "UniformToFill", og teglen 1806 når Stretch-verdien er satt til "Fill".

Når ViewPort er bestemt (basert på DestinationUnits) og ViewBox sin størrelse er bestemt (basert på Stretch), må ViewBox posisjoneres inne i ViewPort. Dersom ViewBox har samme størrelse som ViewPort (dersom Stretch har verdien Fill eller dersom det bare skjer rent tilfeldig med én av de andre tre mulige Stretch-verdiene), blir ViewBox posisjonert i origo slik at den er identisk med ViewPort. I motsatt fall betraktes HorizontalAlignment og VerticalAlignment. Basert på disse egenskapene blir ViewBox innrettet i både X og Y dimensjonene. Dersom HorizontalAlignment har verdien Left, vil da den venstre kanten av ViewBox bli posisjonert ved den venstre kanten av ViewPort. Dersom den har verdien Center, vil da senteret av ViewBox bli posisjonert i senteret av ViewPort, og dersom den har verdien Right, vil da de høyre kantene møtes. Prosessen gjentas for Y-dimensjonen.

Dersom ViewBox er (0,0,0,0), betraktes den som ikke satt, hvorved ContentUnits blir betraktet. Dersom ContentUnits har verdien UserSpaceOnUse, ut-føres det ingen skalering eller forskyvning, og innholdet blir tegnet inn i ViewPort uten transformasjon. Dersom ContentUnits har verdien ObjectBoundingBox, blir da innholdets origo innrettet etter ViewPort sin origo, og innholdet blir skalert med bredden og høyden til objektets avgrensningsboks.

Ved fylling av et rom med et VisualBrush-objekt, blir innholdet avbildet inn i ViewPort som ovenfor og klippet til ViewPort. Dette danner base-teglen for fyllingen og resten av rommet blir fylt basert på Brush-objektets TileMode-verdi. Endelig, dersom den er satt, blir Brush-objektets transform anvendt - dette skjer etter alle andre avbildninger, skaleringer, forskyvninger, etc.

TileMode-listen blir anvendt for å beskrive om og hvordan et rom skal fylles med dens Brush-objekt. Et Brush-objekt som kan være teglet har et tegl-rektangel definert, og denne teglen har en baseposisjon innenfor det rommet som blir fylt. Resten av rommet blir fylt basert på TileMode-verdien. Figur 19 viser et eksempel på grafikk med ulike TileMode-settinger, omfattende "None" 1900, "Tile" 1902, "FlipX" 1904, "FlipY" 1906 og "FlipXY" 1908. Den øverste teglen lengst til venstre i de ulike grafikkeksemplene utgjør base-teglen. Figur 20 illustrerer en prosess for generering av pikslene for denne børsten Merk at logikken beskrevet i figur 20 bare er én mulig måte å implementere logikken, og det må forstås at andre måter, omfattende mer effektive måter, er mulige. For eksempel vil det sannsynligvis være mer effektive måter å prosessee dataene, f.eks. slik at innholdet ikke blir tegnet for hver repetisjon, idet teglen blir tegnet og bufret.

Figur 20 illustrerer imidlertid en enkel implementasjon.

Generelt blir det dannet et nytt koordinatsystem hver gang innholdet i møn-steret blir tegnet. Origo og forskyvningen for hver repetisjon spesifiseres av egenskapene Origin og Size, filtrert gjennom egenskapene DestinationUnits og Transform.

Et koordinatsystem blir satt opp basert på egenskapen DestinationUnits. For dette formål, dersom DestinationUnits-egenskapen i trinn 2000 har verdien UserSpaceOnUse, er det aktive koordinatsystemet på det tidspunktet børsten ble anvendt start-koordinatsystemet, via trinn 2002. Dersom istedet i trinn 2004 egenskapen har verdien ObjectBoundingBox, anvendes avgrensningsboksen til den geometrien på hvilken denne børsten blir anvendt, som representert ved trinn 2004, for å sette et nytt koordinatsystem som er slik at det øvre venstre hjørnet av avgrensningsboksen avbildes til (0,0) og det nedre venstre hjørnet av avgrensningsboksen avbildes til (1,1). I begge tilfeller blir i trinn 2006 Transform-egenskapen anvendt på dette koordinatsystemet, hvilket i det vesentlige definerer et gridd.

Figur 21 illustrerer et VisualBrush gridd som er definert for teglene i et VisualBrush-objekt. Den første sirkelen er et enkelt grid og den andre har en Transform med en skjevhet i x-retning på 47.

I trinn 2008 blir Visual-objektet tegnet inn i hver celle av griddet, som illustrert i figur 22, der Visual-objektet tegner de ønskede dataene. Dersom det i trinn 2010 er spesifisert en ViewBox, blir Visual-objektet passet til i gridd-cellen som spesifisert av attributtene ViewBox, Stretch, HorizontalAlign og VerticalAlign, via trinn 2012. Egenskapene DestinationUnits og Transform blir benyttet til å anvende den korrekte transformen slik at Visual-objektet innrettes i griddboksen.

Dersom det ikke er spesifisert en ViewBox, blir det da opprettet et nytt koordinatsystem for tegning av innholdet i trinn 2014.

Koordinatsystemet blir satt slik at dets origo befinner seg i origo-punktet for den spesifikke gridd-cellen som blir tegnet.

En klipping blir anvendt i trinn 2018 basert på Size-egenskapen, slik at denne teglen ikke vil bli tegnet utenfor cellens grenser. Origin og Size blir modifisert på passende måte basert på egenskapen DestinationUnits.

Koordinatsystemet blir deretter modifisert basert på SourceUnits-egenskapen. For dette formål, dersom i trinn 2020 SourceUnits-egenskapen har verdien ObjectBoundingBox, blir den korrekte skaleringstransformasjonen anvendt i trinn 2026, ellers har den verdien UserSpaceOnUse, og ingen ny transformasjon blir anvendt. Egenskapen Transform blir anvendt i trinn 2024, og innholdet blir tegnet i trinn 2026.

Merk at dersom en hvilken som helst del av størrelsen er null, blir ingenting tegnet, og dersom Stretch har verdien "None", blir transformasjonen av visningsboksen satt opp slik at én enhet i det nye koordinatsystemet er lik én enhet i det gamle koordinatsystemet. Transformen blir hovedsaklig en forskyvning basert på Align-attributtene og størrelsen til ViewBox. Som beskrevet ovenfor i trinnene 2010 og 2012, anvendes egenskapene Stretch og Alignment bare når det er spesifisert en ViewBox. ViewBox spesifiserer et nytt koordinatsystem for innholdet, og Stretch bidrar til å spesifisere hvordan dette innholdet avbildes inn i ViewBox. Opp-stillingsmulighetene innretter ViewBox, ikke innholdet. For eksempel, dersom visningsboksen er satt til "0 0 10 10" og noe blir tegnet ved -10,-10 og oppstilt etter det øvre venstre hjørnet, vil således dette noe bli klippet ut.

Tlbake til figur 15 kan klassen ImageBrush tenkes på som et spesialtilfelle av VisualBrush. Selv om et program kan instansiere et Visual-objekt, legge inn et bilde i det og knytte det til et VisualBrush-objekt, ville API-grensesnittet for å gjøre dette være tungvint. Siden det ikke er noe nødvendig innhold-koordinatsystem, blir ikke lenger medlemsegenskapene ViewBox og ContentUnits anvendt.

Klassen NineGridBrush er veldig lik ImageBrush, bortsett fra at bildet blir fordreiet basert på størrelsen. Essensielt kan klassen NineGridBrush tenkes på som en spesialisert type av Stretch, i hvilken visse deler av bildet blir strukket mens andre (f.eks. kantlinjer) ikke gjør det. Mens bildets størrelse i ImageBrush vil forårsake en enkel skala, vil således NineGridBrush produsere en ikke-uniform skala opp til den ønskede størrelsen. Enhetene for de ikke-skalerte områdene er brukerenhetene når børsten blir anvendt, hvilket betyr at egenskapen ContentUnits (dersom den eksisterte for NineGridBrush) ville være satt til UserUnitsOnUse. Transform-egenskapen til Brush-objektet kan anvendes effektivt. Merk at kantlinjemedlemmene teller innover fra bildets kant.

Som et eksempel illustrerer figur 23 et ni-griddet bilde som blir forstørret fra en første instans 2302 til en andre instans 2304, med fire typer av områder. Som illustrert i figur 23, for å holde kantlinjen lik, blir områdene merket "a" ekspandert horisontalt, områdene merket "b" ekspandert vertikalt, områdene merket "c" ekspandert horisontalt og vertikalt og områdene merket "d" endrer ikke størrelse.

Som beskrevet generelt ovenfor, omfatter grafikk-objektmodellen ifølge foreliggende oppfinnelse en Transform-objektmodell, som omfatter de typer transformasjoner som er illustrert i hierarkiet i figur 24 under en baseklasse Transform. Disse ulike typene komponenter som utgjør en transformasjon kan omfatte klassene TransformList, TranslateTransform, RotateTransform, ScaleTransform, SkewTransform og MatrixTransform. Individuelle egenskaper kan bli animert; f.eks. kan en programutvikler animere egenskapen Angle i et objekt av klassen RotateTransform.

Matriser for 2D beregninger er representert som en 3x3 matrise. For de nød-vendige transformasjoner er kun seks verdier nødvendige istedenfor en full 3x3 matrise. Disse er navnet og definert som følger.

Når en matrise blir multiplisert med et punkt, transformerer den dette punktet fra det nye koordinatsystemet til det tidligere koordinatsystemet:

Transformasjoner kan bli nestet til et hvilket som helst nivå. Når en ny transformasjon blir anvendt er det det samme som å post-multiplise den på den gjeldende transformasjonsmatrisen:

De fleste steder tar ikke API-grensesnittet en matrise direkte, men anvender i stedet Transform-klassen, som støtter animering.

FORMATERINGSSPRÅK OG OBJEKTMODELL FOR VEKTORGRAFIKK

I henhold til et aspekt ved foreliggende oppfinnelse tilveiebringes et formateringsspråk og en element-objektmodell for å gjøre det mulig for brukerpro-grammer og verktøy å vekselvirke med scenegrafikk-datastrukturen 216 uten å kreve spesifikk kunnskap om detaljene i API-laget 212 (figur 2). Generelt tilveiebringes et vektorgrafikk-formateringsspråk som omfatter et utvekslingsformat sammen med et enkelt kodebasert format for å uttrykke vektorgrafikk via element-objektmodellen. Via dette språket kan formatkode (f.eks. HTML- eller XML-type innhold) bli programmert. Deretter, for å bygge scenegrafikkfremstillingen, blir formatkoden parset og oversatt til de passende API-objekter som er som beskrevet ovenfor. På dette høyere abstraksjonsnivået er det tilveiebrakt et elementtre, et egenskapsystem og et presenteringssystem for å håndtere mye av kompleksiteten, hvilklet gjør det enkelt for scenedesignere å konstruere muligens komplekse scener.

Generelt tilveiebringer vektorgrafikk-systemet et sett av former og andre elementer, integrering med et generelt egenskapsystem, et grupperings- og sammensettingssystem og en to-delt (elementnivå og ressursnivå) tilnærming slik at brukeren kan programmere på en måte som imøtekommer behovene for fleksibilitet og ytelse. I overensstemmelse med ett aspekt ved foreliggende oppfinnelse korrelerer element-objektmodellen for å håndtere vektorgrafikk med scenegrafikk-objektmodellen. Med andre ord deler vektorgrafikk-systemet og visual-API laget et sett av ressurser på element-objektmodellnivået, f.eks. blir Brush-objektet anvendt ved tegning via visual-API grensesnittet og er samtidig også typen fyllings-egenskap i form-objektet (Shape). I tillegg til å ha elementer som korrelerer med scenegrafikkobjektene, deler således formateringsspråket et antall primitive ressurser (f.eks. børster, transformasjoner, osv.) med visual-API laget. Vektorgrafikksystemet eksponerer og utvider også animeringsmulighetene i visual-API laget, som i stor grad er delt mellom nivåene.

Videre, som beskrevet nedenfor, kan vektorgrafikksystemet programmere til ulike profiler, eller nivåer, omfattende et elementnivå og et ressursnivå. På elementnivå er hver av tegneformene representert som et element på samme nivå som resten av de programmerbare elementene i en side/et skjermbilde. Dette betyr at formene vekselvirker fullt med presenteringssystemet, hendelser og egenskaper. På ressursnivået opererer vektorgrafikk-systemet i et rent ressursformat, tilsvarende en tradisjonell grafikk-metafil. Ressursnivået er effektivt, men har noe begrenset støtte for kaskadede egenskaper, hendelsesbehandling og detaljert programmerbarhet. Scenedesigneren har således mulighet for å avveie effektivitet mot programmerbarhet etter behov.

I overenstemmelse med ett aspekt ved foreliggende oppfinnelse, korrelerer vektorgrafikk-systemet på ressursnivå også med visual-API laget i det at ressursnivå-formatkode, i én implementasjon, blir uttrykt ved et VisualBrush-objekt. Når ressurs-formatkoden parses, blir det dannet et Visual-objekt. Visual-objektet blir satt inn i et VisualBrush-objekt som kan anvendes av former, kontroller og andre elementer på elementnivå.

Figur 25 er en illustrasjon av element-klassehierarkiet 2500. Klassene i formateringsspråk-objektmodellen ifølge foreliggende oppfinnelse er representert ved skyggede bokser, og omfatter en klasse Shape 2502, en klasse Image 2504, en klasse Video 2506 og en klasse Canvas 2508. Elementer i klassen Shape omfatter Rectangle 2510, Polyline 2512, Polygon 2514, Path 2516, Line 2518 og Ellipse 2520. Merk at det i noen implementasjoner ikke trenger å være tilveiebrakt et sirkelelement, som angitt ved den stiplede boksen 2522 i figur 25, men for formålet med de ulike eksemplene her vil imidlertid sirkelelementet 2522 bli beskrevet. Hvert element kan omfatte eller være assosiert med fyll(egenskap)-data, strekdata, klippingsdata, transformasjonsdata, filtereffektdata og maskedata.

Som beskrevet nedenfor svarer former, dvs. Shape-objekter, til geometri som blir tegnet med arvede og kaskadede presenteringsegenskaper. Presenteringsegen-skapene blir anvendt for å konstruere den pennen (Pen) og børsten (Brush) som er nødvendig for å tegne formen. I én implementasjon er former fulle presentererings-enheter, som andre kontroll-elementer. I andre implementeringer kan det imidlertid være tilveiebrakt en klasse Cavnas 2508 som en container for former, og former kan bare tegnes når de befinner seg i et kanvaselement. For eksempel, for å holde formene som lettvekterobjekter, kan disse forbys å ha tilknyttet presenteringsenheter. Istedet har kanvasen en tilknyttet presenteringsenhet og tegner formene. Canvas-elementer er beskrevet mer detaljert nedenfor.

Som også beskrevet nedenfor er klassen Image mer spesifikk enn Shape, og kan for eksempel omfatte kantlinjedata som kan være komplekse. For eksempel kan en kantlinje være spesifisert som én farge øverst og en ulik farge på sidene, eventuelt med ulike tykkelser spesifisert og andre egenskaper satt. Posisjon, størrelse, rotasjon og skala kan være satt for et Image-objekt eller et tilsvarende BoxedElement, så som Text eller Video. Merk at bilde- og videoelementene kan eksistere og bli vist utenfor et kanvaselement, og også arve fra BoxedElement, f.eks. for å oppnå bakgrunnen, kantlinjer og fyllingsstøtte fra det elementet.

Videoelementet gjør at video (eller tilsvarende multimedia) kan spilles av innenfor et vist element. På denne måten tilveiebringer vektorgrafikk-systemet et formatkode-grensesnitt mot API-laget som er sømløst konsekvent på tvers av multimedia, omfattende tekst, 2D-grafikk, 3D-grafikk, animering, video, stillbilder og lyd. Dette gjør det mulig for designere som lærer å jobbe med ett medium å på en enkel måte integrere andre medier i applikasjoner og dokumenter. Vektorgrafikk-systemet gjør det også mulig å animere multimedia på samme måte som andre elementer, slik at designere kan anvende multimedia som andre elementer, uten å ofre de unike kjerne-særegenhetene ved hver individuelle mediatype. For eksempel kan en desig-ner anvende samme navneskjema for rotering, skalering, animering, tegning, sammensetting og andre effekter på tvers av ulike mediatyper, hvorved designere på en enkel måte kan skape meget sofistikerte applikasjoner, så vel som å muliggjøre bygging av en meget effektiv underliggende rendrings- og sammensettings-implementasjon.

Figur 26 illustrerer én implementasjon der formatkoden 2602 blir interpretert av en parser / oversetter 2604. Generelt legger parser / oversetter 2604 til elementer i et elementtre / egenskapsystem 208 (også representert i figur 2) og tilknytter presenteringsenheter til disse elementene. Presenteringssystemet 210 tar deretter elementtreet 210 med de tilknyttede presenteringsenhetene og oversetter dataene til objekter og kall til funksjoner i visual-API laget 212. Merk at ikke alle elementer trenger å bli oversatt, bare de med tilknyttede presenteringsenheter.

Generelt er et element et objekt i element-laget som deltar i egenskapsystemet, hendelsesbehandling og layout/presenteringssystemet. Parseren finner formatkodeetiketter og avgjør om disse formatkodeetikettene er med på å definere et element eller et ressursobjekt. I det spesifikke tilfellet med et VisualBrush-objekt kan samme formatkodeetiketter tolkes som elementer eller også tolkes som ressursobjekter, avhengig av i hvilken sammenheng formatkodeetikettene opptrer, f.eks. avhengig av hvorvidt de opptrer i en kompleks egenskapsyntaks eller ikke.

I henhold til ett aspekt ved foreliggende oppfinnelse tilveiebringer formateringsspråket ulike måter for å beskrive en ressurs, omfattende et enkelt datastrengformat eller en kompleks objektnotasjon. For et enkel datastrengformat anvender parser / oversetter 2604 en typeomformer 2608 for å konvertere en datastreng til et motsvarende visual-API objekt. Som et eksempel, i den følgende linjen av formatkode, kan Fill-egenskapverdien bli konvertert til et børsteobjekt via typeomformeren 2608:

Som en lett forstår er det å konvertere en slik in-line linje av etikett-basert formatkode med enkle strenger av parametere til et børsteobjekt enkelt, og tilveiebringer en enkel måte for en scenedesigner å legge til en form og dens attributer til en scene.

Det kan imidlertid forekomme at fyllingsattributen er for kompleks til å passe inn i en enkelt streng. I et slikt tilfelle blir kompleks egenskapsyntaks, som kan være in-line i formatkoden, anvendt for å sette denne egenskapen. For eksempel fyller den følgende den komplekse egenskapsyntaksen en sirkel med en gradient heller enn en énkelt fargetone, idet fargene spesifiseres ved ulike gradientstopper (som kan være i området fra 0 til 1):

I tillegg til å være til stede in-line i formatkoden, kan en ressurs-instans være lokalisert et annet sted (f.eks. i formatkoden eller i en fil, som kan være lokal eller i et fjem-nettverk og bli lastet ned når den trengs) og refereres til ved et navn (f.eks. et tekstnavn, en referanse eller en annen egnet identifikator). På denne måten kan en scenedesigner gjenbruke et element i elementtreet gjennom en hel scene, inklusive elementer beskrevet med den komplekse egenskapsyntaksen.

Parseren håndterer formatkode i den komplekse egenskapsyntaksen ved å aksessere typeomformeren 2608 som nødvendig og også ved å sammenlikne spesifiserte parametere med objekt-egenskapene, og håndterer med det kompleksiteten for scenedesigneren. Parseren setter således ikke bare opp objektene, men setter også attributter i objektene. Merk at parseren faktisk instansierer et byggerobjekt for å opprette objektene, ettersom objekter er uforanderlige.

Ettersom samme rendringsmodeli deles mellom mellom elementnivået og API-nivået, er mange av objektene hovedsaklig de samme. Dette gjør parsingen / oversettingen meget effektiv, og gir også ulike typer programmeringsspråk (f.eks. C#-liknende språk) mulighet for på en enkel måte å konvertere fra formatkoden til sin egen syntaks og omvendt. Merk at som illustrert i figur 26, et annet slikt programmeringsspråk 2610 kan legge til elementer i elementtreet 208 eller kan grensesnitte direkte mot visual-API laget 212.

Som også illustrert i figur 26, og i overensstemmelse med et aspekt ved foreliggende oppfinnelse, kan samme formatkode 2602 anvendes for å programmere på elementnivå og ressursnivå. Som beskrevet ovenfor gir elementnivået scenedesigneren full programmerbarhet, anvendelse av egenskapsystemet som tilveiebringer arv (f.eks. style-sheet liknende egenskaper) og hendelsesbehandling (hvorved et element for eksempel kan ha tilknyttet kode for å endre sitt utseende, sin posisjon, osv. i respons til en brukerinndata-hendelse). Foreliggende oppfinnelse tilveiebringer imidlertid også en ressursnivå-mekanisme med hvilken scenedesignerne essensielt kan forenkle eller omgå elementtreet og presenteringssystemet og programmere direkte mot visual-API laget. For mange typer statiske former, bilder og lignende der elementnivå-særegenheter ikke er nødvendige, tilveiebringer dette en mer effektiv og lettere måte å utmate det ønskede objektet. For dette formål detek-terer parseren når et fyll av typen "visuell børste" er til stede og kaller direkte API-laget 212 med ressursnivådata 2612 for å generere objektet. Med andre ord, som illustrert i figur 22, blir elementnivå-vektorgrafikk parset til genererte elementer som senere må oversettes til objekter, mens ressursnivå-vektorgrafikk blir parset og direkte lagret på en effektiv måte.

Som et eksempel er den følgende formatkode direkte avledet fra objektmodellen for LinearGradient-objektet, og fyller en ytre sirkel med et VisualBrush-objekt. Innholdet i dette VisualBrush-objektet er definert i den indre formatkoden. Merk at denne syntaksen er vanlig å anvende for å uttrykke ulike børster, transformasjoner og animeringer:

Merk at selv om disse VisualBrush-fylte objektene blir lagret på en effektiv måte, kan ressursnivådata (eller objektene som opprettes fra disse) refereres til av elementer og deler av elementtreet 208, som illustrert generelt i figur 26. For dette formål kan disse VisualBrush-ressursene bli navnet (f.eks. med et navn, en referanse eller en annen egnet identifikator) og referert til på samme måte som andre ressurser som er beskrevet via den komplekse egenskapsyntaksen.

Idet en går til en forklaring av kanvasen kan, som nevnt ovenfor i én alternativ implementasjon, formene holdes enkle og således måtte være inneholdt i en kanvas. I denne alternative implementasjonen, når innhold blir rendret, blir det rendret på en uendelig, anordningsuavhengig kanvas som har et assosiert koordinatsystem. Kanvaselementet kan således posisjonere innhold i henhold til absolutte koordinater. Kanvaselementet kan eventuelt definere et synsfelt, som spesifiserer klipping, en transformasjon, et foretrukket høyde/bredde-forhold og en måte for avbildning av synsfeltet til et forelderrom. Dersom det ikke er etablert noe synsfelt, spesifiserer kanvaselementet bare en gruppering av tegneprimitiver, og kan sette opp en transformasjon, opasitet og andre settingsattributter.

Det følgende er et formatkodeeksempel for en mulig kanvas:

Merk at i én implementasjon, når koordinater blir spesifisert uten enheter, så blir de betraktet som "logiske piksler" på 1/96 av en tomme, og i eksempelet ovenfor vil linjen vil være 200 piksler lang. I tillegg til koordinater omfatter andre egenskaper bredde, høyde, horisontal og vertikal innretting og ViewBox (av type rektangel; standardverdi er ikke-satt eller (0,0,0,0), hvilket betyr at ingen justering blir gjort og at strekk- og oppstillingsegenskapene blir ignorert). Som beskrevet generelt ovenfor med henvisning til figurene 18-20, omfatter andre egenskaper Stretch, som når den ikke er spesifisert bevarer opprinnelig størrelse eller kan: 1) spesifisere Fill, der høyde/bredde-forholdet ikke bevares og innholdet blir skalert for å fylle avgrensningene som etableres av topp/venstre/bredde/høyde, 2) spesifisere Uniform, som skalerer størrelsen uniformt inntil bildet passer innenfor grensene som etableres av topp/venstre/bredde/høyde eller 3) spesifisere UniformToFill, som skalerer størrelsen uniformt for å fylle avgrensningene som etableres av topp/venstre/bredde/høyde og klipper som nødvendig.

For ytterligere å samsvare med den lavere-nivå objektmodellen, etablerer transformasjonsegenskapen et nytt koordinatsystem for elementets underelementer, mens klippingsegenskapen begrenser området til hvilket innhold kan bli tegnet på kanvasen, idet den standard klippingsbanen er definert som avgrensningsboksen. Egenskapen Zlndex kan anvendes for å spesifisere rendringsrekkefølgen for nestede kanvaselementer innenfor et panel.

Viewbox spesifiserer et nytt koordinatsystem for innholdet, f.eks. ved å rede-finere synsfeltets utstrekning og origo. Stretch bidrar til å spesifisere hvordan dette innholdet avbildes inn i synsfeltet. Verdien til ViewBox-attributen er en liste av fire "enhetsløse" tall <min-x>, <min-y>, <bredde> og <høyde>, f.eks. separert av mellom-rom og/eller et komma, og er av typen Rect. ViewBox-rektangelet spesifiserer det rektangelet i brukerrommet som avbilder til avgrensningsboksen. Den fungerer på samme måte som innsetting av scaleX og scaleY. Egenskapen Stretch (dersom verdien er ulik fra None) tilveiebringer ytterligere kontroll for å bevare høyde/breddefor-holdet for grafikken. En ytterligere transformasjon blir anvendt på avledere av det gitte elementet for å oppnå den spesifiserte effekten.

I eksempelet ovenfor ville det effektive resultatet av rektangelet i formatkode-eksempelet ovenfor under hver ekspansjonsregel være:

Dersom det eksisterer en transformasjon på kanvasen, blir den essensielt anvendt over (f.eks. i treet) avbildningen til ViewBox. Merk at denne avbildningen vil

strekke ethvert element i en kanvas, f.eks. bokser, tekst, osv, ikke bare former. Merk videre at dersom det er spesifisert en ViewBox, kanvasen ikke lenger blir gitt størrel-se etter sitt innhold, men i stedet får en spesifisert størrelse. Dersom y-bredden og y-høyden også er spesifisert, blir da strekk- og oppstillingsegenskapene anvendt for å innpasse ViewBox i den spesifiserte bredden og høyden.

Elementene i objektmodellen kan hvert ha en "klippingsattributt (Gip)" anvendt. I noen elementer, i særdeleshet former, er dette eksponert direkte som en felles språk-kjøretidsegenskap, mens i andre (f.eks. de fleste kontroller) denne egenskapen blir satt via et DynamicProperty.

Generelt begrenser klippingsbanen det området innenfor hvilket innhold kan bli tegnet, som illustrert generelt i figur 27 der en kontrollknapp er vist i ikke-klippet form 2702 og en form 2704 der det er spesifisert en klippingsbane (idet den stiplede linjen representerer klippingsbanen). Konseptuelt sett blir ikke noen del av tegningen som befinner seg utenfor området som avgrenses av den aktive klippingsbanen tegnet. En klippingsbane kan tenkes på som en maske der de pikslene som ligger utenfor klippingsbanen er sorte med alfaverdi null og pikslene innenfor klippingsbanen er hvite med alfverdi 1 (med det mulige unntak av antialiasing langs kanten av silhuetten).

En klippingsbane defineres av et Geometry-objekt, enten in-line eller mer typisk i en ressurs-seksjon. En klippingsbane blir anvendt og/eller referert til ved anvendelse av "Clip"-egenskapen i et element, som vist i det følgende eksempelet:

Merk at det å animere Clip er tilsvarende det å animere transformasjoner:

En bane blir tegnet ved å spesifisere "Geometry"-data og rendringsegen-skapene, så som Fill, Stroke og StrokeWidth i Path-elementet. Et eksempel på formatkode for en bane er gitt som følger:

Path-strengen "Data" er av typen Geometry. En mer ordrik og fullstendig måte for å spesifisere en tegnet bane er via den komplekse egenskapsyntaksen, som beskrevet ovenfor. Formatkoden (så som i det følgende eksempelet) blir matet direkte inn i Geometry-byggerklassene beskrevet ovenfor:

Path-strengen data blir også beskrevet, ved anvendelse av den følgende notasjonen for å beskrive grammatikken for denne:

Det følgende viser informasjon i Path-strengen data beskrevet med denne notasjonen (merk at i én implementasjon kan FillMode være spesifisert her istedenfor en egenskap på elementnivå):

Elementet Image (figur 25) angir at innholdet i en hel fil skal rendres til et gitt rektangel innenfor det gjeldende bruker-koordinatsystemet. Bildet (angitt av Image-formatkodeetiketten) kan referere til rasterbildefiler, så som PNG eller JPEG, eller til filer med MIME type "image/wvg", som illustrert i det følgende eksempelet:

Den følgende tabellen tilveiebringer informasjon om noen eksempler på egenskaper for bilder:

Som beskrevet ovenfor svarer former til geometri som blir tegnet med arvede og kaskadede presenerteringsegenskaper. De følgende tabellene illustrerer eksempler på form-egenskaper for de grunnleggende form-elementene beskrevet ovenfor (Rectangle, Ellipse, Line, Polyline, Polygon). Merk at disse grunnleggende formene kan ha strek-egenskaper, fyllings-egenskaper og bli anvendt som klippebaner, har

arv-karakteristika og har gyldighet for både element- og ressursnivåene:

Det følgende er et eksempel på formatkodesyntaks for et rektangel:

Et rektangel har følgende egenskaper i objektmodellen (merk at rektangler er lesbare/skrivbare, har standardverdier lik null, støtter arv og har gyldighet for både element- og ressursnivå):

Det følgende er et eksempel på formatkodesyntaks for en sirkel:

En sirkel har følgende egenskaper i objektmodellen (merk at sirkler er lesbare/skrivbare, har standardverdier lik null, støtter arv og har gyldighet for både element- og ressursnivå):

Det følgende er et eksempel på formatkodesyntaks for en ellipse:

En ellipse har følgende egenskaper i objektmodellen (merk at ellipser er lesbare/skrivbare, har standardverdier lik null, støtter arv og har gyldighet for både element- og ressursnivå):

Det følgende er et eksempel på formatkodesyntaks for en linje:

En linje har følgende egenskaper i objektmodellen (merk at linjer er lesbare/skrivbare, har standardverdier lik null, støtter arv og har gyldighet for både element- og ressursnivå):

En "polylinje" definerer et sett av forbundede, rette linjesegmenter. En "polylinje" definerer typisk en åpen form.

Det følgende er et eksempel på formatkodesyntaks for en polylinje:

En polylinje har følgende egenskaper i objektmodellen (merk at linjer er lesbare/skrivbare, har standardverdier lik null, støtter arv og har gyldighet for både element- og ressursnivå):

Polygon-elementet definerer en lukket form som omfatter et sett av forbundne, rette linjesegmenter. Det følgende er et eksempel på formatkodesyntaks for et polygon:

Et polygon har følgende egenskaper i objektmodellen (merk at polylinjer er lesbare/skrivbare, har standardverdier lik null, støtter arv og har gyldighet for både element- og ressursnivå):

Grammatikken for punktspesifiseringer i "Polyline"- and "Polygon"-elementer er beskrevet med følgende notasjon:

Det følgende beskriver punktspesifikasjoner "Polyline"- og "Polygon"-elementer ved anvendelse av notasjonen ovenfor:

KONKLUSJON

Som kan sees fra den foregående detaljerte beskrivelsen er det tilveiebrakt et system, en fremgangsmåte og en element-/objektmodell som tilveiebringer program-koder med ulike mekanismer for å grensesnitte mot en scenegrafikkfremstilling. Systemet, fremgangsmåten og objektmodellen er enkle å anvende, men likevel kraftige, fleksible og utvidbare.

Selv om oppfinnelsen er mottakelig for ulike modifikasjoner og alternative konstruksjoner, er noen illustrerte utførelsesformer vist i figurene og beskrevet ovenfor i detalj, noe som ikke skal begrense oppfinnelsen til de spesifikke beskrevne utførel-sesformene, men tvert imot er intensjonen å dekke alle modifikasjoner, alternative konstruksjoner og ekvivalenter som ligger innenfor oppfinnelsens definisjon slik den er gitt i de vedføyde patentkrav.

Claims

1. System i et databehandlingsmiljø, karakterisert ved: en mekanisme som interpreterer formatkode for å konstruere et tre av elementer, idet i hvert fall noen av elementene i elementtreet har assosierte egenskapdata og svarer til en element-objektmodell; et scenegrafikkfremstilling-grensesnittslag som omfatter et sett av minst ett grensesnitt som fyller en scenegrafikkfremstilling med objekter i respons til fore-spørseler om å opprette objektene, idet objektene svarer til en scenegrafikk-objektmodell; og en oversetter som oversetter i hvert fall noen av elementene og egenskapdata i elementtreet til forespørseler til scenegrafikk-grensesnittslaget om å opprette objekter i scenegrafikkfremstillingen.

2. System ifølge krav 1, der elementene i element-objektmodellen i vesentlig grad samsvarer med objektene i scenegrafikk-objektmodellen.

3. System ifølge krav 1, der formatkoden omfatter in-line tekst som omfatter en datastreng som definerer en elementegenskap og der oversetteren kommuniserer med en typeomformer for å konvertere datastrengen til en objektegenskap.

4. System ifølge krav 1, der formatkoden omfatter in-line tekst som omfatter kompleks egenskapsyntaks.

5. System ifølge krav 4, der in-line teksten blir identifisert med en referanse som er referert til ved et annet sted i formatkoden.

6. System ifølge krav 4, der in-line teksten blir identifisert med en referanse som refererer til en fil.

7. System ifølge krav 4, der in-line teksten blir identifisert med en referanse som svarer til en fil som kan lastes fra en fjernlokasjon i et nettverk.

8. System ifølge krav 1, der formatkoden omfatter in-line tekst som omfatter kompleks egenskapsyntaks svarende til en grafisk ressurs.

9. System ifølge krav 8, der den grafiske ressursen beskriver et visuelt børste-objekt, idet oversetteren tilveiebringer ressursnivådata for direkte å kommunisere med scenegrafikk-grensesnittslaget for å skape et visuelt fyllingsobjekt som svarer til elementet beskrevet med den komplekse egenskapsyntaksen.

10. System ifølge krav 9, der ressursnivådata blir identifisert med en referanse som er referert til ved et annet sted i formatkoden.

11. System ifølge krav 9, der ressursnivådataene blir identifisert med en referanse som refererer til en fil.

12. System ifølge krav 9, der ressursnivådataene blir identifisert med en referanse som refererer til en fil som kan lastes ned fra en fjernlokasjon i et nettverk.

13. System ifølge krav 1, der ett av elementene i element-objektmodellen omfatter et bilde-element.

14. System ifølge krav 1, der ett av elementene i element-objektmodell omfatter et video-element.

15. System ifølge krav 1, der ett av elementene i element-objektmodellen omfatter et kanvaselement som inneholder et form-element.

16. System ifølge krav 1, der ett av elementene i element-objektmodellen omfatter et form-element.

17. System ifølge krav 16, der form-elementet omfatter et rektangel-element.

18. System ifølge krav 16, der form-elementet omfatter et polylinje-element.

19. System ifølge krav 16, der form-element omfatter et polygon-element.

20. System ifølge krav 16, der form-elementet omfatter et bane-element.

21. System ifølge krav 16, der form-elementet omfatter et linje-element.

22. System ifølge krav 16, der form-elementet omfatter et ellipse-element.

23. System ifølge krav 16, der form-elementet omfatter et sirkel-element.

24. System ifølge krav 16, der form-elementet omfatter fylling-egenskapdata.

25. System ifølge krav 16, der form-elementet omfatter strek-egenskapdata.

26. System ifølge krav 16, der form-elementet omfatter klipping-egenskapdata.

27. System ifølge krav 16, der form-elementet omfatter transformasjon-egenskapdata.

28. System ifølge krav 16, der form-elementet omfatter effekt-data.

29. System ifølge krav 16, der form-elementet omfatter opasitetsdata.

30. System ifølge krav 16, der form-elementet omfatter blendemodus-data.

31. System ifølge krav 1, videre omfattende en motor som prosesser scenegrafikk-datastrukturen og tilveiebringer kommandoer til minst én lavere-nivå grafikk-komponent.

32. System ifølge krav 31, der motoren traverserer scenegrafikk-datastrukturen.

33. System ifølge krav 31, der motoren overfører scenegrafikk-datastrukturen.

34. System ifølge krav 1, der oversetteren ber om instansiering av minst ett bygge-element for å opprette objektene.

35. Datamaskin-implementert fremgangsmåte, karakterisert ved at den omfatter: å parse formatkode som omfatter formatkode-etiketter og assosierte egenskapdata i henhold til en objektmodell; å interpretere en formatkode-etikett i formatkoden for å bestemme hvorvidt formatkode-etiketten vedrører et elementnivå eller et ressursnivå; og a) dersom formatkode-etiketten vedrører elementnivået, å opprette et element basert på formatkode-etiketten og egenskapdata assosiert med formatkode-etiketten og legge til elementet i et elementtre for senere oversettelse til et scenegrafikk-objekt i en scenegrafikk-datastruktur; og b) dersom kodeetiketten vedrører ressursnivå, å tilveiebringe data for direkte å opprette et scenegrafikk-objekt i scenegrafikk-datastrukturen via et grensensitt mot scenegrafikk-datastrukturen.

36. Fremgangsmåte ifølge krav 35, der objekter i element-objektmodellen i det vesentlige samsvarer med objekter i scenegrafikk-datastrukturen.

37. Fremgangsmåte ifølge krav 35, der formatkoden omfatter in-line tekst for en formatkodeetikett-egenskapverdi og videre omfatter det å kommunisere med en typeomformer for å konvertere in-line teksten til en objektegenskap.

38. Fremgangsmåte ifølge krav 35, der formatkoden omfatter in-line tekst for en formatkodeetikett-egenskapverdi som har en referanse til annen tekst i formatkoden, og der det å interpretere formatkodeetikett-egenskapverdien omfatter det å interpretere den andre teksten.

39. Fremgangsmåte ifølge krav 35, der formatkoden omfatter formatkode-etiketter som omfatter kompleks egenskapsyntaks for et element, og der det å interpretere formatkode-etikettene omfatter det å interpretere den komplekse egenskapsyntaksen for å bestemme at kodeetikettene er rettet mot elementnivået.

40. Fremgangsmåte ifølge krav 35, der formatkoden omfatter formatkode-etiketter som spesifiserer kompleks egenskapsyntaks for et element, og der det å interpretere kodeetikettene omfatter det å interpretere den komplekse egenskapsyntaksen for å bestemme at elementet er rettet mot ressursnivået.

41. Fremgangsmåte ifølge krav 40, der det å interpretere den komplekse egenskapsyntaksen omfatter det å detektere at den komplekse egenskapsyntaksen beskriver en egenskap svarende til et visuelt børsteobjekt.

42. Fremgangsmåte ifølge krav 40, der formatkode-etiketter som definerer et visuelt børsteobjekt refereres til av et element i elementtreet.

43. Datamaskinlesbart medium som inneholder datamaskin-eksekverbare instruksjoner for å utføre fremgangsmåten ifølge krav 35.

44. Datamaskinlesbart medium i hvilket det er lagret en datastruktur, karakterisert ved at det omfatter: et første sett av data som omfatter et første sett av formatkode-etiketter og egenskapdata, idet sammenhengen i hvilken det første settet av formatkode-etiketter interpreteres angir at det første settet av formatkode-etiketter er rettet mot et elementnivå; et andre sett av data som omfatter et andre sett av formatkode-etiketter og andre egenskapdata, idet den sammenhengen i hvilken det andre settet av formatkode-etiketter blir interpretert svarer til en kompleks egenskapsyntaks og angir at det andre settet av formatkode-etiketter er rettet mot et ressursnivå; og når datastrukturen blir interpretert, det første settet av data resulterer i at data svarende til det første settet av formatkode-etiketter blir generert og satt inn i et elementnivå-tre basert på den første informasjonen i det første settet av tekst, og det andre settet av data resulterer i at data svarende til det andre settet av formatkode-etiketter blir tilveiebrakt for direkte å opprette et scenegrafikk-objekt i en scenegrafikk-datastruktur på ressursnivå via et grensesnitt mot scenegrafikk-datastrukturen, basert på den andre informasjonen i det andre settet av tekst.

45. Datastruktur ifølge krav 44, videre omfattende et tredje sett av data som omfatter en streng som svarer til en verdi for en egenskap.

46. Datastruktur ifølge krav 44, der det første settet av formatkode-etiketter spesifiserer en identifikator, og videre omfattende et tredje sett av data som refererer til identifikatoren.

47. Datastruktur ifølge krav 46, der, når det blir interpretert, det tredje settet av data resulterer i at data svarende til det første settet av formatkode-etiketter blir lagt til i elementnivå-treet i en posisjon for det tredje settet av data.

48. Datastruktur ifølge krav 44, der det andre settet av formatkode-etiketter omfatter en identifikator, og videre omfattende et tredje sett av data som refererer til identifikatoren.

49. Datastruktur ifølge krav 44, der det andre settet av formatkode-etiketter omfatter data som er formattert i en kompleks egenskapsyntaks in-line i formatkode.

50. Datastruktur ifølge krav 49, der den komplekse egenskapsyntaksen beskriver et ressursnivå-element som har en fyllingsegenskap svarende til et visuelt fyllingsobjekt.

51. Datastruktur ifølge krav 49, der den komplekse egenskapsyntaksen beskriver egenskaper for et bildeelement.

52. Datastruktur ifølge krav 49, der den komplekse egenskapsyntaksen beskriver egenskaper for et videoelement.

53. Datastruktur ifølge krav 44, der det første settet av formatkode-etiketter beskriver egenskaper for et form-element.

54. Datastruktur ifølge krav 53, videre omfattende data i datastrukturen som beskriver et kanvaselement som inneholder form-elementet.

55. Datastruktur ifølge krav 53, der egenskapene til form-elementet omfatter fyllings-egenskapdata.

56. Datastruktur ifølge krav 53, der egenskapene til form-elementet omfatter strek-egenskapdata.

57. Datastruktur ifølge krav 44, der egenskapene til det første elementet omfatter klippingsdata.

58. Datastruktur ifølge krav 44, der egenskapene til det første elementet omfatter transformasjonsdata

59. Datastruktur ifølge krav 44, der egenskapene til det første elementet omfatter opasitetsdata.

60. Datastruktur ifølge krav 44, der egenskapene til det første elementet omfatter blendemodus-data.