Draw pen hover position into image #46
Conversation
|
Hi there! This looks good, I didn't know this would be so easy. Do you notice an impact on framerate/lag? I'm planning on adding commandline features to reStream. so I'll merge this once that is implemented, with the option to turn this feature on/off. Thanks! |
I believe the framerate is currently only limited by the bandwidth of the USB link, so there's no impact from drawing the cursor. It does make the low framerate on more complex pages (that don't lz4-compress as well) very noticeable, though.
Excellent, I can update the PR once that's there. |
|
@lluchs I've created a new release (with the addition of command line arguments), can you rebase your PR on it and add an option to enable this feature? |
This is useful to point out parts of your drawing when streaming to a video conference.
lluchs
left a comment
There was a problem hiding this comment.
I rebased and added an option now. There's a few places that might need adjustments for RM1.
I believe the framerate is currently only limited by the bandwidth of the USB link
That doesn't seem to be true by the way, I think I was confused by top output because of the idling second core. I think I'm going to try doing the compression with two threads...
| anyhow = "1.0" | ||
| lz-fear = "0.1" | ||
| clap = "3.0.0-beta.2" | ||
| libremarkable = "0.4.3" |
There was a problem hiding this comment.
This pulls in a lot of unnecessary dependencies, I already opened a PR (linked earlier) to reduce that somewhat. Doesn't seem to have an effect on binary size, though.
|
|
||
| /// Draw pen position into fb data, if necessary (in hover range and not drawing). | ||
| fn draw_pen_position(&mut self, buf: &mut [u8]) { | ||
| if let (false, Some((y, x))) = (self.drawing, self.pen_pos) { |
There was a problem hiding this comment.
The input and framebuffer axes are swapped on RM2, so we have (y, x) here. Might be different on RM1.
| px_end = cursor + buf.len() as isize; | ||
| } | ||
| // invert pixel (on RM2) | ||
| // TODO: Do something sensible on RM1 |
There was a problem hiding this comment.
I don't know how the RM1 framebuffer works, inverting each byte like this might be wrong.
|
Are there any plans to get this merged? |
| // we need negative numbers to calculate offsets correctly | ||
| let width = self.width as isize; | ||
| let height = self.height as isize; |
There was a problem hiding this comment.
| // we need negative numbers to calculate offsets correctly | |
| let width = self.width as isize; | |
| let height = self.height as isize; | |
| let flip = self.width > self.height; | |
| let (x, y) = if flip { (y, x) } else { (x, y) }; | |
| // we need negative numbers to calculate offsets correctly | |
| let width = if flip { self.height } else { self.width } as isize; | |
| let height = if flip { self.width } else { self.height } as isize; |
A rm2 without rm2fb has inverted width/height
There was a problem hiding this comment.
With this change, it works nicely!
|
Hi @abmantis, I can look at merging this but I would first have to test if this works on an rM1. You can create a new PR with the changes you requested, rebased with the current main branch. |
I already had a working branch that was updated from the main branch already. Opened a PR now: #90 |
This is useful to point out parts of your drawing directly on remarkable when streaming to a video conference.
Demo:
pen_marker.mp4
I don't have a RM1, so I couldn't test there. I did implement two bytes per pixel, but inverting might work differently.
Adds a dependency on libremarkable for input handling.