flipDMABuffer without flipping the target buffer

[ccrawford]

TL;DR: Is there a way to flipDMABuffer without actually displaying the other buffer?

My display project includes information that scrolls vertically (headers stay put, bottom lines scroll up) and horizontally (text scrolls across the screen in a single line.) They both have static text and scrolling text on the same screen.

I initially used a single buffer and did the horizontal text by blanking a horizontal rectangle and rewriting the text. Works great, no flicker.

When I added vertical scrolling I switched to double-buffering to prevent flickering of the non-scrolling text. However that introduced flickering of the horizontal scroll screens because I was not redrawing the entire screen, just the scrolling line. It is complex/expensive to redraw the static screen elements for each scrolling frame.

Psuedo code:

// Build the base screen
clearScreen();
createFullScreen(); // Assume this is an expensive/long function.
flipDMABuffer();
clearScreen(); // Clear the background screen in prep for the loop

// Scroll the single line text (this works great with single buffer but has a slight flicker when you show the blank screen for a millisec)
while (scrolling)
flipDMABuffer(); // To make the full display active
drawRectangle(scrollArea, BLACK); // Blank the scroll area
writeScrollText( x++, y, text);
flipDMABuffer(); // Return the full display with the shifted text

What I really need is a "flipDMABufferNoDisplay()" function (or a flag to flipDMABuffer) so I can make the other buffer active without actually sending the other screen to the display. I wrote this function in the library and it works great, but I'm wondering if there's a better way.

Here's what works for me:

  inline void flipDMABuffer(bool flipOutput=true)
  {
    if (!m_cfg.double_buff)
    {
      return;
    }
	
    if(flipOutput) dma_bus.flip_dma_output_buffer(back_buffer_id);
    
    back_buffer_id = back_buffer_id^1;
    fb = &frame_buffer[back_buffer_id];	
	
  }

Is there a better way to accomplish what I'm doing here? Or is this a reasonable enhancement?

[mrcodetastic]

Don't you need to call createFullScreen(); twice? Write it once for the front buffer and then the back?

The back buffer is its own completely blank canvas. You'll get flicker because every second buffer flip has no static stuff drawn

[ccrawford]

Exactly. The problem I have is that "createFullScreen()" is computationally complex. I'd rather not have to call the entire routine dozens of times just to scroll a text line that is too wide to display on screen. I could do some major refactoring, but I am where I am, and going back to a virtual single buffer fixed my problem with a couple lines of code.

(BTW: Thank you so much for the library. I've used it in a couple projects now. You rock.)

[mrcodetastic]

Exactly. The problem I have is that "createFullScreen()" is computationally complex. I'd rather not have to call the entire routine dozens of times just to scroll a text line that is too wide to display on screen.

I appreciate that, but I think you're not understanding what I am saying. You shouldn't get 'flicker' on the static stuff when you use double buffering. The only reason I can think of you getting flicker is that one of the buffers doesn't have the static stuff setup.

// Build the base screen
clearScreen();
createFullScreen(); // Assume this is an expensive/long function.
flipDMABuffer();
clearScreen(); // Clear the background screen in prep for the loop

Should be

// Build the base screen
clearScreen();
createFullScreen(); // Assume this is an expensive/long function.
flipDMABuffer();
clearScreen(); // Clear the background screen in prep for the loop
createFullScreen(); // Assume this is an expensive/long function.

Then both buffers have the static stuff ready and painted now... just don't actually write over it. You will still need to 'wipe' only the section that changes on both buffers.

(BTW: Thank you so much for the library. I've used it in a couple projects now. You rock.)

Thank you for the kind words. Glad you find it of use :-)

[ccrawford]

You are 100% correct as to the cause of the flicker. And you're right: The way the library expects me to work is to build each buffer completely and that would resolve the flicker. You are also right: I could get away with the expensive call 2x, not dozens of times. I was trying to reduce the expensive call to 1x by only manipulating the live buffer and redisplaying.

If the proposed extension isn't in alignment with the way you want the library to work or would confuse other users, that's totally cool and I'll drop it. Thanks for engaging here.