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

The WaveshareDisplay associated color is not properly documented #122

Open
peckpeck opened this issue Nov 1, 2022 · 4 comments
Open

The WaveshareDisplay associated color is not properly documented #122

peckpeck opened this issue Nov 1, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@peckpeck
Copy link
Contributor

peckpeck commented Nov 1, 2022

Since it is an associated type, most driver implement it as the color type the epd supports.

However since there is a separate WaveshareThreeColorDisplay trait, some driver implement it only as a black and white color and let the 3 colors handling to WaveshareThreeColorDisplay (eg epd1in54c).

We should document and enforce the right behaviour to make sure this is coherent between various implementations.

@caemor caemor added the enhancement New feature or request label Nov 4, 2022
@caemor
Copy link
Owner

caemor commented Nov 4, 2022

Sounds like a good idea 👍

@peckpeck
Copy link
Contributor Author

peckpeck commented Nov 7, 2022

I se no other reason than rendering speed to provide a specific trait fir 3 color versions, so I wrote this.
Are you ok with this definition ?

DisplayColor should be the exact color type supported by the device. 

If you want to be able to let the user update only chromatic or bw buffer separately
in color mode sometimes, maybe to gain some refresh time, please implement
`WaveshareTheeColorDisplay`.

If you want to support a black and white only mode on a color EPD, because it may make the refresh 
faster, please implement `WaveshareDisplay` with the bicolor `Color` type on a bicolor 
version of your structure.

If it not any faster, the user can always use a TriColor `WaveshareDisplay` as a Bicolor 
one.

It implies that most (b) versions, ie tricolor, of existing display will work differently than they do currently, but they will be closer to what bw versions and octocolor versions provide. And it also means the definition will match their Display structure counterpart.

@peckpeck
Copy link
Contributor Author

Any news on this ?

@caemor
Copy link
Owner

caemor commented Nov 28, 2022

DisplayColor should be the exact color type supported by the device.

Please implement WaveshareThreeColorDisplay, if you want to allow that in color mode the user can sometimes only update chromatic or B/W buffers separately to maybe gain some refresh time.

Please implement WaveshareDisplay with the bicolor type Color on a bicolor version of your structure, if you want to support a pure black and white mode on a color EPD, as this can speed up the refresh.

If there is no faster way, the user can still use a TriColor WaveshareDisplay as Bicolor one.

Some small changes but the meaning hopefully should have stayed the same.

This also sounds like a good change to make the usage and development of this crate more intuitive.

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

No branches or pull requests

2 participants