Cutting Legacy Features for Maintainability - Do you use any of them?

[vroland]

Hi everyone,

I noticed that between supporting multiple boards, displays and chip revisions the codebase has gotten quite complex. This limits the pace at which myself and especially others can develop for epdiy. Hence, I plan to remove some legacy features to allow refactoring into a simpler, more testable architecture. This will mean breaking changes, though I'll try to keep breakage for the preserved features minimal.

TLDR: Please scream below if you're using any of the features below:

• 1 bit-per-pixel framebuffers
• 4 bit-per-pixel framebuffers (using the lower level functions directly, not through the highlevel API)
• framebuffers that are smaller than the full display
• telling the driver that the display was already white / black though PREVIOUSLY_WHITE / PREVIOUSLY_BLACK
• giving a cropping area to only draw part of the provided framebuffer

Especially with V7 and the vector instruction optimizations, there is little need for these very low-level optimizations, while they introduce a lot of complexity.

Thanks for giving feedback!

[schuhumi]

Hi,

I use 4 bit-per-pixel framebuffers and no high-level-api at all. All my drawing happens using epd_draw_base() with MODE_PACKING_1PPB_DIFFERENCE.

Also I tried to use cropping area, but failed to do so (probably a mistake on my side). Instead I use the drawn_lines parameter extensively, as it makes drawing small changes a lot faster. So from my side you can remove the cropping area if drawn_lines stays.

\</scream> Thank you for working towards a simpler codebase, that is very helpful!

[martinberlin]

I use 4 bit-per-pixel framebuffers and mostly the high level API except in LVGL driver since it writes directly to the framebuffer. I think @ashald used 1 bpp framebuffer but I’m not sure he should confirm since I only helped a bit adding Adafruit GFX https://github.com/martinberlin/platformio-epdiy-monochrome-GFX

framebuffers that are smaller than the full display & telling the driver that the display was already white / black though PREVIOUSLY_WHITE / PREVIOUSLY_BLACK

about those 2 I never used them at all. Also if I remember well never used that cropping area feature, only epd update giving a certain area to make a smaller rectangular update

[vroland]

@schuhumi Ok, so from the perspective of drawing you're still only using the 1ppB difference mode? I think the front / back draw buffers will still be 4bpp, but for rendering I may switch to 1ppB difference buffers only. Also having a line as well as column mask (as added in the vector instructions branch) should supersede the crop.

[vroland]

@martinberlin I could add the capability of supplying pre-calculated output frames instead of monochrome framebuffers, that should allow the same functionality at lower complexity on the driver side. Since it's a niche use case, I think it's ok to push that complexity to the consumer.

[schuhumi]

@vroland I only use the difference mode where it is 1 byte per pixel: 4 bit for the "from" color, and 4 bit for the "to" color:

  /// A difference image with one pixel per byte.
  /// The upper nibble marks the "from" color,
  /// the lower nibble the "to" color.
  MODE_PACKING_1PPB_DIFFERENCE = 0x100,

I do not use any other mode, and I also do not use any front / back buffers. Instead I write the "to" colors into the difference buffer myself, and also update the "from" colors after epd_draw_base() myself.

Yes I saw the column mask in the branch, I'm excited for that and the speedup! :)

[martinberlin]

I started to test the new vector experimentation branch looking forward to get that working as soon as possible