I found out that the v7 will be a little faster than v8 in my full screen double frame buffer configuration with 1024*600 resolution . The refresh rate will slow down when the total widget increasing both in v7 and v8 ,but v8 is more serious.
Attached are the result of benchmarks demo without other widget or APP running . The rectangle score is 31 in v7 and 30 in v8. As a comparison , in my photo in the above post, the benchmarks demo is running under a button event cb of the tabview and the score slow down to 15 for v7 and 12 for v8, nearly half of the original . The only different is the background widget tree adding , but it were covered by the benchmark container and will never being actually drawn .
Which might be the reason for the slow down and how to work around?
Hi, @kisvegabor and @pete-pjb，
I found a mistake in my benchmark testing in v7 that I forgot to set the background to COVER style. The background widget were drawn which slowing down the refresh rate. When setting as below, the rectangle score rise to 29 , very closed to the 31 of single APP conditions.
lv_obj_set_style_local_bg_color(scene_bg, LV_OBJ_PART_MAIN, LV_STATE_DEFAULT, lv_color_hex(0xffffff));
lv_obj_set_style_local_bg_opa(scene_bg, LV_OBJ_PART_MAIN, LV_STATE_DEFAULT, LV_OPA_COVER);
In v8 , I had already set the scene_bg in the last test and the rectangle score drop from 30 to 12 when in the multi-APP conditions. I will verify again.
Further more ,I found a very strange behavier in v8 that the DMA2D copy subrutine will mulfunction in the cb of disp_flush. If setting as below, the display is normal:
for(a = 0; a < disp->inv_p; a++) {
if(disp->inv_area_joined[a]) continue;
lv_coord_t w = lv_area_get_width(&disp->inv_areas[a]);
for(y = disp->inv_areas[a].y1; y <= disp->inv_areas[a].y2 && y < disp_drv->ver_res; y++) {
memcpy(buf_cpy+(y * hres + disp->inv_areas[a].x1), colour_p+(y * hres + disp->inv_areas[a].x1), w * sizeof(lv_color_t));
}
}
If changed to the DMA2D copy as below , the display will crash when in the animation of the the drawing as the attached photo. My own DMA2D copy is also like that.
int32_t act_x1 = disp->inv_areas[a].x1;
int32_t act_y1 = disp->inv_areas[a].y1;
int32_t act_y2 = disp->inv_areas[a].y2>disp_drv->ver_res?disp_drv->ver_res:disp->inv_areas[a].y2;
lv_coord_t h=act_y2-act_y1+1;
lv_draw_stm32_dma2d_buffer_copy(NULL,
buf_cpy, hres, &disp->inv_areas[a],
colour_p, hres, &disp->inv_areas[a]);
I am running on double frame buffer in the direct mode with manually copy the invalid area. The DMA2D copy function is correct in my v7 version .
Is there any reason for that issue of my v8 porting? That might be the same reason of the slow down in the multi-APP benchmark testing?
Hi, @kisvegabor and @pete-pjb，
To verifying the slow down in multi-APP condition of v8 , I merged the lv_demo_widgets() with the lv_demo_benchmark() by setting the lv_demo_benchmark as the event cb of the log_out_btn as below
lv_obj_add_event_cb(log_out_btn, benchmark_event_cb, LV_EVENT_ALL, 0);
So when press the log_out_btn in the lv_demo_widgets demo, the benchmark demo is running now. As the background of the benchmark had been set to COVER and white, there should be no other widget drawing , but the rectangle score also drop to 12 comparing to the 30 in the single demo test, very similar with the score in my own tabview based multi-APP condition.
Hi, @kisvegabor and @pete-pjb，
I have double confirmed that the score of rectangle will drop for 32 to 14 when switch from benchmark demo to widget+benchmark demo. There have not such issue in the v7 in the same test. Note that I have set the scene_bg of benchmark to cover and white, so nothing had been drawn in the background of the test.And I had bypass all the meter animation cb of the widget demo for not to interrupt the generate_report function of benchmark tes. Further note that I am running on double frame buffer in the direct mode with manually copy the invalid area by memcpy().
Fully. LVGL tries to find a widget which fully covers the area to readraw and start rendering it, all its children all its younger siblings (as they can be on top of that widget) .
Hi, @kisvegabor,
Many Thanks!
I have tired the new code but result almost the same. The rectangle score is still 14 vs 32 in single APP mode. Attached FYI.
Hi, @kisvegabor,
Many Thanks!
I have some problem on uploading the lvgl file and will try later. I just download the v8.2 last month and made no change on the lvgl file. I will try the latest one.
I just updated the newest master version 8.3 dev of lvgl lib and test again. The rectangle score is 16 in multi-APP condition vs 32 in single-APP condition. I also tried not to set the scene_bg cover and white, to let the background widget being drawn ,the score is also 16, same with the covered one. I doubt the background is always drawn regardless it is covered or not by the top widget container.
I also tried modifying the code on line 744-746 in lv_refr.c as your guide, the score is 15 , a little slower than the original one.
Would like to have your further advice.
Hi, @kisvegabor,
I found out that there have some part of the background tabview of the widget demo in the top area were not covered by the front benchmark demo scene_bg, please refer to the left and right cornor area in the attached photo. Is this the reason of full redrawn of the tabview widget and all its children, regardless if the children were covered by the top widget or not ?
It is not a good idea to redraw the children fully covered by the top widget, right? It seems the v7 have a different rule on the condition.
It can not cover the background widget demo, so the score drop to 15. And it is so easy to run to the hardfault status. Something is wrong when too much widget tree need refreshing with animation?
I am running the updated v8.3 dev version. Would you please help to check , if an object is partly covered by the top object, will all his child object be redrawn ,regardless of the child being fully covered or not by the top object in the V8.3 lib? I found that V7 will not redraw the child being covered but V8 will.
If a widget is covered by the top object, then that widget won’t be drawn. In other words if the top object covers something it means the top object over the other. And LVGL starts to draw from the top object so the object behind it will be untouched.
Don’t forget the bug I mentioned here, which affects whic object is found as top object.
Hi, @kisvegabor,
Many Thanks !
I doubt the background widget of the widget demo been fully redrawn when there just left a upper cornor area not being covered by the benchmark demo bg , as the frame rate droped from 32 to 16.
If not ,there should be a little drop of the frame rate comparing to the fully covered one.
Please refer to the last photo I post.
Would you please help to verify it.
Is there a serious performance drop in v8 (compared to v7) when running only the benchmark?
Is there a serious performance drop if you make the benchmark fully cover the widgets demo? (As described [here](https://Is there a serious performance drop in v8 (compared to v7) when running only the benchmark?))
