16 August 2026
Annotating a shared screen means drawing directly on the image someone else is showing — circling a field, underlining a line of code, dropping a pin on a chart — instead of saying "the box near the top, no, the other top." It works because it replaces a description with a location. It breaks, silently and often, when the person drawing and the person watching are looking at two different-shaped windows and the mark was placed against the screen instead of the picture.
Verbal location is slow and lossy. "Second row, third column, the one that says pending" takes four exchanges to land, and it fails completely the moment the shared view scrolls or the table reflows. A mark takes one gesture and lands in a place everyone can see at the same instant, which matters most in the exact situations where annotation gets used: reviewing a design mockup, walking through a spreadsheet, pointing at a specific error in a stack trace someone else is sharing.
The gain is biggest on dense, visual material — dashboards, diagrams, code, PDFs with small print — and close to zero on a slide with one sentence on it, where saying "that line" is already unambiguous. Annotation is a tool for precision on crowded content, not a feature to reach for by default.
Here is the part that goes wrong and nobody notices until it does. The person sharing their screen has a window at some resolution and aspect ratio. Everyone watching has their own window — a laptop lid open to a different size, a phone in portrait, a second monitor stretched wide. If a mark is recorded as "320 pixels from the left, 180 from the top," that coordinate means something different on every one of those screens.
The presenter's 1920×1080 laptop and a viewer's 2560×1440 external monitor don't just differ in size, they can differ in what fraction of the frame is filled with actual content versus letterboxing, especially when someone shares a single narrow app window rather than a full screen. A pixel-based mark drifts off the intended spot as soon as the aspect ratios don't match, and it drifts worse on a phone.
The fix is to record the mark as a position relative to the content, not the screen — a fraction like "18% across, 40% down" rather than an absolute pixel. That normalized coordinate means the same thing regardless of how large or what shape the viewing window is, because every viewer's client scales it to their own frame before drawing it. This is the one design decision that determines whether annotation is useful or just a party trick that works in a demo where both screens happen to be the same size.
It also has to survive the presenter resizing, minimizing, or switching which window they're sharing. A mark anchored to screen pixels vanishes or jumps the moment any of that happens. A mark anchored to the image content — the actual pixels of the shared frame, wherever they land — stays put until the presenter clears it or the shared content itself changes underneath it.
Most implementations restrict drawing to whoever is presenting, or require the presenter to grant it, because open annotation on someone's live screen turns into six people scribbling on a spreadsheet at once. A smaller set allow any participant to mark up what they're seeing, which is closer to a whiteboard and works better for design review than for a status update.
Marks are almost always live-only. They exist as an overlay rendered on top of the shared frame for whoever is watching in that moment, not as a change to the underlying document or app. When the share ends, the marks are gone unless someone captured a screenshot first — the same live-only limitation that applies to files dropped into a meeting for everyone to see: it's there for the call, not for the record.
AVAY supports live annotation on a shared screen with marks anchored to relative position on the shared frame, so a circle drawn on a chart lands on the same bar of the chart whether the person looking at it is on a widescreen monitor or a laptop lid, and it stays there if the presenter's window gets resized mid-call. It does not persist the marks into the meeting's permanent record — like a file dropped into the call for everyone to see, an annotation is live for the people in the room at the time, not something someone joining the recording later will find waiting on the screen.
If a markup needs to outlast the call, the practical move is a screenshot at the moment it matters, or noting the decision in the meeting's decision log rather than relying on the drawing itself to survive.
| Precision | Works across different window sizes | What it asks of the viewer | |
|---|---|---|---|
| Describing it out loud | Low — depends on shared vocabulary | Not applicable, no visual reference | Listening carefully |
| Cursor or laser-pointer highlight | Medium — visible only while held there | Yes, if anchored to the content | None |
| Click-to-mark annotation | High — exact spot, persists until cleared | Only if the mark uses relative coordinates | None |
| Remote control handoff | Highest — direct manipulation of the file | Yes, it's the same screen | Must accept a control request |
Most tools default to letting only the presenter draw, because open drawing rights turn into several people marking up the same document at once. Some let the presenter grant drawing rights to a specific person for the duration of a review, which works better for design walkthroughs than a full free-for-all.
Generally no. The transcript captures what was said, and a recording captures the video feed including whatever was drawn at the moment it happened, but the mark itself isn't stored as a separate, retrievable object once the share ends. If it needs to survive, take a screenshot while it's on screen.
This almost always means the annotation was recorded as an absolute pixel position instead of a position relative to the shared content. It shows up worst when the presenter is on a HiDPi display and the viewer isn't, or when someone is sharing a single app window with a different aspect ratio than a full screen.
Yes, but the frame being annotated is whatever the tab renders, which can be narrower or a different shape than a full-screen share. That's fine as long as marks are anchored to the tab's content rather than to screen pixels — the same rule applies, just with a smaller frame.
If the mark is stored as a relative position, it stays anchored to the same spot on the content and just gets redrawn at the new size. If it was stored as an absolute pixel position, it will drift or disappear, which is the failure mode that makes annotation feel unreliable when it's actually a coordinate system problem.
Annotation earns its keep on dense, visual content where a spoken description would take four back-and-forths — but only if the mark is tied to a position on the picture, not a pixel on the screen, since no two people in the call are looking at a window the same shape.
Meetings that take their own notes, in the browser: avay.ai.