Double buffer, one buffer is not updated

[LRose.3]

I have an application developed using touchGfx 4.13 where we are using a double buffer and it works fine. I have now migrated to touchGfx 4.17 but it seems like the double buffer is not working as expected. When I change from a longer text to a shorter text in a text area (change text from ‘Medium’ to ‘Low’ and resizeToCurrentText and move to center of the display) the longer text that is outside of the shorter text area is flickering in the screen (resulting MLowm, where M and m is flickering). It seems like the longer text that is outside of the shorter text area is not removed from the one frame buffer. In this particular example the error can be solved by keeping the text area size fixed and invalidate the whole text area but the same problem will probably come back in another error later on. Any ideas what can be the problem with my implementation? 

I'am using a custom board with an STM32F7.

[HP]

Just a couple of ideas:

1. what happens if you try out a single buffer? Does the issue go away?
2. have you verified the size of your buffers? I made a mistake once where I just copied the buffer starting addresses from the template, but missed that I was running 24-bit and the template was 18-bit. animations came out really weird at specific points during transitions

[LRose.3]

Thanks for the input.

I have been looking at the frame buffers quite a lot and I believe they are the correct size. With the same buffer size I have not been able to reproduce the error when I run touchGfx4.13.

When I change to Single buffer the M and m are still there but they are not flickering. I have by mistake invalidated the text area every frame hence the buffer is changed every frame and hence the flickering. Note the problem is still there but expessed in another way. To pinpoint the problem I created a simple application using double buffer and one application with single buffer. Where a textArea is moved and text is updated every 100 tick. The behaviour is not same in with single and double buffer. Is this expected??? See the result in the attached videos.

void Screen1View::handleTickEvent()
{
	
	if((tick % 100) == 99)
	{
		static int count = 0;
		static int16_t y = 0;
		
		// print counter
		count++;
		Unicode::snprintf(textArea1Buffer, TEXTAREA1_SIZE, "%d", count);
		
		// move text 30 rows. If close to the buttom of the screen start from top again.
		y = (y + 30) > 299 ? 0 : y + 30;  
		textArea1.setY(y);
		
		textArea1.invalidate();
		
	}	
	tick++;
}

[Alexandre RENOUX]

Hello LRose.3,

Could you enclose a project illustrating this issue ?

I would like to try on a ST board with the same screen size to see if the problem occurs.

Btw, what's your display resolution ? display interface ? Color depth ?

/Alexandre

[LRose.3]

Hello Alexandre

Appreciate your help!

Settings 320x240 LTDC RGB565.

Attached is a simple project. Changing from single to double buffer in the CubeMx project will generate the behaviour shown in earlier attached videos.

[Alexandre RENOUX · Accepted solution]

Hello LRose.3,

The issue comes from your test code. When moving a widget, you need to invalidate both before and after moving the widget.

In your case you only invalidate at the end, therefore you invalidate only the widget at the new position. But you also need to invalidate the previous location of the widget so that it disappears correctly at the start location.

If you modify your function as below, this should work just fine with double framebuffer

oid Screen1View::handleTickEvent()
{
	
	if((tick % 100) == 99)
	{
		static int count = 0;
		static int16_t y = 0;
		textArea1.invalidate(); // TO ADD
		// print counter
		count++;
		Unicode::snprintf(textArea1Buffer, TEXTAREA1_SIZE, "%d", count);
		
		// move text 30 rows. If close to the buttom of the screen start from top again.
		y = (y + 30) > 299 ? 0 : y + 30;  
		textArea1.setY(y);
		
		textArea1.invalidate();
		
	}	
	tick++;
}

Please let me know

/Alexandre

[LRose.3]

Thanks Alexandre!

I have tried it in the simple application and in my real application and it seems to solve the problem. I’m still a bit confused. Have this behaviour changed from touchGfx 4.13 to 4.17? Because I didn’t experience flickering M and m (which I described in the initial post) in my real application when I used 4.13.

[Alexandre RENOUX]

Hello LRose.3,

No this behavior is not supposed to change. It's the same graphics theory in 4.13 and 4.17.

There must have been something else in your 4.13 project that prevented the real behavior to occur.

Good to know it's working now.

If your question is answered, please close this topic by choosing Select as Best.

/Alexandre