How to avoid rendering the screen with defaultBgColor?

[wctltya]

Hi Joel and inmarket,

My application manages many pages which do not have dynamic contents only, but their layouts depends on the server's data as well. Even some of the pages doesn't fit the screen, therefore they are divided in many sub-pages. As I already mentioned in a few other posts there is no OS, the system has enough uC speed, flash and ram, but anyway the resource are not unlimited. The display is 320x480,  display controller's  integrated buffer and 16bit Parallel Port Interface is used. So an approach like:  

"1. Create all pages

2. Show First (let say Home) page

3. Show next page/Hide previous page (on demand or event)"

is not suitable. 

Therefore I'm using this:

"1. Create/Show Page_1

2. On Event - Destroy Page_1

3. Create/Show next (required) Page_2

etc..."

Because the speed of PPI is limited to about 30MHz pages changing is visible. But I noticed that a full rendering with defaultBgColor happens at destroying the "old" page. That is logical, I though, if there is no other page, So I changed the sequence to:

"2. On Event - Create Page_2

3. Destroy Page_1"

But that makes the presentation even worst, because:

At point 2 the desired Page_2 is rendered, then at point 3 - the screen is wiped (rendered with defaultBgColor), and then Page_2 is re-rendered again

From my point of view  the screen wiping is done for nothing and makes the presentation bad on displays with slow interfaces.

I've done some debug and found that screen wiping is done at line 803 gwin_wm.c in WM_Redraw(GHandle gh) with: 

// Clear the area to the background color
gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gwinGetDefaultBgColor());

at GWIN_FLG_BGREDRAW set. This flag is set internally in the same function and in two more _gwinRippleVisability() and gwinRedrawDisplay() at certain conditions.

 

So, could you advice me, please - How to avoid the screen wiping?

[inmarket]

The reason is that making something not visible must always be processed before making new things visible. Also the current window manager does not handle overlapping windows except as a parent child relationship.

So in scenerio 1 when page 1 becomes invisible the screen is background filled. Creating page 2 then draws page 2.

In scenerio 2 the pages are both visible, and both overlap but are not in a parent child relationship. This breaks the current display rules for the standard window manager. When page 1 is made not visible it is set to the background color and then anything visible in the original area is asked to redraw thereby redrawing page 2.

This limitation is to keep code small and prevent unbounded memory use (as would be required for a full overlapping window window manager).

Think of the situation where page 2 is smaller than page 1. In this situation without full region clipping support the way we do the redrawing is the only way to guarantee a valid screen.

As your pages are 100% equivalent in size you may be able to fool the window manager into not clearing the area of page 1 and therefore preventing the issue you are seeing. To do that you need to fool the window manager that page 1 is no longer visible even though it is.

The easiest way to do this would be to manually clear the visible  and sysvisible flags in the window structure before destroying the page. That may be sufficient although technically it leaves invalid flags on the page 1 children. If that method is not sufficient you may need to also cycle through page 1 children and clear the sysvisible flag (but not the visible flag) before destroying the object.

[wctltya]

Hi inmarket,

Sorry for late replay,but  I wanted to test it carefully.

It works, i.e. manually clearing both flags prevents wiping.

Thank you for the advice.

[ronan_rt]

 

The easiest way to do this would be to manually clear the visible  and sysvisible flags in the window structure before destroying the page. That may be sufficient although technically it leaves invalid flags on the page 1 children. If that method is not sufficient you may need to also cycle through page 1 children and clear the sysvisible flag (but not the visible flag) before destroying the object.

Hello @inmarket! Im having such problem. How I do this? Im working with several screens and the change of then is too slow because im using SPI of a Stm32f103.

[inmarket]

The solution posted above is not a general way of increasing redrawing speed. The solution above was specific to that situation, the whole screen was being replaced by destroying one full screen container and replacing it with another full screen container.

If that is your situation as well then the above solution will work for you. If not then there is unlikely to be much that can be done to increase the speed of your slow redraw.

Check your spi speed. That is the area most likely to yield benefits in redrawing speed.

[Joel Bodenmann]

Other than that, you might want to consider using a display controller that too offers an SPI interface but that offers hardware acceleration along that. Even if it can just draw rectangles you'll get a HUGE performance improvement. Have a look at the RA8875 as an example.

[viji s]

Hi, 

I have the same problem.Could you please, give me more detailed information regarding this as soon as possible.

 

Thanks and Regards

 

[Joel Bodenmann]

Hi,

What information would you like to get? There were a few different things mentioned in this topic.
Please don't hesitate to ask specific questions.