full updates don't work correctly after fast mode

[stevenbell]

I'm using vnsee with Xournal++ to annotate PDF slides. I've found that when I write with the pen, the du "fast repaint" mode seems to interfere with the complete update once the pen is lifted. If I use the red pen, the du updates don't do much (no problem, that's expected), but then the "standard" update doesn't properly update the stroke, and I'm left with nearly invisible lines.

I tried tweaking a few things in the code, and have figured out the following so far:

• The standard update is happening after the pen is lifted (screen::repaint() is called and uses the whole rectangle)
• It seems that the update is only occurring on parts of the screen where the du update has not taken place yet. If I move the pen quickly, then part of the stroke is updated correctly, but if I move it slowly, then almost none is updated.
• The fast repaints are called on the full update rectangle, which grows as the pen continues to draw. This seems odd to me. Shouldn't a sequence of (mostly) non-overlapping fast repaints be sufficient, followed by a single standard repaint at the end?

Any suggestions on what might be going on?

[matteodelabre]

Hi @stevenbell, thanks for sharing this report. This is on rM1, right? I tested this on both device versions and I only managed to reproduce the issue on rM1.

• It seems that the update is only occurring on parts of the screen where the du update has not taken place yet. If I move the pen quickly, then part of the stroke is updated correctly, but if I move it slowly, then almost none is updated.

This could be a timing issue where we should wait more before triggering the gc16 update, or maybe the controller doesn’t like that we are pushing du updates that contain intermediate grays where it supports only full black or full white pixels.

• The fast repaints are called on the full update rectangle, which grows as the pen continues to draw. This seems odd to me. Shouldn't a sequence of (mostly) non-overlapping fast repaints be sufficient, followed by a single standard repaint at the end?

I agree with you here, the current behavior is not optimal. It has also the side effect that the display response lags more and more behind the pen input as you make a long continuous black stroke. This is because we only keep a single dirty rectangle struct that is shared for fast and standard updates. By keeping two independent such rectangles we could improve the fast redraw behavior.

[stevenbell]

Yes, this is on rM1. That's very interesting that it doesn't happen on rM2... must be something related to the screen driver and update behavior.

I'll experiment with adding some delays and with using two "dirty" rectangles, and see what more I can learn. Thanks!

[giorgio-arena]

Just wanted to let you know that I'm having the same issue on remarkable 2 (version 2.10.1.332 patched with ddvk-hacks). I've installed this through Toltec but I'll try to build from source and play around with the code in order to fix this, but for future development I think it'd be good to add an option for setting the repaint delays