Recent

Author Topic: Fast Screen Updating program  (Read 3142 times)

JL69

  • Newbie
  • Posts: 3
Fast Screen Updating program
« on: February 18, 2018, 12:27:54 am »
Hi, I downloaded Lazarus recently.  I had previously looked into possibly starting with a nice RAD environment like Delphi but between the cost and uncertainty about Embarcadero's future, never went forward with it.  Tried VS and couldn't get a simple program to compile!  Couldn't believe it.  So glad I found Lazarus/FPC! 

I am trying to write a small program to simulate a real-time stock market ticker "tape" similar to this one  https://www.youtube.com/watch?v=taqqFCRmXAc.  In some seconds there are no updates, in others there would be many rapid updates, some with 300 updates in one second (which may be staggered 100 trades in one millisecond, 250 millisecond gap and then 40 trades, then 250 millisecond gap and then 160 trades).  I need to create a very close to realistic real time simulator.

I took an existing Lazarus example (the drop files example) which had a memo box.  I added lines to the memobox with a millisecond gap (using Delay and Millisecondsbetween).  This works as expected except that when I use Memo1.Refresh between each line added (each trade), the delay of the refresh command itself slows the speed of the program dramatically.  (If I don't refresh between lines added, the speed of the control seems blazingly fast though.)

Is there any way I can speed the memo refresh command up?  I am guessing that I would have to do some heavy inline assembly code to get this to work the way I am thinking.  I would appreciate any help here. Thanks.

ASerge

  • Hero Member
  • *****
  • Posts: 2222
Re: Fast Screen Updating program
« Reply #1 on: February 18, 2018, 02:40:18 am »
Are you sure that it is necessary?
TMemo is a GUI element, i.e. for the user's eyes, and therefore can be updated occasionally. For example, once a second, or if you want to look very fast, then 5 times a second!

JL69

  • Newbie
  • Posts: 3
Re: Fast Screen Updating program
« Reply #2 on: February 18, 2018, 02:51:47 am »
Ok, I guess maybe I don't know how to use the Memo control property. How would I set the memo control so it updates 5 times a second?

Handoko

  • Hero Member
  • *****
  • Posts: 5131
  • My goal: build my own game engine using Lazarus
Re: Fast Screen Updating program
« Reply #3 on: February 18, 2018, 02:53:50 am »
...  This works as expected except that when I use Memo1.Refresh between each line added (each trade), the delay of the refresh command itself slows the speed of the program dramatically.

What is your OS, Lazarus version and widgetset?

Can you please write a demo showing that issue, compress them (exclude: binary, *.bak and lib folder) and send it to the forum?

JL69

  • Newbie
  • Posts: 3
Re: Fast Screen Updating program
« Reply #4 on: February 18, 2018, 03:24:24 am »
Lazarus version is 1.8, FPC version is 3.0.4.  Not sure where to find widget set version.  But I installed the most current Lazarus/FPC versions about a week ago.

All I did was open the example file dropfiles.lpi which was installed with Lazarus and added the starred lines below to the section of Unit1.pas file (and added Crt to "Uses" clause):

Actually, now that I look at this again, this may be ok.  When I drop 10 files on the form, the code below tells me it is taking 176 ms to write those 10 files to Memo1 (I know the timer functions I am using below may not be the most accurate), which would be 17 ms each line.  Is there anyway to improve this updating time?

procedure TForm1.ApplicationProperties1DropFiles(Sender: TObject;
  const FileNames: array of String);
var
  I: Integer;
begin
  Start := Now;
  Memo1.Lines.Add(TimeToStr(Now));
  Memo1.Lines.Add(IntToStr(Length(FileNames)) + ' file(s) dropped on Application:');
  for I := 0 to High(FileNames) do
    begin
    Memo1.Lines.Add(FileNames);
 
  *Memo1.Refresh;
  *Delay(1);
 
  *end;
  *Stop := Now;
  *Memo1.Lines.Add(TimeToStr(Stop));
  *Memo1.Lines.Add(IntToStr(MilliSecondsBetween(Stop,Start)));
end;                 

molly

  • Hero Member
  • *****
  • Posts: 2330
Re: Fast Screen Updating program
« Reply #5 on: February 18, 2018, 03:31:59 am »
... Lazarus and added the starred lines below to the section of Unit1.pas file (and added Crt to "Uses" clause):
Mixing GUi with crt is a bad idea. Just remove that unit from your uses clause.

Code: [Select]
  *Delay(1);
use sleep instead.

But even then, why would you want to do that if your aim is to be as fast as possible ?

I don't seem to remember ever having to use memo.refresh manually. beginupdate/write loads of stuff/endupdate usually does the trick.

You add lines while the ticker you showed in the video (just) changes existing lines. Of course they should be added first, but once present you update the existing/present entries.

PS: a small riddle for you: how much of those 'changes in gui updates' are possible to notice by a human eye ?
« Last Edit: February 18, 2018, 04:11:14 am by molly »

Thaddy

  • Hero Member
  • *****
  • Posts: 14204
  • Probably until I exterminate Putin.
Re: Fast Screen Updating program
« Reply #6 on: February 18, 2018, 09:53:33 am »
A grid is usually a better option than a memo, because the painting of the cells is usually more optimized by better use of clipping. E.g. when bid or ask has changed only the cell for bid or ask will get updated. When trades change, only trades will updated. And that is much, much faster than a full repaint of a memo.
But what molly says is true: depending on exchange, updates are such that they can't be followed by the human eye: they are indicative only. Most trades are therefor effectively done by trading algorithms.
Human trades are done by setting a buy or sell moment (aka stop-loss) and executed automatically when the actual price hits the spot. If you don't trade like that you are always behind the market.
A professional - like my old employer Alex/Binckbank - team can reach visual updates of 15 Ms in custom software and 25-30 in a browser and that is too slow 8-) to follow the markets. Although every and all actual trades could be registered in the huge Oracle clusters (buffered). Depending on data provider, but that's a different story: we've see data providers drop trades, which is unacceptable.

Note pricing is not that important: use a priority queue to display actual trades first, volume second and bid ask last.
« Last Edit: February 18, 2018, 10:10:08 am by Thaddy »
Specialize a type, not a var.

 

TinyPortal © 2005-2018