Finally got my graphing calculator working on an STM32 board

I went through almost the same arc with mine last winter, except I was plotting on one of those cheap ILI9341 modules driven over SPI. My bottleneck turned out to be floating point math, not the display. Evaluating sin and cos thousands of times per frame on the F103 was killing my frame rate until I switched to fixed point with a 1024 entry sine lookup table. Went from about 2 frames a second to something like 15, which was enough to feel smooth. The clipping thing you mention is so real. I never wrote a proper line clipper, I just subdivided any line that crossed the edge into short segments and skipped the ones outside bounds. Crude but it worked and took an afternoon instead of a week. For your zoom and pan plans, I would actually push you toward buttons first. I got a resistive touch panel working and the calibration drove me nuts, the coordinates drifted depending on where you pressed and how hard. Ended up with four buttons on a breadboard and honestly the panning feels better anyway because it steps in nice increments instead of drifting all over the graph. Touch is doable but expect a weekend of fiddling before it feels right. One tip on the wireframe sorting, painting a background rectangle behind each quad made my depth sorting mistakes way less obvious.

On the input question, I'd lean toward buttons over touch from experience. I put a resistive touch panel on mine and spent way more time fighting it than actualy using it. The readings would jump around depending on how hard I pressed, and sharing the bus between the display and the touch chip caused glitches until I added proper chip select handling. Two point calibration got it usable but never great, and my fat thumb covered half the graph area anyway. What actually worked better for a graphing tool was a rotary encoder plus a couple of push buttons. Turning the knob to zoom in steps felt natural, holding it while turning panned around, and a single button press recentered everything. It took maybe an evening to wire up and the code was trivial compared to the touch mess.

That said, your clipping fix rings true. I had the same lightning bolt artifact until I clamped my line endpoints and it instantly cleaned up. One thing I'd suggest before the touch route: check whether your panel is resistive or capacitive. The cheap add-on boards are usually resistive and honestly not worth the hassle for this kind of interface.

The jump from two frames a second up to fifteen sounds huge for a tiny board. It makes me wonder about the power. Since you are doing all that math and driving the colors so fast, is the whole thing drawing a lot of power? I tried running something like this on my old computer and the fan started spinning way up. I don't want my board to get too hot while it is running your complex graphics. Does the power consumption change much once you get the speed up and the display working properly?

I found that when I optimized the rasterization loop for the wireframes, I shaved off a good 15% of the processing time. The trick was moving the coordinate conversion out of the inner drawing loop. You keep checking bounds and doing scaling operations for every single pixel drawn, which adds up quickly. On my setup, I was dealing with over 4000 vertices per frame, so minimizing that overhead was crucial. I used a simple pre-calculated scaling factor array to handle the X and Y transformations before the actual draw call. It really helped keep the frame time stable.

I'd also suggest looking at the buffer size for the display update. If your color depth is 16 bit, check if you can reduce the active area being rewritten. Just clearing the whole buffer on every frame is wasteful if you're only updating a small portion of the graph. I managed to cap my redraw area at about 200x300 pixels for the plot region without seeing any aliasing issues.