Slide transition not working with single framebuffer

[Pirol]

Hello,

I’m trying to understand some issues we have with the slide transition. The slide transition uses the snapshot widget functions to copy the "old" screen to the animation storage to combine this screen with the incoming screen.

Here is the code:

SlideTransition(const uint8_t transitionSteps = 20)
 : Transition(),
 snapshot(),
 snapshotPtr(&snapshot),
 handleTickCallback(this, &SlideTransition::tickMoveDrawable),
 animationSteps(transitionSteps),
 animationCounter(0),
 calculatedValue(0)
{
 if (HAL::USE_ANIMATION_STORAGE)
  { 
 snapshot.setPosition(0, 0, HAL::DISPLAY_WIDTH, HAL::DISPLAY_HEIGHT);
 snapshot.makeSnapshot();
 ...
 }
 ...
}

So far so good. When I use the snapshot functionalities with a "single framebuffer strategy" in CubeMx and an additional animation storage, the "old" screen consists of just random pixels during the sliding process, see image. The pixel data on the screen is the same as the pixel data in the animation storage.

 

When I use a double buffer strategy with an additional animation storage and same project settings, everything works well and as expected.

Do you have any ideas why it did not work with a single framebuffer but did work with a double buffer? I do not understand the correlation between the number of framebuffers and how the animation storage is filled. Shouldn’t it work in both cases?

We use a STM32F469.

Thanks in advance for your answers.

[Osman SOYKURT]

Hello Pirol,

My guess is that these random pixels are due to transferring 832 length pixels and not 800 as it should be. By the way, in the HAL_DSI_EndOfRefreshCallback function, you can see these "832" hard coded values.

In double framebuffer strategy you will always show the 800 first pixels in length on your screen, but with single framebuffer it's not the same because you'll "move" the framebuffer to the side, meaning that the residual 32 pixels will show up to your screen.

I've wrote an article few months ago about enabling double framebuffer on the STM32F469-disco. I guess the part where I set the Color Frame Buffer Line Length should maybe work on your side. I let you try it and come back to me if you have more question.

2- Configuration of the LTDC on STM32CubeMX : under "Layer Settings"> "Frame Buffer">"Layer0 - Color Frame Buffer Line Length", set "832" value.

 

/Osman

[Pirol]

Hello Osman,

thank you for your answer.

We use the display with FMC, not LTDC, so your solution unfortunately does not work for us. I'm sorry, I should have said that in the post.

I can't find the function HAL_DSI_EndOfRefreshCallback in our project. I guess that's because our display interface is parallel while that function is for serial interfaces.

We use the function TouchGFXHAL::flushFrameBuffer to send the data to the display. There we send the exact amount of pixels, not some more. So I think we do not have the case with residual pixels.