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

Frame Change Flicker #83

Closed
kevincloutier opened this issue Jun 2, 2021 · 10 comments
Closed

Frame Change Flicker #83

kevincloutier opened this issue Jun 2, 2021 · 10 comments
Labels
question Ask for help setting up or running a VSMP

Comments

@kevincloutier
Copy link

kevincloutier commented Jun 2, 2021

Hi, first, fantastic project. I purchased the displays a few months ago and finally had the time to configure etc. I'm not familiar with the inner workings of EPD so please forgive me if these are dumb questions.

In between frames the display flickers multiple times, I am assuming this is to clear the image that is present in order to make a "clean slate" to draw the next image:

  1. Is this a good assumption?
  2. Is this clearing required? For example, can one just paint the pixels that have changed rather than clearing the entire screen?
  3. Assuming this clearing / flickering is required, can it be reduced in time or somehow otherwise mitigated? For example, is the epd.prepare() call the function causing the "clear action"? If so, would it help to move the generate_frame call before the epd.prepare() call (or something similar) to reduce the time the screen is blank (e.g., put the frame in memory before clearing)?

These are just general questions, all of which I can answer myself with a few hours of debugging, I just thought I would ask in case someone had the info at the ready and failing that, I will post back what I learn from a bit of exploring in case someone else has a similar question.

Thanks,

Kevin

@kevincloutier kevincloutier added the question Ask for help setting up or running a VSMP label Jun 2, 2021
@missionfloyd
Copy link
Collaborator

missionfloyd commented Jun 2, 2021

That's out of our control. Maybe it could be changed in the driver (I think some do support partial refresh), but that would be something to ask the manufacturer.

https://github.com/waveshare/e-Paper
https://github.com/pimoroni/inky

@kevincloutier
Copy link
Author

Cool, i'll take a look around and see what I find. I was looking at the driver code earlier, if I find anything worthwhile I'll surely let you know. Thanks again for a great project,

@kweiwen
Copy link

kweiwen commented Jun 20, 2021

@kevincloutier i'm facing same problem now, have you find out the solution? hw: rpi 4b, waveshare 7.5inch v2.

@robweber
Copy link
Collaborator

I don't think there is much to be found in the way of a fix, or time reduction. It's a property of how an e-ink display physically works compared to something like an LED or LCD screen. Most manufacturers state the avg refresh time right on the product page. Partial refesh, when supported, does save time but is worse for the display over time.

@kweiwen
Copy link

kweiwen commented Jun 21, 2021

I don't think there is much to be found in the way of a fix, or time reduction. It's a property of how an e-ink display physically works compared to something like an LED or LCD screen. Most manufacturers state the avg refresh time right on the product page. Partial refesh, when supported, does save time but is worse for the display over time.

hi rob, thanks for replying. now i'm wondering am i the one faces this issue? i've checkec Bryan Boyer's vsmp video seems works fine to me.

beside slowmovie.py, i also tested my vsmp with scripts in Extra directory, such as houseofdust.py, testframe.py... there's still flickering issue.

should i replace my rpi to 3b+ or other version?

@kweiwen
Copy link

kweiwen commented Jun 21, 2021

i did more investigation on this issue.

follow the information from the vendor side(waveshare), they claimed the problem came from spi host, not e-paper device.

i've tried to degrade the kernel version to 4.19 follow this discussion, there's no luck and flickering still exists. temporary i don't have a scope to verify the spi speed is better or not.

@TomWhitwell
Copy link
Owner

@kweiwen There was an issue/change that sped up writing, I haven't noticed that it's reverted so not sure what's going on

waveshareteam/e-Paper#104

There is always flicker / page changing / but it doesn't do it multiple times for me

@TomWhitwell TomWhitwell reopened this Jun 21, 2021
@kweiwen
Copy link

kweiwen commented Jun 21, 2021

@TomWhitwell mine always flicker while the page is changing, does it happened to you? could you provide the stable released so i could try and compare both to find out the root cause?

also i noticed CPU rate will exceed 100% while the frame is changing, not sure which line slower the processor down, i will try to investigate those two:

  1. generate_frame(currentVideo, "/dev/shm/frame.bmp", msTimecode) → image processing ability related
  2. epd.display(pil_im) → spi speed related

@robweber
Copy link
Collaborator

To help frame the conversation I think a definition of "flicker" would probably be helpful to all. When updating the screen you'll notice a change from the image it's currently on to all white then all black then white then the new image will be displayed. In total that's 3 "blank" screens then a new image. The exact duration of this varies by screen model. On my 7.5in Waveshare this is somewhere between 2-3s. On the Waveshare site they say it will take 5 seconds. If you're seeing more than this type of "flicker" then you may be having an problem. I think it's also important not to conflate the "flicker" effect with the time aspect. The screen will "flicker" but there very well could be optimizations (at the e-ink driver level) that reduce the amount of time this takes to happen. Regardless of how fast it happens you'll get the white-black-white effect.

I found this to be a pretty detailed explanation of the why behind this.

A pixel is comprised of tiny balls full of black ink suspended in white fluid, and how black the pixel looks depends on what percentage of the balls are near the top of the fluid. For a black pixel they're ideally all at the top and for a white pixel at the bottom. If only some of them are at the top, or many of them are floating halfway down, etc., the pixel may appear to be some shade of grey. You might think of the floating balls as subpixels.

The balls get to the top or bottom by having an appropriate charge applied to each cell. However, each cell might be influenced by its neighbors as well as the applied charge. To the extent the balls are attracted to charge on a neighboring cell (horizontally) rather than its own cell (vertically) they won't wind up in the intended place. If a cell is changing from black to white and all its neighbors are also, it will transition more completely than if some neighbors are staying black or are going the other direction. This is where ghosting comes from.

The solution is to drive the entire screen white-black-white (or similar) so that no cell has a problem from neighboring cells, and then apply the desired screen image. Every screen write starts with a screen that has been wiped clean so there is no afterimage of the previous screen.

@TomWhitwell
Copy link
Owner

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Ask for help setting up or running a VSMP
Projects
None yet
Development

No branches or pull requests

5 participants