[BCB] Grafieken, threads en array

[bart0l0meus]

Beste programmers,

Voor school zijn we bezig een hartslag monitor te maken, waarmee we aan de hand van RS232 op de computer met een zelfgemaakt programma het welbekende grafiekje tekenen.

Er zijn echter een aantal problemen, we moeten de grafiek altijd blijven tekenen, hierbij zijn dus threads nodig en omdat we beginnelingen zijn in de programmeertaal zal dit een probleem kunnen worden.
Op dit moment tekenen we de grafiek met een canvas en een array met punten die we met een for loopje afdrukken, hij moet de gui echter na elk geplot punt weergeven, dit doen we nu met processmessage wat een zeer lelijke manier is met knipperd scherm als resultaat, is dit ook anders (beter) op te lossen?
Het volgende probleem is dat we in een array telkens alle waarden een plaatsje moeten opschuiven waar de nieuwe waarde op plaats 0 erin schuift, echter kost dit veel te veel kracht (in een array van 700 plaatsen) en gebeurd dit daardoor veel te langzaam. Is dit ook op te lossen?

[Orphix]

Ik weet niet waar BCB voor staat (Borland C++ Builder?), maar ik denk dat je door dingen wat slimmer aan te pakken al een eind kan komen ipv threads.
Het flikkeren van het beeld kan komen omdat je direct op het canvas tekent. Een tweede optie is eerst te tekenen op een off-screen canvas (in he geheugen) en deze in een keer te kopieeren naar de canvas op het scherm. Daarnaast heb ik het gevoel dat jullie de hele grafiek elke keer opnieuw tekenen. Maar een hartslagmonitor werkt toch van links->rechts? Dus je zou ook een enkele kolom per update kunnen doen ipv de gehele grafiek.
Voor je data structuur zou kunnen kijken naar een queue. Maar dit is afhankelijk van de taal/omgeving waar je in programmeert.

[bart0l0meus]

BCB staat idd voor Borland C++ Builder;)
Het knipperen van het beeld komt door de procesmessage; we tekenen namelijk de grafiek op de volgende manier:

code:

for (int i = 1; i <= 700; i++)
  {
    Image1->Canvas->Pen->Width = 1;
    Image1->Canvas->Pen->Color = clLime;
    Image1->Canvas->MoveTo((i+100), array[i-1]);
    Image1->Canvas->LineTo((i+100),array[i]);
    Sleep(10);
    Application->ProcessMessages();
  };

Door die processmessage ververst hij de Gui na elk streepje die hij tekend, reken dus maar uit, elke 10ms, en dan gaat het scherm gek doen.
We zullen elke keer de grafiek opnieuw moeten tekenen, en niet alleen 1 kolom, anders klopt het plaatje niet meer.
Het kan op 2 manieren:
http://nl.youtube.com/wat...R3kfLISDA&feature=related
http://nl.youtube.com/wat...vKoHngJqY&feature=related
Wij hebben voorkeur op de laatste link, omdat aan de hand van deze methode het beste de snelheid etc te zie is.
Ik zal een swat opzoeken over queue

[AtleX]

Waarom doe je die Sleep(10) en die ProcessMessages()? Je kan toch gewoon de hele grafiek tekenen, en dan pas ProcessMessages() aanroepen?

[TeeDee]

Over het compleet opnieuw tekenen:
Als er geen hartslag is, dan zal de lijn op zijn 0 punt zitten. Die hoef je toch niet nog eens te berekenen/tekenen?

[RobIII]

Uhm, ik neem aan dat je op vaste intervals meet? Dan zet je toch gewoon een timer op X milliseconden en doe je een meting en plot je de meting (lijn trekken vanuit previous point naar current point). Dan hoef je iedere X ms dus maar 1 lijn te trekken. En 'aan het einde van het plaatje' even rekening houden met een wrap.

code:

Timer_Fired:
  Doe meting
  Plot vanuit vorig punt (of 0,0 wanneer geen vorig punt) lijn naar huidige meetwaarde

Als je de grafiek wil 'scrollen' zoals in je 2e voorbeeld dan kun je beter gebruik maken van een sliding viewport / window ofzo (en een offscreen buffer / double buffer).

Hoe dan ook, ik zie niet waarom je telkens de hele grafiek wil tekenen (hoewel dat technisch prima haalbaar is zonder geflikker) en waarom je arrays met waarden zou willen hebben als je gewoon op een interval een meting doet.

[ Voor 31% gewijzigd door RobIII op 14-04-2008 17:12 ]

[bart0l0meus]

Nouw, ik zal vanuit de microcontroller elke Xms een waarde krijgen (Protentiaal Voltage) die waarde moet hij dus achter het laatste getekende punt op de grafiek plakken, dit betekend dus dat ik alle getekende punten van het canvas een bepaalde afstand moet opschuiven zodat ze plaats maken voor de nieuwe waarde. Zover ik weet kan men niet de punten in een canvas opschuiven, dus zal ik hem helemaal opnieuw moeten tekenen met de nieuwe waarde erbij getekekend.
Dit is me ook gelukt, maar door het verschuiven van alle waarde in het array wordt het gewoon veeeeeeeeel te langzaam (refresh 1 keer per 2 seconde) en dit zou dus minimaal 1 keer per 100ms moeten zijn. Men zou dan het array kleiner kunnen maken, maar dan bezuinigt men dus aanzienlijk op de nauwkeurigheid.
Het probleem zit hem dus in het refreshen van de GUI in een while/for loop (op een fatsoendelijke manier) en het oplossen van het verplaatsen van het array.

[Verwijderd]

ipv LineTo kan je PolyLine/PolyLineTo gebruiken, deze tekent al een stuk sneller waarschijnlijk.

Ik neem aan dat je het grid maar 1x tekent, dus opslaan in een bitmap en deze kopieeren naar nieuwe bitmap, grafiek erop plotten en naar je scherm sturen?

Nu is BCB beetje oud, heb je daarin een PaintBox component ?

[Orphix]

bart0l0meus schreef op maandag 14 april 2008 @ 17:14:
Het probleem zit hem dus in het refreshen van de GUI in een while/for loop (op een fatsoendelijke manier) en het oplossen van het verplaatsen van het array.

Het probleem zit meer in de aanpak. Jullie gebruiken een array om de waardes te meten, maar de array is eigenlijk overbodig als je bij elke interval direct de waarde op het scherm tekent. Je hoeft dan enkel de voorgaande waarde op te slaan (enkele variabele) om op die manier een lijn te kunnen tekenen.
Het verplaatsen van alle pixels kan prima. Je verplaatst dan in feite het hele plaatje naar links. Het is alweer een tijdje geleden dat ik met BCB heb gewerkt, maar het lijkt me dat Canvas methodes heeft waarbij je een gedeelte kan verplaatsen (translate), of kan kopieeren en een paar pixels meer naar links weer plakken.
Als je het op deze manier aanpakt heb je zeer weinig instructies en die moeten razendsnel kunnen, binnen de frames, waardoor je geen moeite hoeft te doen om de GUI te updaten in aparte threads.

[.oisyn]

bart0l0meus schreef op maandag 14 april 2008 @ 17:14:
Dit is me ook gelukt, maar door het verschuiven van alle waarde in het array wordt het gewoon veeeeeeeeel te langzaam (refresh 1 keer per 2 seconde) en dit zou dus minimaal 1 keer per 100ms moeten zijn.

Pfff, hoeveel elementen heb je in die array staan, 1 miljard ofzo? Of werk je nog op een 8086? Ik denk eerder dat dat komt door die Sleep(10) midden in je loop. Waarom wil je slapen terwijl je lijnstukken tekent? Als je het al op die manier wilt doen dan moet je het slapen buiten de loop zetten (alsmede de ProcessMessages()). Maar beter gebruik je gewoon een timer met een degelijk interval.

Orphix schreef op maandag 14 april 2008 @ 17:33:
[...]

Het probleem zit meer in de aanpak. Jullie gebruiken een array om de waardes te meten, maar de array is eigenlijk overbodig als je bij elke interval direct de waarde op het scherm tekent. Je hoeft dan enkel de voorgaande waarde op te slaan (enkele variabele) om op die manier een lijn te kunnen tekenen.

Nou ken ik de Canvas niet, maar onthoudt hij de getekende pixels, of moet je opnieuw tekenen nadat er een andere window overheen is gegaan? In dat laatste geval heb je dus ook de meetgegevens nodig. En het opschuiven in een array van 700 elementen kost echt geen seconden hoor, eerder in de orde van grootte van een enkele microseconde . En als je de array cyclisch gebruikt hoef je niet eens op te schuiven.

[ Voor 37% gewijzigd door .oisyn op 14-04-2008 17:46 ]

[Janoz]

Het volgende probleem is dat we in een array telkens alle waarden een plaatsje moeten opschuiven waar de nieuwe waarde op plaats 0 erin schuift, echter kost dit veel te veel kracht (in een array van 700 plaatsen) en gebeurd dit daardoor veel te langzaam. Is dit ook op te lossen?

Circular buffer lijkt me hiervoor ideaal.

[RobIII]

bart0l0meus schreef op maandag 14 april 2008 @ 17:14:
Nouw, ik zal vanuit de microcontroller elke Xms een waarde krijgen (Protentiaal Voltage) die waarde moet hij dus achter het laatste getekende punt op de grafiek plakken, dit betekend dus dat ik alle getekende punten van het canvas een bepaalde afstand moet opschuiven zodat ze plaats maken voor de nieuwe waarde. Zover ik weet kan men niet de punten in een canvas opschuiven, dus zal ik hem helemaal opnieuw moeten tekenen met de nieuwe waarde erbij getekekend.
Dit is me ook gelukt, maar door het verschuiven van alle waarde in het array wordt het gewoon veeeeeeeeel te langzaam (refresh 1 keer per 2 seconde) en dit zou dus minimaal 1 keer per 100ms moeten zijn. Men zou dan het array kleiner kunnen maken, maar dan bezuinigt men dus aanzienlijk op de nauwkeurigheid.
Het probleem zit hem dus in het refreshen van de GUI in een while/for loop (op een fatsoendelijke manier) en het oplossen van het verplaatsen van het array.

Vandaar dat ik het had over een sliding window / viewport:

Dan kun je makkelijk met 2 images werken en hoef je niet steeds alles opnieuw te tekenen en wek je toch de illusie dat je scrollt, terwijl je (in principe) enkel de .left property van de beide buffer images wijzigt.

edit:

En inmiddels zijn Janoz en .oisyn me min of meer voor

[ Voor 9% gewijzigd door RobIII op 14-04-2008 17:56 ]

[.oisyn]

RobIII schreef op maandag 14 april 2008 @ 17:40:
[...]

Vandaar dat ik het had over een sliding window / viewport:

Wellicht "praktischer" vanuit het aspect van de applicatie (al waag ik dat te betwijfelen, de contents van een in-memory buffer opschuiven en een lijntje erbij tekenen is natuurlijk ook peanuts ), maar zeker niet efficienter performancewise, want nu moet het OS gaan blitten

Een circular buffer is trouwens niet hetzelfde als een sliding window, janoz en ik hadden het over de array met meetgegevens

[ Voor 12% gewijzigd door .oisyn op 14-04-2008 17:49 ]

[RobIII]

.oisyn schreef op maandag 14 april 2008 @ 17:48:
[...]

Wellicht "praktischer" vanuit het aspect van de applicatie (al waag ik dat te betwijfelen, de contents van een in-memory buffer opschuiven en een lijntje erbij tekenen is natuurlijk ook peanuts ), maar zeker niet efficienter performancewise, want nu moet het OS gaan blitten

Het ging er mij om dat het praktischer (makkelijker) te implementeren is (zo op het eerste oog althans, dat kon nog wel eens meevallen met een circular buffer).

.oisyn schreef op maandag 14 april 2008 @ 17:48:
[...]
Een circular buffer is trouwens niet hetzelfde als een sliding window, janoz en ik hadden het over de array met meetgegevens

Daarom was je me ook voor

[Orphix]

.oisyn schreef op maandag 14 april 2008 @ 17:38:
Nou ken ik de Canvas niet, maar onthoudt hij de getekende pixels, of moet je opnieuw tekenen nadat er een andere window overheen is gegaan? In dat laatste geval heb je dus ook de meetgegevens nodig. En het opschuiven in een array van 700 elementen kost echt geen seconden hoor, eerder in de orde van grootte van een enkele microseconde . En als je de array cyclisch gebruikt hoef je niet eens op te schuiven.

Hmm ja daar zeg je wat. Volgens mij was het idd zo dat Canvas niet de pixels onthoudt (in een offscreen buffer), en de Image daarentegen wel. In dat geval (aan de TS), moet je dus Image gebruiken. (Of 1 van de andere methodes die menig mede-GoT-er hierboven al heeft geopperd )

[Verwijderd]

Het optimaliseren van je array van te tekenen punten kan ook nog wat uitmaken, niet ieder meetpunt hoeft een ander punt op je zichtbare grafiek te betekenen, als je beetje google'd kom je ook op routines om arrays van punten te optimaliseren voor het tekenen van een (poly)line, hiermee versnel je de zaak ook weer.

Het tekenen op zich moet kunnen, heb ooit voorbeeldje gemaakt in Delphi hiervoor (kan het helaas niet meer vinden).

[.oisyn]

Hoewel een interessant onderwerp, is het een beetje overkill als je 10 keer per seconde 700 lijnstukjes wilt tekenen. De meeste tijd zit 'm waarschijnlijk zelfs in het blitten van de offscreen buffer naar het scherm, en die ga je met een dergelijke optimalisatie niet wegwerken

[Verwijderd]

.oisyn schreef op maandag 14 april 2008 @ 19:21:
Hoewel een interessant onderwerp, is het een beetje overkill als je 10 keer per seconde 700 lijnstukjes wilt tekenen. De meeste tijd zit 'm waarschijnlijk zelfs in het blitten van de offscreen buffer naar het scherm, en die ga je met een dergelijke optimalisatie niet wegwerken

is correct, maar je hebt sowieso maar een beperkt aantal punten te tekenen, namelijk de breedte in pixels van je "monitor".

voorbeeldje in delphi:
"lopende" grafiek

met standaard delphi/windows programming krijg je het nooit 100% knipperloos, als je dat wilt moet je echt meer richting "game" programming kijken hoe die dit soort zaken oplossen.

[ Voor 22% gewijzigd door Verwijderd op 14-04-2008 21:00 ]

[farlane]

Verwijderd schreef op maandag 14 april 2008 @ 19:47:
met standaard delphi/windows programming krijg je het nooit 100% knipperloos, als je dat wilt moet je echt meer richting "game" programming kijken hoe die dit soort zaken oplossen.

Hmmm? Vanuit een memory buffer blitten kan toch prima?

[Verwijderd]

farlane schreef op maandag 14 april 2008 @ 21:18:
[...]


Hmmm? Vanuit een memory buffer blitten kan toch prima?

je ziet altijd wel iets geknipper, er wordt niet "gesynced" ofzo.
Zie in het voorbeeld daar wordt vanuit memory (een bitmap) "geblit".

[bart0l0meus]

@Rob|||,
Dat ziet er zeer interresant uit!
Hoe moet ik me echter een getekend canvas in een buffer voorstellen?
Of ben ik hier de canvas werkelijk aan het verschuiven?
In principe zou ik dan een interrupt kunnen maken op de RS232 input die zodra hij een waarde binnenkrijgt de grafiek tekend.
@maui71, jou programma is eigenlijk precies wat we willen berijken.
Verder, van die buffers, ik heb nog totaal geen ervaring met geheugen, buffers enz dus ik zal me hier dan sowiso op moeten verdiepen, iemand tips?

[Verwijderd]

bart0l0meus schreef op maandag 14 april 2008 @ 23:02:
@Rob|||,
Dat ziet er zeer interresant uit!
Hoe moet ik me echter een getekend canvas in een buffer voorstellen?
Of ben ik hier de canvas werkelijk aan het verschuiven?
In principe zou ik dan een interrupt kunnen maken op de RS232 input die zodra hij een waarde binnenkrijgt de grafiek tekend.
@maui71, jou programma is eigenlijk precies wat we willen berijken.
Verder, van die buffers, ik heb nog totaal geen ervaring met geheugen, buffers enz dus ik zal me hier dan sowiso op moeten verdiepen, iemand tips?

Kijk in de code, dan zie je hoe het ongeveer werkt.

Paintbox -> deze maakt een en ander zichtbaar in applicatie window.
Image 1 -> static image (je achtergrond met raster etc.)
Image 2 -> dit is je "teken"" buffer

Initialisatie:
Init image 1
Init array met coordinaten

Verloop:
Schuif punten 1 plek op (naar links)
vul laatste punt met nieuwe waarde
forceer een "paint event" van de Paintbox

PaintEvent:
Copieer static image (Image 1) naar werkimage (image 2)
Teken data op werkimage (image2) -> canvas.polyline(array of tpoint)
Copieer werkimage naar canvas (in dit geval canvas van een TPaintbox)

ander voorbeeld:
2 grafieken + foto op achtergrond:
voorbeeldje in delphi:
"lopende" grafiek v2
(resizable nu, resize code niet optimaal )

[ Voor 9% gewijzigd door Verwijderd op 14-04-2008 23:25 ]

[Voutloos]

Maar je reageert nu nog steeds niet op de opmerkingen mbt sleep() en ProcessMessages(). Waarom moet dat per se in de loop staan? En zelfs al zou ProcessMessages() erin moeten staan omdat je ook tijdens het loopen dat moet doen, dan kan je het misschien wel af en toe doen (i modulo 25 oid).

En een array circular gebruiken is ook zo lastig nog niet. Een var met het volgende element, welke opnieuw gaat tellen als het einde bereikt is en klaar ben je.

En er zijn nog wel meer optimalisaties, meer bovengenoemde wijzigen zijn iig triviaal toe te passen.

[ Voor 39% gewijzigd door Voutloos op 15-04-2008 08:13 ]

[.oisyn]

Verwijderd schreef op maandag 14 april 2008 @ 19:47:
met standaard delphi/windows programming krijg je het nooit 100% knipperloos, als je dat wilt moet je echt meer richting "game" programming kijken hoe die dit soort zaken oplossen.

Sorry maar dat is echt dikke onzin. Ik heb al talloze GDI animaties gemaakt zonder knippering. Waar knipperen bij windows vaak vandaan komt is de WM_ERASEBKGND message die standaard bij een BeginPaint() wordt verstuurd tijdens het afhandelen van een WM_PAINT. De default implementatie van die message vult het geïnvalidatete stuk met de standaard background HBRUSH van de window. Dat is simpel te voorkomen door een null HBRUSH in te stellen, of zelf de WM_ERASEBKGND af te vangen en niets te doen.

Misschien heb je het over tearing? Dat is helaas niet met GDI alleen te verhelpen, maar je kunt wel een D3D9 device maken die een WaitForVBlank() methode heeft. Een andere mogelijkheid is het vsync register van je videokaart pollen middels DLPortIO

[ Voor 13% gewijzigd door .oisyn op 15-04-2008 10:24 ]

[bart0l0meus]

Heel goed nieuws:D
Alle moeite was voor niks!
In borland bestaat een standaard component TPerformaceGraph die percies doet wat ik wil!
Het is gewoon een lopende grafiek, waar men een array invoert! percies wat we willen!

[Verwijderd]

.oisyn schreef op dinsdag 15 april 2008 @ 10:05:
[...]

Sorry maar dat is echt dikke onzin. Ik heb al talloze GDI animaties gemaakt zonder knippering. Waar knipperen bij windows vaak vandaan komt is de WM_ERASEBKGND message die standaard bij een BeginPaint() wordt verstuurd tijdens het afhandelen van een WM_PAINT. De default implementatie van die message vult het geïnvalidatete stuk met de standaard background HBRUSH van de window. Dat is simpel te voorkomen door een null HBRUSH in te stellen, of zelf de WM_ERASEBKGND af te vangen en niets te doen.

Weet ik

Misschien heb je het over tearing? Dat is helaas niet met GDI alleen te verhelpen, maar je kunt wel een D3D9 device maken die een WaitForVBlank() methode heeft. Een andere mogelijkheid is het vsync register van je videokaart pollen middels DLPortIO

Gaat wat ver denk ik voor dit topic, je hoort mij ook niet zeggen dat het onmogelijk is om 100% smooth te scrollen (lees mijn opmerking die je quote, let vooral op standaard Delphi/Windows (waaronder dus ook allerlei andere talen waarbij je direct op canvas tekent op een vrij standaard manier). Ik doel erop dat met standaard gedrag van windows canvas, met normale methoden zonder getruc dit bijna niet te doen is.

TS Kan natuurlijk ook een of andere game engine gebruiken voor dit project, komt ie er ook. Alleen is de vraag of ie het dan eind van dit jaar af heeft.

Laten we TS eerst 's een eind op gang krijgen daarna is het misschien interressant voor allerlei optimalisaties te bekijken.

Denk niet dat TS zit te wachten op allerlei trucs , om een en ander voorelkaar te krijgen.

[.oisyn]

Jij bent degene die kwam met trucs en optimalisaties . Maar je had het dus over tearing? Want dat is me nog een beetje onduidelijk uit je post.

[Verwijderd]

.oisyn schreef op dinsdag 15 april 2008 @ 13:22:
Jij bent degene die kwam met trucs en optimalisaties . Maar je had het dus over tearing? Want dat is me nog een beetje onduidelijk uit je post.

Trucs en optimalisaties voor normale componenten die mensen allerdagen gebruiken.
Niet alleen over tearing, maar ook enigszins niet 100% soepel scrollen.
(graphics zijn nu eenmaal niet de dingen waar ik me dagelijks mee bezig hou).

Maar ik houdt me altijd open voor tips/trucs/voorbeelden ...
( ben zelfs nieuwschierig eigenlijk , ).

[ Voor 10% gewijzigd door Verwijderd op 15-04-2008 14:33 ]

[bart0l0meus]

Oké, de grafiek plotten is opgelost;
hij krijgt elke 10ms een adc waarde via de com poort en plot deze op de grafiek, maar hier zal ik dus gebruik moeten maken van een interrupt lijkt me? of gewoon een while(1) waar hij continu op de com kijkt en plot.
Maar zoals ik al zij zou ik wel nog graag het programma verder willen gebruiken, zoals de range veranderen en andere instellingen veranderen, maar als er dus continu een while loop loopt, gaat dit dus niet. Iemand een idee hoe op te lossen, thread ofzo?

[RobIII]

Waarom plot je niet gewoon de waarde "onDataReceived"? Gewoon reageren op een event van de COM port. Niks geen while(1) of "interrupts" (hoewel dat laatste natuurlijk een beetje op een event lijkt). En dan natuurlijk gewoon de meetwaarde plotten op het tijdstip dat je 'm ontving, dus niet op x+1. Zodoende klopt je grafiek ook nog als je (onverhoopt) een tijdje geen waardes zou ontvangen.

(Eigenlijk zou je een interval timer moeten zetten om wél om de X ms een waarde te plotten, ook dan heb je geen 'interrupts' of 'while(1)' nodig maar plot je gewoon 'onTimer' de laatst gemeten waarde (of nul als er in de interval geen meting is gedaan). Kans is echter dat 't na verloop van tijd wat 'scheef' gaat lopen, dus daar zul je wel wat 'synchronisatie' moeten inbouwen)

[ Voor 36% gewijzigd door RobIII op 15-04-2008 18:05 ]

[bart0l0meus]

Maar ik lees de com poort uit met een functie uit een headerfile van iemand anders.
Met de functie Getchar, waar ik de waarde van de char mee return.
Hoe wil ik dan een return hier op maken? zo ver ik weet kan men geen event op de com poort maken, in iedergeval niet op windowsxp en hoger, of toch wel?

[Creepy]

Verwijderd schreef op dinsdag 15 april 2008 @ 13:35:
[...]

Trucs en optimalisaties voor normale componenten die mensen allerdagen gebruiken.
Niet alleen over tearing, maar ook enigszins niet 100% soepel scrollen.
(graphics zijn nu eenmaal niet de dingen waar ik me dagelijks mee bezig hou).

Maar ik houdt me altijd open voor tips/trucs/voorbeelden ...
( ben zelfs nieuwschierig eigenlijk , ).

Double buffering van een TForm aanzetten helpt enorm. Evenals zelf een backbuffer gebruiken om in te tekenen en die steeds te blitten naar je TGraphics/TBitmap/TWhatever. Met de VCL is het prima mogelijk om graphics smooth te laten bewegen. Dat zijn overigens redelijk standaard trucs. Als je je niet met graphics bezighoudt moet je natuurlijk niet zomaar concluderen dat iets niet zomaar kan in Delphi

[farlane]

bart0l0meus schreef op dinsdag 15 april 2008 @ 19:02:
Maar ik lees de com poort uit met een functie uit een headerfile van iemand anders.
Met de functie Getchar, waar ik de waarde van de char mee return.
Hoe wil ik dan een return hier op maken? zo ver ik weet kan men geen event op de com poort maken, in iedergeval niet op windowsxp en hoger, of toch wel?

Ja wel. Maar je poll routine in een timer event zetten en van daaruit je poort lezen is een betere optie. ( 10ms ga je niet halen trouwens maar dat terzijde )

[ Voor 4% gewijzigd door farlane op 15-04-2008 22:22 ]

[bart0l0meus]

oké, hoezo denk je dat 10ms niet te halen zijn?

[RobIII]

bart0l0meus schreef op dinsdag 15 april 2008 @ 22:25:
oké, hoezo denk je dat 10ms niet te halen zijn?

Omdat je onder windows blij mag zijn als je onder de 50ms komt _{met een standaard timer en wat default form controls}

[ Voor 11% gewijzigd door RobIII op 15-04-2008 23:54 ]

[.oisyn]

timeSetEvent() is je vriend

[Verwijderd]

Borland's TTimer gebruikt de oude DOS/Windows low resolution clock, en die wordt maar 18x per seconde getriggerd. Resultaat: je ondergrens ligt net iets boven de 50 ms.
Hier zijn wel een aantal vervangers voor (ZylTimer bijvoorbeeld), maar die zitten niet standaard in de VCL.

Edit: .oisyn, uit jouw TimeSetSevent link:
"This function is obsolete. New applications should use CreateTimerQueueTimer to create a timer-queue timer."

[ Voor 20% gewijzigd door Verwijderd op 16-04-2008 00:41 ]

[.oisyn]

Dus? Met timeSetEvent() is je app nog compatible met Windows versies voor Windows 2k

[Verwijderd]

Creepy schreef op dinsdag 15 april 2008 @ 20:39:
[...]

Double buffering van een TForm aanzetten helpt enorm. Evenals zelf een backbuffer gebruiken om in te tekenen en die steeds te blitten naar je TGraphics/TBitmap/TWhatever. Met de VCL is het prima mogelijk om graphics smooth te laten bewegen. Dat zijn overigens redelijk standaard trucs. Als je je niet met graphics bezighoudt moet je natuurlijk niet zomaar concluderen dat iets niet zomaar kan in Delphi

laat maar wat zien zou ik zo zeggen dan.

en dan wel zonder de zgn highres timers etc.
standaard is standaard toch ?

zie m;n eigen voorbeelden, redelijk smooth op zich, maar niet 100% smooth.

[ Voor 11% gewijzigd door Verwijderd op 16-04-2008 06:17 ]

[farlane]

.oisyn schreef:
timeSetEvent() is je vriend ...

Maakt het wel een stuk trickier aangezien die een eigen thread heeft van waar de callback komt.


_{Hmm raar, op de MSDN pagina wordt beweerd dat deze alleen voor WIndows Xp is, terwijl timeKillEvent vanaf Windows 95 aanwezig zou zijn. Lijkt me een slip up.}

[Creepy]

Verwijderd schreef op woensdag 16 april 2008 @ 06:13:
[...]

laat maar wat zien zou ik zo zeggen dan.

en dan wel zonder de zgn highres timers etc.
standaard is standaard toch ?

zie m;n eigen voorbeelden, redelijk smooth op zich, maar niet 100% smooth.

Eeeh? Je hebt toch echt een paar regels code nodig om het smooth te krijgen, dus nee, alleen VCL componenten slepen en verder niks is echt niet voldoende. Of versta je wat anders onder standaard? Overigen zijn highres timers wat mij betreft ook standaard, je hebt er echt geen 3rd party component voor nodig

Ik zal je code vanavond eens bekijken maar je grafiek is toch al aardig smooth dacht ik zo.

[Verwijderd]

Creepy schreef op woensdag 16 april 2008 @ 09:38:
[...]

Eeeh? Je hebt toch echt een paar regels code nodig om het smooth te krijgen, dus nee, alleen VCL componenten slepen en verder niks is echt niet voldoende. Of versta je wat anders onder standaard? Overigen zijn highres timers wat mij betreft ook standaard, je hebt er echt geen 3rd party component voor nodig

Ik zal je code vanavond eens bekijken maar je grafiek is toch al aardig smooth dacht ik zo.

is het ook voor paar minuten wat prutsen

Probleem is dat ik natuurlijk snap dat 100% smooth kan, het is alleen de vraag of die manieren in het verlengde van de opdracht van TS liggen. Ben trouwens wel benieuwd naar die grafiek component van TS, deze wordt niet meer geleverd bij Borland/CodeGear producten (althans bij delphi niet ?).