Offload window management and Windows GDI operation to a separate thread in win32drv.

[MouriNaruto]

In #212, I said that I will try to create a new PR to offload them to a separate thread because Windows GDI operation uses 80% of the main thread CPU time when I use the profiler. Here is the code.

Before

After

Kenji Mouri

[MouriNaruto]

@kisvegabor ping for progress

Kenji Mouri

[kisvegabor]

Wow, it's unbelievable. Again 🙂

I started to work on the new driver architecture which will be part of the main repo. It consists of drvs (low level) and devs (high level). In case of SDL, SDL is a driver and frame buffer is an abstract device which uses the SDL driver.

It can be used like this:

  lv_drv_sdl_window_t * drv_win = lv_mem_alloc(sizeof(lv_drv_sdl_window_t));
  lv_drv_sdl_window_init(drv_win);
  drv_win->hor_res = w;
  drv_win->ver_res = h;
  lv_disp_drv_t * disp_drv = lv_drv_sdl_window_create(drv_win);

  lv_dev_fb_t * dev_fb = lv_mem_alloc(sizeof(lv_dev_fb_t));
  lv_dev_fb_init(dev_fb);
  dev_fb->hor_res = w;
  dev_fb->ver_res = h;
  lv_disp_t * disp = lv_dev_fb_create(dev_fb, disp_drv);

As I imagine Linux /dev/fb, your Windows driver, STM32's frame buffer, etc will be drvs hidden behind a a frame buffer dev.
Do you think the Windows driver can with into this scheme?

[MouriNaruto]

@kisvegabor

Do you think the Windows driver can with into this scheme?

I am reading the source code you committed in the arch/drivers branch.

It looks like I can try to integrate the Windows driver to this scheme, but I need to try first and validate my guess.

Kenji Mouri

[kisvegabor]

If it looks good at first look, it's already something. 🙂
I'm still also validating the architecture by adding some very different drivers.

I'll let you know when it's stabilized.

[MouriNaruto]

@kisvegabor

I think may be lv_drv_reset_dev, lv_drv_send_cmd, lv_drv_read_data and lv_drv_send_image can merge into one multi-functional API and related callback to unify the API. For example:

lv_res_t lv_drv_control(lv_drv_t * drv, uint8_t cmd, const void * input_buffer, uint32_t input_buffer_length, void * ourput_buffer, uint32_t* output_buffer_length);

Kenji Mouri

[kisvegabor]

For this callbacks I was considering an SPI based display controller (e.g. ILI9341) and an I2C touchpad controller. For these purpose of these functions is quite different:

• reset: set/clear GPIO
• send: send a cmd specified by the controller IC via SPI or I2C
• read: read some data via SPI or I2C
• send_img: the core of the flush_cb

Anyway, I keep this option in mind.