BUG: Poor Freehand Stroke Sampling Rate on E-Ink Android Tablet with Wacom Digitizer

[michimussato]

Your environment Please run Command Palette/Show Debug info in Obsidian and paste the result here.

SYSTEM INFO:
    Operating system: android 11 (alps k65v1_64_bsp)
    Obsidian version: 1.4.9 (108)
    API version: v1.3.7
    Login status: logged in
    Catalyst license: none
    Live preview: on
    Legacy editor: off
    Base theme: adapt to system
    Community theme: none
    Snippets enabled: 0
    Restricted mode: off
    Plugins installed: 13
    Plugins enabled: 10
        1: Advanced Tables v0.19.1
        2: Canvas Presentation v0.0.3
        3: Dataview v0.5.56
        4: Mindmap NextGen v1.9.0
        5: Map View v4.0.0
        6: Excalidraw v1.9.19
        7: Linter v1.19.1
        8: Calendar v1.5.10
        9: Google Calendar v1.10.3
        10: ExcaliBrain v0.2.9

RECOMMENDATIONS:
    Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.

Describe the bug Freehand writing on an Android tablet with Wacom Digitizer layer using the stylus lacks detail. Sampling rate seems very slow.

To Reproduce Steps to reproduce the behavior: Hard to say. My tablet is running Android and is an E-Ink note taking device (Bigme Galy 3).

Expected behavior The expected behavior would be that the freehand drawing quality (stroke resolution) would be equal to drawings made on my PC using a Wacom tablet. Hard to say if it is directly related to the slower refresh rates of E-Ink tech. However, OCR writing with Google GBoard works without issues.

Screenshots

Additional context Add any other context about the problem here.

[nidhoggr-nil]

@zsviczian If I were to take a look at this, do you have any helpful tips? I had my eye on this issue for a long time, and it seems persistent across platforms.

• Is it correct to assume that all the logic for pen-input is handled within excalidraw itself and not the plugin?
• Do you know if excalidraw itself exhibits the same behavior?
• Did you already take a look at this, and gave up because the javascript timer loop is too slow or the excalidraw render/update code itself is too intermingled?
• If the container is limited somehow in drawing updates via requestAnimationFrame or whatever they might have used in excalidraw, I guess a solution would be to go through their code and change it or decouple the components responsible for drawing and run them separately unless the main thread is being blocked somehow. Don't know if service workers are mature enough to run something like this in a separate thread, but I'm still afraid of relying on those things without thorough testing.
• I'm also afraid that the electron container itself could impose limits on update frequency, if that was the case, it would be bad.

Kind Regards