[VB6] Veel lijnen tekenen: GDI, OpenGL of DirectX?

[Battle Bunny]

Op dit moment ben ik bezig met een programma die op een AutoCAD achtige manier gebouwen en ruimtes laat zien. In de ruimtes staan ook nog een hoop elementen die samen een flink aantal lijnen opleveren.

Aangezien VB6 en snelheid (zeker qua graphics) niet echt samengaan ben ik bezig met zoeken naar een nieuwe oplossing. Voor zover ik nu zie zijn er vier opties:

1) GDI blijven gebruiken. Zelf een C++ lib schrijven die in 1 klap alles op het scherm gooit. Lekker snel, maar ik ben geen ster in C. Ook nog steeds software.
2) DirectX. Bijzonder snel, maar ben ik ook geen ster in. Daarbij mag ik niet van uit gaan dat de gebruikers een DX9 kaart hebben ofzo, dus daar moet ik rekening mee houden. Pluspunt: The sky is the limit. 3D camera, lightning, etc.
3) OpenGL. Weet ik helemaal niets van.
4) Een 3rd party product, bijvoorbeeld Cairo. Moet ik eerst een conversie voor schrijven naar VB en dan is het ook nog veel werk te leren.

Wat zou nou de beste methode zijn om mijn data (een hele stapel lijnen (3000+) en een aantal gevulde rectangles (1000+)) snel te tonen? Het gaat om hoofdzakelijk statische data die bij zoom/pan opnieuw getekend moet worden.

Iemand tips / ideeen? (Hoe doet bijv. AutoCAD dit?)

[ThunderNet]

Waarom gebruik je hier VB6 voor?
C# (of desnoods VB.Net) icm Direct3D lijken me veel geschikter.

[Verwijderd]

je kunt zonder DX9 toch ook al heel veel op het scherm zetten? ik denk dat iedereen wel minimaal een dx7 of 8 GPU heeft, desnoods onboard

[LPEspecial]

DirectX is een optie (ook onder VB).

Natuurlijk kan OpenGL ook. Zie voor wat basic tutorials http://nehe.gamedev.net/

Natuurlijk is een model met 3000+ lijnen en 1000+ polygonen niet altijd even vloeiend te vertonen op zeer verouderde hardware (je praat over systemen zonder directX -> mogelijk zeer verouderde systemen).

[Battle Bunny]

Thundernet:
Het programma is niet bepaald klein en is al in VB6 gemaakt. Dit is geen probleem. Ik wil nu het rendering deel hier uit halen (zit lekker verweven... grrr) en apart (in C) maken. De vraag is ook niet in welke taal het programma moet draaien, puur welk hulpmiddel ik het beste kan gebruiken om te renderen.

Kage:
Ik heb een aantal boeken over DirectX, en kan hier veel over gaan leren. Je mag er ondertussen best van uit gaan dat iedereen minstens Win XP heeft, dus DX9.

De meeste voorbeelden die ik heb laden hun complexe modellen uit .x files (of in elk geval uit een bestand). Ik wil dit zelf "toevoegen". Kan dit met Direct 3D?

Overigens wil ik ook proberen Terminal Server gebruikers niet uit te sluiten... Maar volgens mij vallen DirectX en OpenGL dan meteen al af, nietwaar?

[.oisyn]

Overstappen naar een andere taal heeft natuurlijk geen enkel nut. De lijn-teken-code zelf is tenslotte ook niet in VB6 geschreven, en GDI, DX en OGL zut kun je ook gewoon vanuit VB6 aanroepen. Ik denk dat het handig is te onderzoeken waar precies de bottleneck zit. Hoe worden de lijnen nu getekend, gewoon naar een form of control? Ik zou eens proberen (vanuit VB6) een offscreen DC aan te maken en daarnaartoe te tekenen, en dat vervolgens te blitten naar je form/control. Geen idee of VB6 daar native support voor heeft, en anders kun je nog terugvallen op de Win32 API.

[Battle Bunny]

Overstappen voor de hele app heeft geen zin, maar voor het tekenen wel. Ik weet zeker dat C sneller is dan VB als het op loopen, arrays, collections, etc aankomt.

Wat tekenen betreft: ik gebruik al geen VB line meer, maar de api's LineTo en MoveTo. Dit is soms al een factor 10 sneller. In tests heb ik ook een offscreen DC aangemaakt, zelfs een een bit array en die met SetDIBits naar een hdc gepompt. Dan loop ik nog steeds tegen het punt aan dat VB gewoonweg traag is met loopen e.d. (en ik moet zelf lijnen tekenen, veel rekenwerk en daar is VB slecht in)

Dus wat ik wil is mijn VB app eenmalig alle lijnen laten ophoesten en dit in een C DLL bijhouden. Vervolgens alleen wijzigingen doorgeven (lijn 2152 verplaatst naar x,y bijv.).

Zelfs als ik het in VB hou (dat zal ik wel doen voor mijn tests) rest mij de vraag: is GDI snel genoeg? Het liefst zou ik een hele stapel line commando's naar de videokaart driver willen sturen o.i.d.

[ Voor 4% gewijzigd door Battle Bunny op 19-12-2007 17:06 ]

[.oisyn]

Battle Bunny schreef op woensdag 19 december 2007 @ 17:05:
Overstappen voor de hele app heeft geen zin, maar voor het tekenen wel. Ik weet zeker dat C sneller is dan VB als het op loopen, arrays, collections, etc aankomt.

Als de bottleneck bij dat soort dingen ligt dan is dat idd zinniger.

Zelfs als ik het in VB hou (dat zal ik wel doen voor mijn tests) rest mij de vraag: is GDI snel genoeg? Het liefst zou ik een hele stapel line commando's naar de videokaart driver willen sturen o.i.d.

Lijntjes tekenen met de GPU is meestal ook vele malen langzamer dan polygonen, gek genoeg, dus ik denk niet dat je zoveel gaat winnen met DirectX of OpenGL. GDI is best rap, vergis je daar niet in. En volgens mij worden dingen als blits en rect/line draws ook gewoon hardware optimized.

[Battle Bunny]

Iets wat mij ook zou helpen: hoe kun je Windows / de hardware / whatever meerdere "lagen" laten tekenen? Als je bijv. kijkt naar het selectie rechthoekje in de Windows Explorer (Alpha blending), Firefox met z'n image drag-en-drop (FF3), etc. Dit MOET hardware zijn, anders kan het nooit zo snel. BitBlt kan inderdaad met transparantie werken, maar ik heb al ondervonden dat dit niet bijster snel is (tenminste, niet voor grotere platen).

[.oisyn]

BitBlt()? AlphaBlend() kan het wel, en die is doorgaans hardware optimized (waar mogelijk natuurlijk), net als BitBlt() en StretchBlt(). Kun je zien door de device caps op te vragen met GetDeviceCaps(). Alpha-blended windows kun je maken met de WS_EX_LAYERED style en de SetLayeredWindowAttributes() functie.

[Battle Bunny]

Alpha blending an sich heb ik ook wel aan de gang. Maar hoe doe je dat in de praktijk? Een nieuw window maken, hier naar blitten en van dit nieuwe window zeggen dat 'ie layered moet zijn?

Ik denk overigens dat ik voorlopig eerst een nieuwe VB project te maken en die al het tekenwerk laten doen. Dit haal ik dan compleet los van het bestaande project. Dit geeft mij alvast een enorm voordeel omdat ik daarna de teken-app kan aanpassen en OpenGL / DirectX kan testen. In de eerste instantie ga ik alleen GDI gebruiken. Ook al ben ik er nog niet van overtuigt dat dit snel is: een LineTo zal toch de DC moeten opzoeken, locken, coordinaten van de lijn checken, of alle vars bestaan, etc. en daarna pas de lijn moeten tekenen. Lijkt me uiterst inefficient.

[ Voor 60% gewijzigd door Battle Bunny op 20-12-2007 14:33 ]

[.oisyn]

Een layered window zal in de praktijk niet sneller zijn dan AlphaBlend() oid hoor. Verder kun je in de MSDN genoeg info vinden over layered windows.

.edit: dan gebruik je toch PolyPolyline()

[ Voor 13% gewijzigd door .oisyn op 20-12-2007 14:41 ]

[Battle Bunny]

Volgens mij is het zo dat Windows het tekenen doet als ik een layered window over mijn eigen window beweeg. Scheelt weer

PolyPolyLine is wel een goede, maar niet altijd te gebruiken. Veel dingen zijn losse lijntjes en voor die functie moeten ze "connected" zijn (tenminste, zo zegt de documentatie).

[.oisyn]

Nee, voor Polyline zijn ze allemaal connected. PolyPolyline tekent een serie van polylines. Je kunt het dus ook gewoon een lijst van lijnstukken voeren (2 verts per polyline, net als dat je met Polyline gewoon 1 lijnstuk kunt tekenen).

[ Voor 14% gewijzigd door .oisyn op 20-12-2007 15:56 ]

[ThunderNet]

Voor VB6 Graphics programmeren is dit boek trouwens een aanrader:

[farlane]

Heb je al met de opties van VB gespeeld mbt tot bounds cheking van arays en dat soort dingen? VB is absoluut niet snel dat geef ik toe maar ik heb nog niet meegemaakt dat loopen door een array de bottleneck was.

[Battle Bunny]

Hmmm, ik zal eens met polypolyline spelen, kijken of ik dan ergens kom

Dat boek zal ik overwegen, ook al ben ik er redelijk zeker van de de teken functies uit VB worden gehaald.

Het helaas ook geen optie om die array-checks e.d. uit te zetten, ook al weet ik dat dat in veel gevallen sneller is. We hebben een eigen fout afvang system, die zal dan niet meer werken (de app zal dan gewoon *poef* doen, hebben we weinig aan).

Ik heb alleen nog geen duidelijk antwoord op mijn eerste vraag: als ik het m.b.v. een teken-api wil doen: kan DirectX goed omgaan met een hele stapel lijnen, of OpelGL? En welke is dan het simpelst aan te sturen?

[ThunderNet]

Battle Bunny schreef op vrijdag 21 december 2007 @ 09:43:

Is idd niet specifiek een boek over dit probleem. Maar er worden wel erg leuke dingen in uitgelegd o.a. raytracing etc. Kleurberekeningen, polyline wordt af en toe ook gebruikt

[Battle Bunny]

Even de oude draad weer wakker schoppen: hier en daar heb ik gelezen dat de GDI calls, in theorie, hardware geacceleerd zijn. Zeker voor het fillen van polygonen zal dit voor een flinke snelheidswinst zorgen.
Helaas zit je dan nog steeds met de overhead van die functions.

Een andere oplossing, waarbij je het helemaal zelf in de hand hebt, is met de API call SetDIBits iets een stuk geheugen direct naar een hdc mikken. Ik heb een app die dit doet (een fractal generator) en die is razend snel. Het enige nadeel is dan dat line commando's software zijn (je zult ze zelf moeten schrijven)...

M.a.w., voor pixeltjes zetten is SetDIBits een goede oplossing. Maar weegt dat op tegen de speed penalty van het zelf schrijven van een line commando (is geen probleem, gewoon van Wikipedia halen).

[.oisyn]

Als je dan toch handmatig pixels gaat plotten zou ik een DC maken met een in-memory bitmap waar je direct naar kunt schrijven (CreateDIBSection()). Dan hoef je alleen nog een BitBlt naar de juiste DC van je window te doen.

[Battle Bunny]

Het probleem is dat ik nog niet zeker weet of ik dat wil

Volgens mij zijn er voor handmatig toch ook weer meerdere oplossingen:
CreateDIBSection
+Kun mee bitblitten
+Waarschijnlijk ook LineTo, FillRegion, etc gebruiken?
+Denk ik in hardware?
SetDIBits en SetDIBitsToDevice
+Meeste controle, is tenslotte een array
-Puur software, dus lijnen traag.
'Simpele DC'
-Geen idee.

Argh, raak nu helemaal de draad kwijt. Het moge duidelijk zijn dat ik voorlopig voor een niet-DX/OpenGL oplossing wil gaan (zal er toch moeten komen omdat ik het ook via Terminal Server wil laten werken), maar weet nu echt niet meer wat het snelst zal zijn ...

[roy-t]

Battle Bunny schreef op vrijdag 28 december 2007 @ 14:50:
Argh, raak nu helemaal de draad kwijt. Het moge duidelijk zijn dat ik voorlopig voor een niet-DX/OpenGL oplossing wil gaan (zal er toch moeten komen omdat ik het ook via Terminal Server wil laten werken), maar weet nu echt niet meer wat het snelst zal zijn ...

plaag jezelf dan niet door dit over een jaar weer te doen, maar scrijf gewoon meteen naar dx7/8/9 (kan elke kaart)

VB voorbeeld
http://www.planet-source-...?lngWId=1&txtCodeId=14218

dan kun je zodadelijk iets als

graphics.GraphicsDevice.DrawPrimitives

Heerlijk snel, volgend jaar hoef je niet weer dit te doen, en alles meteen goed

[Battle Bunny]

therat10430, ik snap dat iets als DirectX het beste is. Helaas loop je volgens mij dan tegen het probleem aan dat je in hardware mode MOET zitten. Daarbij moet je ook een redelijk actuele kaart hebben om DX8 te kunnen, veel bedrijven draaien nog op Win2K met DX7 en hebben er een simpel Matrox G400 kaartje in oid. Vandaar dat ik eerst een non-DX optie zoek.

[.oisyn]

Overigens is videohardware helemaal niet zo rap in het tekenen van lijntjes als in het tekenen van polygonen, en zo heel erg langzaam is een CPU daar ook weer niet in. Dus staar je daar niet al teveel op blind.

[roy-t]

Battle Bunny schreef op vrijdag 28 december 2007 @ 15:26:
therat10430, ik snap dat iets als DirectX het beste is. Helaas loop je volgens mij dan tegen het probleem aan dat je in hardware mode MOET zitten. Daarbij moet je ook een redelijk actuele kaart hebben om DX8 te kunnen, veel bedrijven draaien nog op Win2K met DX7 en hebben er een simpel Matrox G400 kaartje in oid. Vandaar dat ik eerst een non-DX optie zoek.

Zelfs een matrox G400 kan prima overweg met DX8 en de bedrijven waar ik kom hebben tegenwoordig toch minstens een Intel onboard DX9 kaartje. Verder maak je een soort CAD achtig programma en dan mag je best wat (lage) eisen stellen aan het programma, ik weet niet waar het exact voor is, maar het klinkt iig niet als een programma wat elke random werknemer achter random workstation zal draaien, maar dat terzijde.

@ Oisyn: Verder weet ik de exacte performance verschillen niet tussen een cpu (in jouw geval waarschijnlijk dus een pentium4 1,6ghz +- ) en een Matrox G400 of hoger, maar voor mijn gevoel is de gpu daar een stuk sneller mee, je hebt niet voor niets allerlij primitivetypes om te tekenen in DirectX, dit is naar mijn wetenhoog geoptimalizeerd, terwijl er voor de CPU nauwelijks optimalizatie voor is. (naar mijn weten).

Anyways, als je het doet, doe het dan goed en bekijk even hoe afhankelijk je echt bent van de CPU, trouwens, zelfs in DX7 is het toch prima mogelijk om een paar honderd lijntjes te tekenen

[.oisyn]

therat10430 schreef op vrijdag 28 december 2007 @ 17:44:
@ Oisyn: Verder weet ik de exacte performance verschillen niet tussen een cpu (in jouw geval waarschijnlijk dus een pentium4 1,6ghz +- ) en een Matrox G400 of hoger, maar voor mijn gevoel is de gpu daar een stuk sneller mee, je hebt niet voor niets allerlij primitivetypes om te tekenen in DirectX, dit is naar mijn wetenhoog geoptimalizeerd, terwijl er voor de CPU nauwelijks optimalizatie voor is. (naar mijn weten).

Een GPU is snel omdat het een stream processor is en daardoor vele pixels tegelijk kan verwerken, in blokjes. Daarnaast heeft het dedicated memory en hardware om texels te fetchen en te filteren waar nodig. Als je een lijntje tekent zijn het ten eerste geen blokjes, en ten tweede wil je ze niet texelen. De inner loop van een degelijke lijn implementatie is maar een paar cycles, op dat vlak wint een GPU echt niet zoveel (denk er aan dat zelfs de huidige high-end kaarten nog onder de GHz geklokt zijn).

Het is ook niet voor niets dat als je een scene met miljoenen polygonen dat 60fps loopt in wireframe gaat renderen, dat je framerate als een tiet inkakt, terwijl je feitelijk veel minder pixels vult.

[roy-t]

Een heldere uitleg Oisyn, alleen gaat deze in mijn App iig niet op. (maar leesdoor ik heb nog verder nagedacht en je krijgt gelijk )

als ik de volgende code set in XNA heb ik zo'n 120~150fps

C#:

//in XNA
graphics.GraphicsDevice.RenderState.FillMode = FillMode.WireFrame;

als ik de fillmode gewoon op solid laat heb ik een fsp van 115~130
(zo'n 1ms verschil in rendertijd per frame (ik weet dat fps vrij weinig zegt nl.)

In de scene wordt een gebumpmappede roterende ball (mesh) getekend met daar achter een een muur (vertices) en 3 lampen die shadowscasten van de bal op de muur.

Nu moet ik zeggen dat hier niet al te veel lijnen worden getekend (zo'n 50) en dat in beide gevallen de fps cpu-bound is. En ik denk dat in het geval van veel lijnen uiteindelijk de solid mode hogere fps gaat scoren.


Nu denk ik aan de ene kant: je hebt gelijk zelfs versus 3 shadowmaps, lightning en normalmapping is de WireFrame modus niet erg sneller

Aan de andere kant is het resultaat cpu bound.

Na wat tobben denk ik dat inderdaad het verschil minder groot zal zijn dan ik had gedacht, maar toch denk ik dat in direct3D de performance (en makkelijkheid van implementatie) hoger zal zijn dan op de cpu blijven schakelen.

Maar het kon nog wel eens een interessante testcase worden.

iig hulde voor je technische kennis, deze mis ik op dit gebied nog

[.oisyn]

Ik had het ook over een scene met miljoenen poly's . Als ik onze TR8 renderer op de xbox360 op wireframe zet dan valt het aantal frames per seconde terug van ~30 naar ~12.

[Battle Bunny]

Toch vind ik 12fps op wireframe modus redelijk netjes, het is in elk geval sneller dan ik red in VB

Overigens, eindelijk is er wel een childhook mystery opgelost. Ik vroeg me altijd al af waarom Wireframe mode trager was dan 'normale' modus. Eindelijk opgelost!

[ Voor 44% gewijzigd door Battle Bunny op 31-12-2007 10:25 ]

[Battle Bunny]

Ondertussen heb ik een test DX8 programma gemaakt.Real basic, maar het werkt goed. De tekening die in mijn eigen teken-engine zo'n 250ms duurde draait nu op DX8 met 140-150fps (op een X1400, mijn Dell Inspiron 9400).

De lijnen zijn gewoon een linelist. Ondanks dat dit enorme beperkingen heeft (het ding is altijd 1 pixel breed, etc), heeft het ook voordelen: het is simpel, snel en werkt grotendeels met mijn bestaande systeem. Ik zie hier en daar wel dingen over quads, maar daar moet ik me nog in verdiepen.

Ook heb ik geen idee hoe ik items in mijn vertex-buffer kan wijzigen, of beter, hoe ik kan uitvogelen WAT ik moet wijzigen. Maarja, komt nog wel. Ik heb in elk geval een goed gevoel hier over en denk dat dit de goede weg is. Hoe dan ook kan ik hier nog veel verder mee gaan, the sky is the limit!

[roy-t]

Battle Bunny schreef op maandag 31 december 2007 @ 22:33:
Ondertussen heb ik een test DX8 programma gemaakt.Real basic, maar het werkt goed. De tekening die in mijn eigen teken-engine zo'n 250ms duurde draait nu op DX8 met 140-150fps (op een X1400, mijn Dell Inspiron 9400).

De lijnen zijn gewoon een linelist. Ondanks dat dit enorme beperkingen heeft (het ding is altijd 1 pixel breed, etc), heeft het ook voordelen: het is simpel, snel en werkt grotendeels met mijn bestaande systeem. Ik zie hier en daar wel dingen over quads, maar daar moet ik me nog in verdiepen.

Ook heb ik geen idee hoe ik items in mijn vertex-buffer kan wijzigen, of beter, hoe ik kan uitvogelen WAT ik moet wijzigen. Maarja, komt nog wel. Ik heb in elk geval een goed gevoel hier over en denk dat dit de goede weg is. Hoe dan ook kan ik hier nog veel verder mee gaan, the sky is the limit!

Nu gebruik ik wel eens een vertex buffer, maar wat wil je veranderen? Invoer type?

[Battle Bunny]

Nu gebruik ik wel eens een vertex buffer, maar wat wil je veranderen? Invoer type?

Nee, de data die er in zit. Ik heb nu een collection met lijnen, deze stop in in de vertex buffer. Vervolgens kan DirectX het allemaal leuk renderen. Als ik in mijn app nu een lijn wijzig, zal ik die coordinaten moeten aanpassen, lijkt me.

Tenminste, het lijkt met niet de bedoeling dat ik elke keer een compleet nieuwe set met gegevens ga aanbieden. Like I said, ik heb nog geen idee... Any help is appreciated, natuurlijk.

[roy-t]

Ik ben nu toevallig niet thuis, daar heb ik wat meer voorbeeldjes code.

Maar het idee is volgens mij dat je een vertexbuffer met een liefst vaste grote declareerd

en elke update cyclus de vertexbuffer opnieuw vult met lijnen.

Efficienter is natuurlijk alleen als de lijnen veranderd worden, maar dit is voor goed renderen niet noodzakelijk, en vaak complexer dan gewoon die v.b. weer vullen.

Ik zou een stukje code kunnen plakken als ik weer thuis ben. Maar kijk eerst maar of je er zo uitkomt. Wees niet bang voor die paar vulcodes vanaf je app, deze updates zijn over het algemeen veel sneller dan je draw.

Edit: oh btw ik neem verder aan dat je gewoon een array met een soort van lijn struct hebt.
soort van struct met
Lijn.begin.x
Lijn.begin.y
Lijn.eind.x
Lijn.eind.y

En hier dan een array van. Deze stop je gewoon standaard elk frame in je vertexbuffer (de check of er iets veranderd is, is op een grote array gewoon langzamer dan vertexbuffer.setdata();
Als lijn[34] veranderd verander je dit direct in de array en blijf alles goed gaan.

[ Voor 26% gewijzigd door roy-t op 01-01-2008 22:43 ]