Useless whole screen refresh

In the most simple case, we need to compare all properties of state A with B. If there is no change no need to redraw. It should be done on every virtual part of the object too. (e.g. slider knob also goes to pressed state).
It’s about 100 queries per state per part. E.g. 100 x 2 states x 2 parts = 400 queries.
However, some optimization can be applied:

  • break on the first difference: if there is a change in the styles probably we will quickly find it if the most relevant properties are checked first.
  • exclude not visible properties: e.g. if border_widht is zero, border_color is irrelevant.

So we can add a well-optimized function to tests the difference between 2 states. If it says there is no difference between the 2 states just set the state and return without refresh.

What do you think?

Provided that we can get that function to run faster than a refresh does, I see no problem with this. An alternative option is to add a flag that requires users to manually refresh the styles on a state change.

Sounds great, but as you said, I’m afraid it would decrease the overall performance, especially in small objects or in objects with more than one part. Maybe we should test and see how it is.

It’s good idea. If the @kisvegabor idea didn’t work well I think it’s a good alternative.

As another idea, what about this:
What If we save the need to refresh in bitfields for every state.
Forexample, Consider a byte for a pressed state that each bits shows if it needs a refresh when changed to another states. And these flags are set whenever the style of the object is getting set.
I think, it’s more complicated than the @kisvegabor 's method, but seems faster to me.

I think it shouldn’t be that slow because most of the style properties need to be get for drawing too. And after getting properties there is the drawing which takes most of the time.

I’ve just realized that we can cover most of the properties by using lv_obj_init_draw_rect_dsc (and similars for label, image and line) and compare only the draw descriptors. These functions are already well optimized.

1 Like

OK, if say so.
Let’s see how it is.

I’ll add it this week.

Thank you very much Gabor. :pray:

Hi,

I pushed it to the dev branch, but can’t test it on embedded hardware yet. It workes well in the simulator.

Can you try it out?

1 Like

Hi
Thanks, yes of course.
I will try it out ASAP, and let you know the result.

Yeah, It seems great. thanks, again🌺

At first, I saw no difference, after looking to the lv_obj_set_state I found you implement it for LV_USE_ANIMATION == 1.
Will you implement it for the other state too?

Yes - perfect. But it works for only enabled use animation.In my project I don’t use animation because I have slow display communication. So I need it also for LV_USE_ANIMATION == 0.

Good point, I updated the dev branch to make it work without animations too.

1 Like

Thank you very much @kisvegabor
It works well.
Although the horrible refresh is solved now, there is another thing that bothers me.
When I scroll the menu fast, I can see a lag in updating the chart, which was not in ver 6. Until now I thought that it might be related to this problem but as this lag is still there seems that it’s not. what do you think about it?
Here is the ver 6, with acceptable lag in updating the chart:

And here is the ver 7 one, you can see the updating lag in chart:

PS: I checked it with both states of LV_USE_ANIMATION and I saw no difference. Not sure but even felt that disabling the animation makes it worse.

Interestingly the menu scrolling actually looks smoother in v7. Maybe it’s the same and there’s just less tearing.

1 Like

Good point👍
It seems that in ver 7, It sticks in the task of refreshing an object and then go for another object. Am i right @kisvegabor?

That logic hasn’t changed in v7. LVGL just redraws every dirty area. However, it seems in v6 the chart is still running in the background while you scroll, but in v7 it stops. So v7 might be slower here.

Anyway, how you implemented this chart? Maybe there is something to optimize there.
If you are interested in discussing it please open a new topic in the “How to” category.

Sure, thanks.

I discovered that after commit 8188440 from 8.9.2020 the lv_checkbox_set_checked(…) do not update checkbox gui element correctly.

@cmarty I think it’s fixed now, would please check it again with the latest update of the master branch.

Checked and it works OK now! Thanks.

1 Like