How to change the height of the mbox

JamesJJ · June 21, 2019, 9:16am

Hi, kisvegabor，
How to change the height of the mbox ？ I want to change not only the width but also the height of the mbox.

Best Regards,

embeddedt · June 21, 2019, 1:05pm

As far as I can tell, nothing should prevent you from using lv_obj_set_height. Does that work?

kisvegabor · June 21, 2019, 9:57pm

Auto fit should be disabled first becaue the height is set automatically: lv_cont_set_fit(mbox, false, false).

The message box has a LV_LAYOUT_COL_M layout too which automatically aligns the text and buttons in a column. So setting the height will result in an extra space at the bottom.

Instead, I suggest adjusting the padding of the background style.

JamesJJ · June 22, 2019, 6:26am

Hi, kisvegabor and embeddedt，
Many Thanks！
I got your idea.It works!
Futher more about the mbox, I create the mbox on the layer top and the backgroud is the live updating waveform created by the lv_chart with my customized design function. When popping up the mbox, everything is ok and the backgroud is 50% opa. When closing the mbox by pressing the btn, the backgroud waveform will have chance to refresh to the 100% opa and is just like jumping to the layer top. I doubt my chart design function ,but the core is so simple as below:
LTDC_Fill_H(vdb_buf_tmp,vdb_width ,x_act,y_tmp,1,h-y_tmp,ser->color);
The LTDC_Fill_H () is just a lower TFT driver to fill the rectangle area of the screen using the LTDC hardware TFT diver in STM32F429, instead of the lv_draw_rect() for the fast speed .

What would be the reason of the improper refreshing of the background layer?

EDIT: Further test show that , it is really causing by my LTDC_Fill_H (). Could you advise me the different of the two rectangle drawing function? I am sure the LTDC_Fill_H () perform well without lv lib and it is also called by disp->driver.mem_fill().
How I can properly use my low level TFT driver safty in case of need?

Best Regards,

embeddedt · June 22, 2019, 1:41pm

How I can properly use my low level TFT driver safty in case of need?

You shouldn’t. Skipping the higher level drawing APIs is likely to result in behavior like what you’re seeing.

JamesJJ · June 22, 2019, 3:39pm

Hi, embeddedt，
Many Thanks！
Yes I see. But the drawing speed need optimize and the high level APIs might be too difficult to make change. That is just in some critical case and I am not planning to replace the low level driver.
It is interesting to learn why their behave different. Would you please give me more advice?

Best Regards,

embeddedt · June 22, 2019, 3:43pm

You can’t expect LittlevGL to work properly if you bypass the logic deciding how layers are drawn. It’s like expecting a car to move after taking out the engine (excuse the humor ) .

I think that you need to find a way of making the high-level APIs work instead of trying to bypass them.

JamesJJ · June 22, 2019, 4:00pm

Hi, embeddedt，
Many Thanks for so soon reply！
Yes the issue were on the two layer refreshing. I have checked the major of the rectangle drawing in the lv_draw_rect_main_mid() , and could not understand where the layer order deciding taken place. I just want to find out that and work around it. Is it possible?

Best Regards,

embeddedt · June 23, 2019, 1:02am

I really don’t recommend bypassing LittlevGL for this. It’s better to optimize LittlevGL rather than working around it.

JamesJJ · June 23, 2019, 10:16am

Hi, embeddedt，
Many Thanks！
I am not going to bypass the lv lib driver. Just to customize the object design function. As there have lots of thing should be concerned , the current lib driver might be complex . So I just try some simple low level driver for testing. The idea works so far except in the two layer condition. Which flag control the layer of the object to be drawing and why there have chance to draw to the top layer for a object on the act layer. I just want to find out the reason, or for better understanding the magic lv lib.

Best Regards,

embeddedt · June 23, 2019, 4:45pm

I am not going to bypass the lv lib driver. Just to customize the object design function. As there have lots of thing should be concerned , the current lib driver might be complex . So I just try some simple low level driver for testing.

Those are conflicting statements. I don’t see how you can use a low level driver in the design function while not bypassing LittlevGL. Can you please clarify?

JamesJJ · June 24, 2019, 2:15am

Hi, embeddedt，
Sorry for make misunderstanding.
Yes I have replaced the lv_draw_rect() with my LTDC_Fill_H() in the lv_chart_draw_cols() . I just want to find out the different of the performance and I am still keeping the framework of the design function in the chart object. Per my understanding , when refreshing with top and act layer , the object on the act layer will be drawn to the framebuffer first and then covered or mixed by the object on the top layer. If so , which low level driver will make no difference to the drawing. But it is not the case. The chart on the act layer will have chance to be drawn to the top layer when pressing the button on mbox. I am trying to learn the reason. That might be just for better understanding how the lv lib handle the mutilayer refreshing.

Best Regards,

kisvegabor · June 24, 2019, 5:29am

@JamesJJ

I seems you are using STM. Do you have more layers in LTDC? I so can use on layer with LittlevGL and other for the chart where you can draw as you want.

However, in this case you can not insert the “HW layer” between two LittlvGL layers. Like:

LittlevGL background
STM chart
LittlevGL top layer with message box

At least not in v5.3. v6.0 supports multiple displays. If you have 3 layers in STM you can:

Layer0: as a display for LittlevGL
Layer1: custom drawing
Layer2: as an other display for LittlevGL when you create a message box.

LTDC will merge these layers into one considering the alpha channels.

JamesJJ · June 24, 2019, 6:21am

Hi, kisvegabor,
Many thanks!
I do not insert chart layer but put it on the backgroud layer. I have only tried low level display driver like drawing rectangle instead of the lv_draw_rect() . You means the layer order decision and controlling were in the lv_draw_rect() ? If so , it is really not so easy to try the new driver.
Yes I am using STM, but I am not planning to use hardware multilayer as for the complex management and resource cost.

Best Regards,

embeddedt · June 24, 2019, 1:21pm

You means the layer order decision and controlling were in the lv_draw_rect() ? If so , it is really not so easy to try the new driver.

Yes, all of this is handled inside lv_draw_rect. Which is why it is much easier to optimize that than to be trying to bypass it.

JamesJJ · June 24, 2019, 5:27pm

Hi, embeddedt，
Many thanks!
I will try to opimize them.

Best Regards,