Post by jamesbowman on Apr 14, 2020 20:25:09 GMT -8
Right, this is the GD2/3 hardware running out of render time because of display list complexity.
More detail: the FT8xx generate the output image on-the-fly at 60 Hz. If the display list is long or complicated, it can start to "underrun" and the graphics engine doesn't finish each raster line before it's sent out to the LCD.
GD3X has "adaptive framerate" enabled which slows down scanout when instead of "underrun".
So, I think one way of making draw_arc() less expensive is to use ScissorXY() and ScissorSize() to reduce drawing to just those pixels that are part of the arc.
Right now each arc is clearing the whole screen, and drawing many pixels outside the arc's square.
Thanks jamesbowman for the quick reply. Your suggestion fixed the problem.
I was reading this in the "Performance" section of the FT800 series programming manual (page 31):
The graphics engine has no frame buffer: it uses dynamic compositing to build up each display line during scan out. Because of this, there is a finite amount of time available to draw each line. This time depends on the scan out parameters (REG_PCLK and REG_HCYCLE) but is never less than 2048 internal clock cycles.
Some performance limits: - The display list length must be less than 2048 instructions, because the graphics engine fetches display list commands one per clock. - The graphics engine performance rending pixels is 4 pixels per clock, for any line with 2048 display commands the total pixels performance drawn must be less than 8192. - For some bitmap formats, the drawing rate is 1 pixel per clock. These are TEXT8X8, TEXTVGA and PALETTED. - For bilinear filtered pixels, the drawing rate is reduced to ¼ pixel per clock. Most bitmap formats draw at 1 pixel per clock, and the above formats (TEXT8X8, TEXTVGA and PALETTED) draw at 1 pixel every 4 clocks.
This seems to suggest that the limitation is capped at 2048 instructions. Per my count, my display list is ~200 instructions. Can you comment on this?