Herman, Now you are speaking my language. I do save the last data or plot for some calculations in static arrays and then substitute the plot for the code when I am trying to speed up the UI for some operations.
My preferred technique to speed up the UI without doing a lot of extra code and static array memory, was to just reduce the number of bars with a SetBarsRequired() command at the end of the formula. This was only partially successful though. All my looping code will reduce the number of bars, but the fast AFL array operations do not. They are stuck with the highest number of bars ever requested since formula startup. I look forward to the day when I have control of reducing the number of fast AFL bars on the fly. That is the easy way to to generally speed things up. Then combined with judicious use of saving plots in static arrays can give the rest of the speedup for the type of custom UI work that we do. I even considered if I should create a generic template for every module that generates plots to save the plots or restore then based on a static variable. The problem with this is that it would slow down normal operations because of all the saving of static arrays. I use a state machine that only saves the static arrays during the first pass of the sequence of a UI operation that is multi-pass and time sensitive, like dragging an element around the chart. Many of my UI functions require multiple AFL passes to complete, and I have routinely tried to reduce refresh times, and reduce the number of formulas that execute to speed up the chart to make the UI operation faster. Perhaps, I should consider killing everything other than price bar plots and Gfx plots when processing any multi-pass UI function. I have a static variable called HurryUp that most of my functions or modules do something with to reduce computation time. I really have to do some major speedup code before I can take advantage of faster than one second refreshes. The 0.1 second refreshes will be very useful to me at that point. BR, Dennis On Aug 2, 2010, at 3:48 PM, Herman wrote: > > > To give you software control the in-line RequestTimedRefresh() must have > priority. I have never used the setting in Preferences so I am not speaking > from experience here, I have it set to zero - I am mostly looking for faster > execution, not slower/timed/paced executions. Remember that these settings > determine the MINIMUM refresh interval, if you quotes come in more frequently > your chart will refresh more frequently. Status("redrawaction") is true when > a timed refresh takes place, false during other (RT quote, click, Param > actions, etc) refreshes. > > I just see TJ's comment coming in: "These refreshes are independent. If you > specify both you will get twice as much." I didn't know that. > > I do speed up refreshes on-the-fly, you can do similarly that also between > panes/charts. For example the code I am looking right now speeds up my chart > refreshes when I move my mouse over the chart, or when it is over one of my > gfx buttons: > > PrevMX = Nz( StaticVarGet( "LastCursorXPosition" ) ); > PrevMY = Nz( StaticVarGet( "LastCursorYPosition" ) ); > MouseAction = CM = MX != PrevMX OR MY != PrevMY; > StaticVarSet( "LastCursorXPosition", MX ); > StaticVarSet( "LastCursorYPosition", MY ); > > if( Nz(VarGet( "OnButton" ) ) OR MouseAction ) RefreshTime = 0.1; > else RefreshTime = 1; > RequestTimedRefresh( RefreshTime ); > > "OnButton" is a variable that is set when my cursor is over a gfx control > button, regardless where it is on the screen. > > To "skip" over panes/formulas while retaining the display is a little more > difficult, it requires saving display arrays in static variables. There is no > graphic FreezeDisplay() command. Somewhat slower than a FreezeDisplay() would > work, if we had one, you can substitute static variables for the calculated > arrays when you want to skip the formula. I don't remember having actually > done this but I am thinking of applying this technique in a current > application. It should work... > > You can use Status("redrawaction") or the GetPerformanceCounter() timer to > create your delays. > > Using the same code in each pane should significantly reduce the work > involved to try timing schemes, just one formula to change ;-) > > btw, what is your formula execution time? > > Doing a search in Help for refresh, timing, and such keywords will lead you > to some distributed bits of information that can prove useful. > > Best regards, > herman > > > > At the moment I'm on a basic one second refresh across > > all charts (set via preferences > Intraday)... > > > All my charts use the same piece of AFL (insert linked > > into each chart)... I like the same functionality in each chart. > > > I will have to think about adjusting the refresh times > > across charts. Not sure how I'd work that right now... I'm > > still struggling with RequestTimedRefresh() vs the > > preferences>intraday setting... you must know Herman.... > > which one takes precedence...? > > > > > ------------------------------------ > > > **** IMPORTANT PLEASE READ **** > > This group is for the discussion between users only. > > This is *NOT* technical support channel. > > > TO GET TECHNICAL SUPPORT send an e-mail directly to > > SUPPORT {at} amibroker.com > > > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at > > http://www.amibroker.com/feedback/ > > (submissions sent via other channels won't be considered) > > > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: > > http://www.amibroker.com/devlog/ > > > Yahoo! Groups Links > > > > > >