Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
vroland opened this issue Feb 7, 2024 · 6 comments
Open

Comments

@vroland
Copy link
Owner

vroland commented Feb 7, 2024

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
Copy link

schuhumi commented Feb 9, 2024

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
Copy link
Collaborator

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
Copy link
Owner Author

vroland commented Feb 12, 2024

@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
Copy link
Owner Author

vroland commented Feb 12, 2024

@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
Copy link

@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
Copy link
Collaborator

martinberlin commented Feb 14, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants