Double buffering?

[Tronix286]

Hello,
I read the documentation for the library but I don't understand how I can use the backbuffer. I want to use a low resolution mode, something like 320x240x8, so I have enough memory for a second buffer. I want to do all the rendering of points in this buffer, and then just swap the display buffer and my buffer to avoid flickering. Is this possible?

[Panda381]

Yes, you're right, I see that I didn't describe the back buffer sufficiently and didn't prepare any examples.

In the simplest case, it should be enough to change the address of the frame buffer 'buf' in the sDispHstxVSlot slot descriptor and wait until the current scan line 'line' in the sDispHstxVModeState state descriptor changes. But I don't use it that way in my projects. Instead, I leave the display buffer at a fixed address. I draw to the back buffer and then transfer the changes to the display buffer with a simple copy. An example of use is in the PicoLibSDK library in the _devices\picopad device, when the USE_DISPHSTX_DISPBUF parameter is 1 - in this case, the display runs from DispBuf, drawing runs to FrameBuf, and changes are transferred with DispUpdate().

The reasons are - transferring the image between buffers is usually very fast, especially when DMA transfer is used or when only the changed part of the image 'dirty area' is transferred. This also allows the use of a back buffer smaller than the frame buffer. When there is a shortage of memory, the image is divided into several 'strips', the back buffer is as high as one 'strip'. Rendering takes place in the back buffer strip, and the rendering functions crop the coordinates to that strip only. The contents of the strip are then transferred to the display buffer and drawn into the next strip.

Another reason for using this method is the uniformity of use for VGA/HDMI displays and built-in LCD/OLED displays. The drawing functions are called in the program, and after the scene is finished drawing, the DispUpdate() function is called, which takes care of updating the changes - either it sends the image from the frame buffer to the LCD/OLED display, or it transfers the image from the back buffer to the display buffer, or it does nothing (if drawing was done directly to the display buffer).

The DrawCan drawing function library contains a pointer to the buffer into which drawing takes place, 'buf'. By default, the drawing library connects to the display buffer of the display library, and drawing takes place directly into the display buffer. When using a back buffer, a separate buffer is used for display, drawing is done to the frame buffer, and after drawing is complete, the changes are transferred to the display buffer with DispUpdate. In cases of output to an LCD/OLED display, only the changed 'dirty' area is transferred to the display because the transfer is slow. However, with VGA/HDMI displays, the entire frame buffer is transferred, as this is a faster operation than doing it in dirty sections.

So, the assumed easy usage is: Create a separate back buffer. If you use your own drawing functions, e.g., 3D rendering, draw to the back buffer and transfer the image with memcpy to the frame buffer. If you are using the DrawCan drawing library, set the display buffer address to 'frontbuf' in the sDrawCan descriptor, the back buffer address to 'buf', and update the image using the DispUpdate() function.

Unfortunately, I see that the separate DispHSTX library is not up to date. The newer version of the library is part of the PicoLibSDK library, which also includes the image update functions. I have not updated the separate DispHSTX library because it would be difficult to ensure sufficient isolation from the other functions of the PicoLibSDK library.

[Tronix286]

Thanks for such a detailed explanation, I'll have to think about it and try it over the weekend.

I'd prefer to simply change the buffer address (buffer pointer) rather than use memcpy. The problem is, I'm trying to build something like a simple X-Y oscilloscope, using ADC in continuous mode via DMA with two circular buffers and interrupts for each buffer overflow. As soon as one buffer overflows, it automatically switches to sampling data in the other, and in the interrupt, I set a flag indicating that the buffer is ready to begin plotting points. In the main loop, I wait for the new_adc_data_ready flag for one of the buffers and plot points in the X and Y directions. I am using DrawPoint. Then I blur the screen using the 8 nearest points to create a "persistence" effect.
Box[i] = (Box[i-1]+Box[i+1]+Box[i+WWIDTH-1]+Box[i+WWIDTH+1]+Box[i-WWIDTH-1]+Box[i-WWIDTH+1]+Box[i+WWIDTH]+Box[i-WWIDTH])/8;

Therefore, a long-running operation like memcpy, given that the DMA bus is busy with continuous ADC processing, seems questionable to me.
Another limitation is that I can't use _fast modes and only work at the standard 126 MHz because I need to sample data at 250 kHz, and I have four ADC channels (X, Y, Z (blank) and an empty one for parity ADC buffers). This means my ADC must be running at no less than 1 MHz (1 MHz / 4 = 250 kHz). Therefore, I use SYS_CLK 126 MHz and a divider as the ADC clock. The standard 48 MHz is too low for me. And the high speeds of _fast modes cause ADC malfunctions.

But thanks again, I'll think about everything you said again and try to squeeze something out of it over the weekend. Thanks!