Discussing the article: "Building AI-Powered Trading Systems in MQL5 (Part 11): Optimizing the UI with Frame Throttling and Partial Rendering"
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Check out the new article: Building AI-Powered Trading Systems in MQL5 (Part 11): Optimizing the UI with Frame Throttling and Partial Rendering.
We optimize an MQL5 canvas interface to stay responsive under rapid input without changing its appearance. The article adds a direct-buffer canvas for block region copies, caches text widths and glyph coverage, caps repaints at 60 fps (16 ms), and limits drawing to panes and regions that actually changed. As a result, hover, scroll, and popups render smoothly without full-panel redraws.
A canvas interface can look finished and still feel sluggish. Ours reached that point. Every hover, scroll tick, and popup forced a full repaint of the dashboard. Each repaint also re-measured text through the operating system from scratch. At rest, the waste is invisible. But if you drag the window or scroll a long chat, redraws accumulate faster than they clear. The interface then stutters when it should feel fluid. The panel was doing an enormous amount of correct work to produce a picture that barely changed from one frame to the next. This article is for MetaQuotes Language 5 (MQL5) developers who build canvas interfaces. It targets those who want their panels to stay responsive under rapid interaction instead of choking on their own redraws.
In our previous article (Part 10), the interface repainted the whole panel on every event and measured every string each time it drew. In this article, we speed it up without changing its appearance. We add a direct-buffer canvas for bulk region copies. We cache text widths and rendered glyphs. We cap repainting at roughly sixty frames per second so event bursts collapse into one frame. We also repaint only the pane or region that changed.
The root problem is that drawing is expensive and events are cheap. Moving the mouse across the panel can fire dozens of hover events a second, and a scroll wheel or a window drag fires even more. If each one triggers a full repaint of the dashboard, the program spends all its time redrawing, and because a repaint rebuilds the whole picture, most of that work reproduces pixels that did not change. The two techniques in this part attack that waste from two directions: doing fewer repaints, and making each repaint smaller.
Frame throttling handles the first. Instead of painting on every event, we set a minimum spacing between frames, about sixteen milliseconds, which is roughly sixty frames a second and faster than the eye needs. When an event arrives inside that window, we do not paint it immediately; we mark that a frame is pending and let a short timer flush it once the interval elapses. A burst of forty mouse-move events no longer produces forty repaints; it produces one. Once the burst ends, the timer returns to an idle cadence, so the panel costs nothing while it sits still. The illustration below shows this on a timeline, with a dense burst of events reduced to a single painted frame per window.
Author: Allan Munene Mutiiria