Why the pointer always lags behind in shared annotations
There’s this moment during a product demo—you’re highlighting a feature using your fancy built-in drawing tools, and someone on the other end says, “Wait, you already erased that? It’s still on my screen.” If I had a dollar for every time marked-up annotations lagged during a screen share, I’d have enough to fund a whiteboard that doesn’t suck over WebRTC.
The actual lag issue usually isn’t the drawing tool itself—it’s the way the stream encodes increasingly complex frames. Drawing live shapes (especially those ghost-trail pen ones) causes a flood of small updates. In low-bitrate settings, apps like Zoom throttle these updates, prioritizing voice packets instead. So your red arrow gets stuck mid-curve until the audio settles.
In rare cases, I’ve seen the pointer itself de-sync completely—like it hovers 200 pixels to the right of where it should be. That turned out to be due to the remote viewer’s DPI scaling (150%) messing with the video overlay hub’s coordinate offset. Basically: their interpretation of your shared desktop isn’t 1:1.
“Drawings work better when sharing a window—not the whole desktop. Does that make sense?”
That nugget came from a frustrated support engineer during a Miro chat session. It holds up. Full-desktop mode involves too many variables: cursor offset, multiple monitors, notification overlays. Stick to app-only shares when annotations matter, like during bug triage or design review.
Screen annotation recording: how most tools butcher it
You’d think that pressing “Record” during a Zoom screen share would faithfully capture whatever you’re drawing. Nope. What you actually get in the MP4 is one of three things:
Your voice and perfect audio—but no annotations at all
Annotation trails that disappear prematurely
An old snapshot of the annotation from 10 seconds ago, yay
I once recorded two hours of feedback sessions annotated over a Figma prototype using Microsoft Teams. During playback, not a single arrow or underline was visible—just lots of “as you can see here” while the viewer saw… the unmarked design. I almost threw my Surface out the window.
Turns out Teams doesn’t commit ephemeral overlays into the meeting recording unless you use their built-in Whiteboard. So the annotations were there—for the participants—but not for the file artifact.
If you absolutely depend on annotation visibility in replays, either use something like Loom (which encodes literally every pixel you draw) or record locally with OBS where you control the entire frame capture.
When annotation layering breaks due to UI interference
This took me a few mornings and two coffees to isolate: if you notice your drawing vanishing immediately after you make it, check for tooltip overlays.
Yeah. Tooltips. For example, if you’re sharing Google Slides in full screen via Chrome, and you mouse over a menu item, the browser’s native tooltip might appear over your drawing layer. Most annotation software uses canvas overlays or SVG wrappers tacked on via JavaScript. These don’t always play nice with DOM elements outside their inherited z-index context.
I used to think this was just a Google Slides quirk, but nah—it happened in Notion too when sharing over Slack’s native screen share. In one session, I spent 10 minutes drawing rectangles on a screen the other party could never see because a submenu kept hijacking focus and repainting over the annotations.
A reactive fix? Flip your annotation layer to a separate window and share that instead. More complex, but it at least isolates control from the volatile browser iframe soup.
Zoom, Teams, and Webex: where annotation capabilities quietly diverge
I’ve tested annotations across a handful of corporate-favorite video platforms while troubleshooting design feedback sessions. The TL;DR:
Zoom: Arguably best-in-class for annotation. But only one person can draw unless you’re in whiteboard mode. Disabling annotation for attendees is buried three menus deep.
Teams: Annotation is a unicorn unless you’re using PowerPoint Live or Whiteboard. No app-screen drawing by default. Feels wild that this is intentional.
Webex: Allows drawing if you enable a proprietary layer. But guess what? That disables co-browsing features. Also, half your options vanish if you’re joining in-browser instead of with the native app.
The most annoying edge case with Teams: if you start sharing a window and mid-share open a different app to annotate, Teams ignores your mouse events silently. No error, nothing. You’re drawing, but it never reaches the stream buffer.
Someone from Webex support once asked me, quote, “Are you using the drawing ring tool *before* sharing the screen?” If you’re curious: yes, that affects behavior. Whole platform logic flaw.
Annotation tools that DO work cross-platform (sort of)
If you’re looking to abandon the built-in options and overlay your own annotation on any platform, you end up in OBS/ShareX/custom overlay hell. But there are a few standalone drawing tools that actually render on top of all windows consistently—without anyone needing to install secondary software.
These worked across my Mac/Windows setups:
Epic Pen (Windows): Stable, hotkey-based, low interference. Doesn’t play well with HDR, though.
Pencast (Mac): Weird UI, but nice stabilized lines and viewport awareness. Reviewed on a Macbook Pro M1 under high load—no lag.
OpenBoard: Great if you also need to save board states mid-session. Linux-friendly too.
Downsides: your annotations are local only. Someone watching via Google Meet won’t see the drawings unless your actual screen share pushes those pixels. It’s not co-annotation.
Still, for async recordings or hybrid sessions, these tools are miles ahead of trusting platforms with inconsistent drawing logic.
“Undo” doesn’t mean what you think it means
Quick rant: in so many annotation-enabled tools—especially Google Meet and Zoom—the Undo button doesn’t necessarily undo your last drawing action. It often undoes only the last object created via shape tools. Dragged rectangles, for example. But freehand pen lines? Those don’t always count as discrete objects and refuse to go away on Ctrl+Z.
This bit me hard while sharing a system diagram. I meant to erase a squiggly line I had drawn to highlight a server cluster. Hit Undo. Entire cloud element I had made two minutes earlier vanished instead. Couldn’t bring it back.
Found out later in a deeply buried Zoom forum thread that Undo operates on objects only and ignores stroke data unless you’re in whiteboard mode. So drawings made over shared apps are more like video overlays—not editable structs.
Security quirks: who can save your annotations without you knowing
Had a pretty gnarly incident where someone took a screenshot mid-draw during a sensitive client roadmap review. I had used Zoom’s drawing tool to circle timelines, but didn’t realize the participant had “remote control” temporarily to navigate slides. That gave them access to the annotation toolbar too, which includes “Save snapshot.” I heard the shutter click and just stared into the void for a beat.
The save button isn’t visible to all users unless toolbar permissions are granularly edited—which you can only do from host settings.
Also worth noting: in Webex, meeting participants can export whiteboard drawings even if the host disables recording. That is NOT surfaced in the UI. Found it out the hard way when a client’s NDA doc appeared in a follow-up email annotated to hell with stakeholder nicknames.
If you’re handling client data or legal docs: lock sharing mode, disable collaborative annotation, and use a local overlay. Trust = revoked otherwise.
The bug where mouse trails break live updating
This one’s obscure but deadly. If you’re using apps like Microsoft Whiteboard or any WebRTC-based real-time canvas (think Mural, Canva live collaboration, etc.), users on older Safari builds (pre-15.x) will sometimes see their mouse update stuck in a fallback static position… forever.
One user moves their mouse over the canvas. You see them “hover” once. Then everything freezes. Doesn’t matter what actions they take—they’ve been phantomified.
I traced this down using browser developer console output. The offending log:
[WebRTC]: Failed to update RTCPeerConnection candidate due to delayed offer/answer flow
Yeah. Because mouse trails depend on timely peer updates. Once that candidate fails, the delivered delta position only checks in every 15–20 seconds—well below the annotation framerate needed for live drawing. Classic failure mode only some platforms catch and retry.
Fix is either global mouse reinitialization (lol) or rejoining the session. A full tab refresh won’t cut it unless the signaling state is rebuilt from zero. Now I just tell users upfront: Safari? Please… don’t.
