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

Drawing latency compared to xochitl #18

Open
Evidlo opened this issue Jan 14, 2019 · 2 comments
Open

Drawing latency compared to xochitl #18

Evidlo opened this issue Jan 14, 2019 · 2 comments
Labels
discussion Discussion encouraged. If this is preparation for a PR, it likely has no agreed implementation yet. wontfix This will not be worked on

Comments

@Evidlo
Copy link

Evidlo commented Jan 14, 2019

I've been playing with the demo and I noticed that the pen latency is a bit higher than in xochitl. Any idea what the cause is or if it can be reduced?

@SafariMonkey
Copy link
Contributor

I'm sorry that this was somewhat forgotten, I wrote a long reply when it was originally posted and accidentally closed the tab and lost it. I've been meaning to rewrite it but have been distracted by other things. I'll try to give a shorter summary of those points. I'd appreciate @canselcik's thoughts too, if/when he has time.

We haven't been able to reliably test the latency, due to lack of high quality high speed recording equipment. Subjectively, it seems to me to be fairly competitive, but I do think it's a little slower.

The version of the libremarkable demo on the master branch (currently unreleased I believe) uses a more efficient drawing implementation and a Bezier based drawing method, giving only an additional 0.5 samples of average latency over linear interpolation. (Given the expected report rates of 200+ Hz (untested), that would be less than 3ms additional latency. As such, I doubt that's the issue.) If you haven't tried this version, I'd be interested to know if you think it's faster, and how it compares to the xochitl version.

For other possible factors, there's this from an article about the rM:

He set himself the goal of removing everything that gave the system inertia, from the operating system to the hardware and software. In addition, we have worked a lot with prediction. The software calculates the position of the pen in the future and draws the line where it comes, says communication manager at Remarkable, Henrik Faller.

(via Google Translate)

That seems to be indicating that xochitl is actually using predictive drawing, which may be the case but I haven't managed to fool it yet (e.g. by drawing quickly up to the edge of a ruler) so I'm not totally sure that it's implemented in the available version.

@LinusCDE
Copy link
Collaborator

The difference should be negligible and most people perceive the latency to be the same. Apart from a minimal function diff, the difference will likely be in how the drawing is done (naive, bezier, ...).

I doubt that there is an actual low level difference and latency on the rM 2 should currently be objectively higher due to the need to send calls via IPC (but most likely negligible as well).

We haven't been able to reliably test the latency, due to lack of high quality high speed recording equipment. Subjectively, it seems to me to be fairly competitive, but I do think it's a little slower.

If anyone has such equipment, comparing the demo (and basic_draw example) to xochitl with it would be really valuable on either model. Apart from that, I don't think there is much we can do to fix this.

@LinusCDE LinusCDE added discussion Discussion encouraged. If this is preparation for a PR, it likely has no agreed implementation yet. wontfix This will not be worked on labels Jan 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion encouraged. If this is preparation for a PR, it likely has no agreed implementation yet. wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants