What's the optimal settings for 6"HD? about papertty HOT 7 CLOSED

The Pi Zero is pretty slow compared to the full raspberry pis. It'll be having a hard time running a panel of that resolution.
You could experiment with the font and font size settings, but it probably won't help much unless you go with a very small/thin font.

One thing you could try is turning on A2 mode.
If you edit the driver_it8951.py file there's a block of code which mentions the 6inch panel.
It currently has A2 mode turned off, because the 6" panel is a bit different than the others, and I don't own one to test with.
All you'd need to do is uncomment this line:
#self.supports_a2 = True
then restart papertty.
If it works, you'll be using A2 mode instead of DU mode, which is a little faster.

You could also try using this branch that I'm working on: https://github.com/mcarr823/PaperTTY/tree/single-line-refresh
It's a work-in-progress and doesn't work on all orientations.
However, it should provide a significant speed boost for a pi zero and the 6" HD panel.
It has some optimizations specifically for the IT8951 driver.
It also tackles some of the big performance bottlenecks for low-end hardware.
Full-screen refreshes will still be slow, but single-line changes or partial refreshes should be significantly faster.

from papertty.

Thank for your answer @mcarr823 !

I've been trying a lot of things, and I can get marginally better results by using simpler fonts and such. The thing is A2 doesn't work of the bat on 6"HD, it needs to be four byte aligned. I don't really know what that means so that's where I'm stuck right now. Can you tell me more about that?

I'll check your branch out, have only skimmed it so far.

from papertty.

@Wim4rk Regarding 4-byte alignment https://www.waveshare.com/wiki/10.3inch_e-Paper_HAT#4-byte_alignment_description
My understanding is that the 6" panels need to align to a 4-byte boundary on the x axis and for the width when in 1bpp mode.
In 1bpp mode there are 8 pixels per byte, meaning 4 bytes = 32 pixels.
So the x coordinate of a draw would need to be divisible by 32, and the width of the image you're drawing would need to be divisible by 32 as well.
eg. You can't draw a 16x16 image because it needs to be at least 32 pixels wide. You can't draw a 48x48 image because it's not evenly divisible by 32. And so on.
And you could draw at x coordinate 0 or 32, but not at x coordinate 16 or 48, for example.

That being said, the IT8951 driver already has a variable of
self.align_1bpp_width = 32
papertty.py passes that through to the "band" method if you're in 1bpp mode (which is turned on by default for terminal mode). The band method then modified the x boundary and width to suit that value.
So it should already be giving you images which have an x coordinate and a width divisible by 32.
I would have thought that for the 6" panels it would be a matter of uncommenting
#self.supports_a2 = True
and it would "just work". But if that didn't work for you then I guess there's still something else which needs to be done.

from papertty.

@mcarr823 Great answer. I wrote a function: self.width - (self.width % 32) to double check. will keep looking into all that again.
It's been working all along, in that I've always gotten an image.
Maybe it's easy as getting a beefier Pi (and a large battery). It's just...

The demos Waveshare put out for the screen are running quick and snappy. That indicates to me that there should be something I can do.

I'm working on your branch now, added a PR for a new GPIO version. We'll be talking again over there, I'd guess. Thanks a million for your answers.

from papertty.

@Wim4rk If uncommenting that line did work (or if you can get it to work) it would be great if you could submit a PR with that change confirming that A2 mode works for you on that model. Might need to test both landscape and portrait mode, just in case there's a change needed there with how the 4-byte alignment works.

In terms of a beefier pi, that's certainly one way to go about it.
DU -> A2 mode shaves off something like 120-140ms. But most of the lag you're facing is because you've paired a low-power pi with a high-res screen, which is something papertty doesn't currently handle well.

I went into some detail about that on this issue #107
And that performance problem is what the branch I linked to aims to solve https://github.com/mcarr823/PaperTTY/tree/single-line-refresh
As noted on the linked issue, I was able to get the delay for a rpi 2b (which I believe has single-thread performance similar to the pi zero) down from 1.2s -> 250ms.

I'll go into greater detail on the PR when I've fixed up that branch and actually submitted one, but basically papertty has a bottleneck in performance. It's present on all pairings, but it's especially noticeable in situations like yours (low-power pi, high-res panel).
Basically papertty currently works like this:
Grabs text from buffer -> builds fullscreen image -> compares new image to previous image -> writes what has changed to the panel.
For a high-res panel and a low-power pi, drawing a fullscreen image, then comparing that image to another image of the same size, is quite an expensive operation.
The branch I linked to instead works like this:
Grabs text from buffer -> compares text to previous text buffer -> builds a small image containing only the changed text -> writes to panel
Comparing text is way faster than drawing and comparing images, especially with a low-power CPU and a high-res screen.

So trying that branch should help a lot. Switching to a faster pi would also help. Doing both should help immensely.
With a rpi 2b on that branch I get around 200-250ms of overhead from papertty for minor text changes.
With a rpi 4b on that branch I get around 8-20ms of overhead.
So if switching to that branch still isn't fast enough, getting a faster pi would certainly help.

from papertty.

@mcarr823 Define working. I get an image, both in portrait and landscape. It updates, although slowly. It seems stable and safe for the screen.

from papertty.

@Wim4rk If it's running in terminal mode, and you can type a few lines of text without any of it becoming garbled or looking broken in any way, then I think it's working.

from papertty.