You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
EDIT: My question is can I run scrcpy with an options to handle this scenario better?
Supernote is an eink tablet like remarkable. My Supernote_A6_X is running an old Android 8.1.0 (Chauvet) with a very custom UI - they're also working on a linux OS.
Wanting to use scrcpy is a bit of an edge-case device (because it already has device streaming functions), but it actually almost works with scrcpy. Could be useful when device is off wifi.
I found you can get the screen to display (default will green screen) with:
While drawing, the screen refresh on scrcpy is fairly delayed about 4 seconds. I think this to do with the supernote being e-ink and the pen drawing is not causing a refresh of the entire device screen. The pen pulls the "black ink" up on the screen if you will - without the need to invoke a redraw on the entire screen. If I swipe to navigate pages (a full redraw), scrcpy refreshes instantaneously, basically telling me that scrcpy is refreshing quick when the entire device refreshes. That's simply not the nature of this eink device. When I print out fps it mostly sits at 0 fps indefinitely until something happens. Draw something will bump up temporarily like this:
The "ink" you saw, might not be in Android rendering process, yet.
Many operating systems have special, low-level APIs for minimizing pen drawing latency, for example, Windows's InkPresenter and Android's low latency graphics.
They receive pen inputs, apply some simple but customizable styles (like color and thickness), and draw to screen directly ("wet" drawing), as quickly as possible, bypassing many normal input and graphics processing. The foreground app only receives batched input events periodically, or after the pen is lift up, to do further processing, draw the final image (called "drying"), and save them.
Although Android's built-in low latency graphics API was added in Android 11, because the importance of this feature, especially for e-ink devices, I imagine the manufacturer has something similar to that, possibly even in hardware.
So it's normal that, while you are drawing, the Android's system knows nothing and never update the screen.
EDIT: My question is can I run scrcpy with an options to handle this scenario better?
Supernote is an eink tablet like remarkable. My Supernote_A6_X is running an old Android 8.1.0 (Chauvet) with a very custom UI - they're also working on a linux OS.
Wanting to use scrcpy is a bit of an edge-case device (because it already has device streaming functions), but it actually almost works with scrcpy. Could be useful when device is off wifi.
I found you can get the screen to display (default will green screen) with:
While drawing, the screen refresh on scrcpy is fairly delayed about 4 seconds. I think this to do with the supernote being e-ink and the pen drawing is not causing a refresh of the entire device screen. The pen pulls the "black ink" up on the screen if you will - without the need to invoke a redraw on the entire screen. If I swipe to navigate pages (a full redraw), scrcpy refreshes instantaneously, basically telling me that scrcpy is refreshing quick when the entire device refreshes. That's simply not the nature of this eink device. When I print out fps it mostly sits at 0 fps indefinitely until something happens. Draw something will bump up temporarily like this:
FPS:
Is there a way to tell scrcpy to refresh/poll at a certain interval?
Or is this currently designed to be defined from the device itself?
I feel like if I could tell scrcpy to run at a refresh I specify, not the device, it would refresh as I draw on the device. Which would be sweet.
The text was updated successfully, but these errors were encountered: