There is something unusual about the modern office. Two people can be sitting on the same floor and still join the same meeting from separate laptops.
Ishan Sharma, Senior Software Engineer at Microsoft, thinks the reason says something important about where enterprise software is heading.
“People stopped walking to the conference room, not because it was far, but because the rendered version was better equipped.”
The online meeting can include screen sharing, captions, chat, recording and, increasingly, a searchable record of what happened. The physical room offers presence, but software adds an entire digital layer around that presence.
For Sharma, this is one sign that real-time rendering has quietly moved from a specialist graphics concern into something much closer to enterprise infrastructure.
“Nobody has a VP of Rendering,” he says, “and every company now depends on one.”
That dependence extends far beyond video meetings. Shared workspaces, live dashboards, collaborative documents, remote desktops and increasingly visual AI interfaces all rely on software responding quickly enough that the experience feels immediate.
Once users become accustomed to that standard, it becomes difficult to lower it again.
Enterprise software is no longer graded on a curve
For years, internal software could be slow, awkward or visually dated and still survive because employees often had little choice about which tools they used.
Sharma believes real-time collaboration helped change that expectation.
“Enterprise software used to be graded on a curve. Users were captive, so slow and ugly survived. Real-time video ended that curve because it put a consumer-grade experience in the middle of everyone’s workday, including the CEO’s.”
The change is not simply that enterprise applications are expected to look better.
They are expected to react immediately.
A delayed cursor, unreadable shared screen or frozen interface can now feel less like a cosmetic flaw and more like a failure of the application itself.
That is where Sharma thinks rendering becomes more interesting. Some of the requirements handled inside modern graphics pipelines have little to do with visual polish alone.
Background blur is a good example.
It is usually described as a visual feature, but Sharma sees it as a privacy feature as well.
“Background blur is effectively a privacy policy implemented through the rendering pipeline.”
When people began joining professional meetings from bedrooms, kitchens and shared homes, cameras started revealing details that an office normally kept private: family members, personal belongings, living conditions and other parts of life that people may not want visible to colleagues or customers.
The technical solution is graphical and computational at the same time.
Software must identify the person in each frame, separate them from the background and continuously modify that background while the device is already processing video, audio and the rest of the application.
“Background blur became a widely used example of machine learning operating directly inside a real-time visual pipeline,” Sharma says. “It also has to compete for the same limited hardware resources as the rest of the experience.”
For Sharma, this points to a broader shift.
Privacy can depend on how accurately an image is segmented. Inclusion can depend on whether an application still works well on an older laptop. Reliability can depend on how gracefully the software responds when hardware resources become constrained.
Even deciding how much visual information to render at once can become a resource-allocation problem.
“Presence itself can become a rendering budget,” he says. “The system has to decide how much visual information it can process while still keeping the experience responsive.”
When rendering fails, the failure is public
Enterprise rendering also carries a different kind of consequence from the graphics problems people usually associate with games or entertainment.
“In games, a dropped frame costs you the shot. In enterprise software, it can cost you the room.”
A frozen image during a client presentation is visible to everyone. An unreadable screen share can stop a discussion. A camera or interface that repeatedly fails may make someone appear unprepared even when the underlying problem is entirely technical.
“The failure is public,” Sharma says. “It happens in front of your manager or your customer, and people may blame the person before they blame the software.”
That changes what engineers optimize for.
The goal is not necessarily to deliver the most impressive experience on the most powerful machine. In enterprise software, it is often more important that the experience remain usable across a broad range of devices.
“The better question is not how good the application looks on the best machine,” Sharma says. “It is how gracefully it performs on the least capable machine that still needs to participate.”
That can quickly become an inclusion issue.
If someone using an older computer cannot keep up with the rendering workload, the result is not simply lower visual quality. They may miss part of a presentation, struggle to read shared information or find it harder to participate naturally in a conversation.
The difficult workload may be a spreadsheet
When people hear “real-time rendering,” they tend to picture video, games or 3D graphics.
Sharma points to something far less dramatic.
“The most demanding rendering workload in many companies may not be a 3D model. It may simply be somebody sharing a spreadsheet.”
Screen sharing is surprisingly difficult because computer screens contain information that needs to remain precise.
A video frame may contain faces, backgrounds and gradual movement. A shared screen can contain tiny text, sharp borders, charts, code and high-contrast interface elements.
When someone scrolls or changes windows, large parts of the frame may change at once.
The problem becomes even more obvious when the presenter is using a large, high-resolution monitor and the viewer is trying to read the same content on a smaller laptop.
Anyone who has squinted at unreadable spreadsheet cells or code during a meeting has experienced the result.
The network often receives the blame, but the experience can depend on several stages working together: screen capture, compression, transmission, decoding, scaling and final display.
It is an unglamorous example, but that is precisely Sharma’s point.
Some of the hardest real-time graphics problems in enterprise software now appear during completely ordinary work.
A rare bug can become an entire customer’s problem
The challenge becomes harder once software leaves a controlled development environment.
Rendering behavior can depend on a particular operating-system version, graphics driver, processor generation, display setup or combination of hardware resources.
“Performance is not a property of your code alone,” Sharma says. “It is a property of your code interacting with drivers, operating systems, schedulers, hardware and resource limits.”
The environment can also change independently of the application itself.
An operating-system update, graphics-driver change or hardware configuration can alter behavior even when the application code has not changed.
That makes debugging and reliability engineering especially difficult.
At scale, global averages can also hide serious problems.
A software issue affecting a very small percentage of devices may appear insignificant when measured across millions of users. Enterprise hardware, however, is often purchased and configured in large batches.
One organization may therefore have thousands of similar machines running nearly identical hardware and software configurations.
“A problem that affects only a fraction of the overall population can still affect a very large share of one organization’s users,” Sharma says.
That makes enterprise reliability difficult to judge from aggregate numbers alone.
A system can appear healthy globally while one particular device configuration or customer environment is experiencing significant degradation.
Rendering is becoming part of the enterprise contract
Most users will never think about the rendering pipeline.
They will notice whether a meeting begins smoothly, whether shared information is readable, whether their background remains private and whether the application still works on the machine they have been given.
Those expectations increasingly depend on decisions made inside the rendering and visual-processing layers of software.
That is why Sharma sees real-time rendering as more than a graphics discipline.
It now sits at the intersection of performance, privacy, reliability and participation.
Companies may never appoint a “VP of Rendering.” But the rendering layer increasingly influences what people can see, what others can see about them, whether they can participate effectively and whether the software remains dependable when the device or operating environment is far from ideal.
At that point, rendering becomes difficult to treat as a visual detail.
It becomes part of the promise enterprise software makes to the people who depend on it.
Disclaimer: The views expressed in this article are Ishan Sharma’s personal views and do not represent the views, positions, policies, product plans or practices of any current or former employer. The discussion is based on general software engineering principles and industry practices and does not disclose confidential or proprietary information, internal incidents, non-public metrics, implementation details or product roadmaps.
