Draw command in V12 causing Graphics Lag

• 03/20/2023 at 2:30 PM #211800
  Philstrading

  Hi

  I have a number of indicators etc that work extremely well in V11 through IG.

  In version 12 via PRT they initially worked well also, then at some point during development graphics lag got introduced.

  When checking this out it related to the draw command, literally drawing anything on the chart on price using code is causing a large amount of lag and choppiness.

  So PRT support has had no joy. Its not the coding and my view is that it relates to a change in requiring more of the graphics card processing than it did before a change.

  This conclusion is due to the fact that i do have 2 cheapish cards in my system, but this isnt an issue for V11… in V12 I’m now getting the lag but didnt initially and my system hasnt been modified. When using on a fambambidozy GSI higher spec card on my sons computer this isnt an issue as the card copes with the processing.

  Change my card for sure yeh, but thatis an expensive swapout albeit probably a necessary one…

  Question is has anyone else with a cheapy card running V12 experienced the same?

  

  Philstrading

  Participant

  Topics: 24

  Replies: 126

  Been thanked: 43 times
  03/20/2023 at 2:34 PM #211802
  Nicolas

  Hi Phil,

  I did not encounter such lags about graphics in V12. In fact, I can’t see any difference. In order to replicate, could you please share with us a simple example of code, so I could make comparison on my own. Thank you.

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20863

  Been thanked: 4773 times
  03/20/2023 at 2:57 PM #211808
  Philstrading

  Hi Nicolas, thanks for the swift response there, any simple draw code poses the issue.

  PRT support sent me some commands to try and they all lagged, literally any draw command in the code created a lag, but only after a certain point in time during the development stage..

  So I was asked to add the code and I’ll put it into a code box also, but it produces the lag all the same but only in Version 12. Bear in mind I have 2 cheapy cards in though they are reasonable, and Version 11 is not currently posing an issue with any draw commands, olny version 12, so to me I believe there has been a change to draw more from local graphics processing in the upgrade, purely based on the fact that V11 on the same machine runs perfectly smoothly. I do also usually run through Java and you cant do that in version 12, but it was initially not an issue when I started using the beta, it came some months later.

  DRAWTEXT(“H”, barindex, high)
  DRAWTEXT(“L”, barindex, low)
  return close

   &

  DRAWTEXT(“H”, barindex, high,dialog,standard,11)
  DRAWTEXT(“L”, barindex, low,dialog,standard,11)
  return close

  draw command code

  defparam calculateonlastbars=500 DRAWTEXT("H", barindex, high) DRAWTEXT("L", barindex, low) return close

  1 2 3 4

  defparam calculateonlastbars=500 DRAWTEXT("H", barindex, high) DRAWTEXT("L", barindex, low) return close

  2nd code asked to try

  defparam calculateonlastbars=500 DRAWTEXT("H", barindex, high,dialog,standard,11) DRAWTEXT("L", barindex, low,dialog,standard,11) return close

  1 2 3 4

  defparam calculateonlastbars=500 DRAWTEXT("H", barindex, high,dialog,standard,11) DRAWTEXT("L", barindex, low,dialog,standard,11) return close

  in my own code I have code such as

  defparam calculateonlastbars=500 drawtext("L", barindex[1] , low[1]-((high[1]-low[1])/100)*25)coloured(0,0,255) return

  1 2 3

  defparam calculateonlastbars=500 drawtext("L", barindex[1] , low[1]-((high[1]-low[1])/100)*25)coloured(0,0,255) return

  So thats just a percentile way to keep the distance so that different timeframes dont need adjusting, but it doesnt really matter, they all cause lag.

  The indicator is far more complex than that, but the complexity not the issue, drawing a simple letter on price causes lag. Obviouly calculateonlastbars is not required in this short bit of code but I do limit it with the indicator..

  

  Philstrading

  Participant

  Topics: 24

  Replies: 126

  Been thanked: 43 times
  03/20/2023 at 2:58 PM #211809
  Philstrading

  thats a typo there of course in the last one

  

  Philstrading

  Participant

  Topics: 24

  Replies: 126

  Been thanked: 43 times
  03/20/2023 at 3:03 PM #211810
  PeterSt

  Graph and/or GraphOnPrice should be avoided like the plague. Within a couple of minutes and Backtesting with 200K bars in V12 the consumed memory is at 11GB and from there all stalls.  After the one and only backtest, this memory-eating emerges, all further idle.
  100% same code under V11.1 and no issues there. No Graph and GraphOnPrice active and in that case also no issue in V12.

  Of course this is PRT-IB (V12 only runs there, AFAIK).

  I created a Technical Report for this on March 7.

   

  

  PeterSt

  Participant

  Topics: 73

  Replies: 2503

  Been thanked: 805 times
  03/20/2023 at 3:07 PM #211811
  Philstrading

  Sounds suspiciously similar and likely related as its all drawing on price, my tech supports go to PRT directly but to no avail on this one

  Glad to know its not just me then..

  The more drawing on price issues sent in the better methinks..

  

  Philstrading

  Participant

  Topics: 24

  Replies: 126

  Been thanked: 43 times
  03/20/2023 at 3:26 PM #211812
  PeterSt

  This is indicative for the problem;
  Java can take ~ 6GB of consumed memory before things start to slow down. When over 8GB things usually are irreversible and a restart of the platform is necessary. The top one you see below is V12 and the 11Gb just is there after minutes of a first backtest right after starting the platform. Right After the backtest the consumed memory is 4GB. And then it grows and grows and grows.

  PRT is historically known for its memory leaks (always in the realm of graphing) and nothing has been done about it that I can see. OK, one thing : 6 months or so ago the Garbage Collect process (which actually is within Java) started to show different behavior and I think things improved somewhat from there. But right now inb V12 ? right now to me it seems that each drawn pixel requires a new handle which is never freed (hence a memory leak).

  N.b.: The lot combines which way less efficient data loading. So that part alone consumes 2 or so GB more for 200K bars than in V11.1. This is how V12 starts out with 4GB of usage, which this should be maybe 700MB (in my case and for 200K bars on one instrument).

  Also notice the crazy CPU usage.

  

  PeterSt

  Participant

  Topics: 73

  Replies: 2503

  Been thanked: 805 times
  03/20/2023 at 3:33 PM #211815
  Philstrading

  I’ll try and look at memory usage later on V12 when no ttrading with V11 and comment

  

  Philstrading

  Participant

  Topics: 24

  Replies: 126

  Been thanked: 43 times
  03/20/2023 at 9:37 PM #211846
  Philstrading

  https://youtu.be/LuUqYdnifs0

   

  Is a link to show the effects of one window. It is a lot worse with multiple windows.. the mouse moving across is actualy attempting to drag the screen…

   

  V11 is smooth that is V12 shown

  

  Philstrading

  Participant

  Topics: 24

  Replies: 126

  Been thanked: 43 times
• Author
  Posts