In a Citrix Virtual Apps and Desktops environment, mouse cursors are presented to a user in one of two ways in an ICA session: client-rendered or server-rendered.

In most cases, mouse cursors are client-rendered. By default, the HDX graphics process will detect OS and application cursors on the VDA (server side), capture the cursor image and send to the Citrix Receiver or Workspace App for rendering locally on the client. A client-rendered cursor delivers the best performance and user experience as it behaves the same as with any local application running on the physical endpoint. This means there is no added latency to the mouse movement from the virtual session.
 
There are two special cases where client rendering of the cursor is not possible for a particular Citrix session and the mouse cursor is server-rendered as a result:
 
Custom cursors (non-Windows standard)
There are some applications that use proprietary cursor types and handle cursor rendering on their own. These applications do not use the standard Windows OS functions to set and render cursors on screen. In this scenario, the application cursor looks no different to the HDX graphics process than any other image on screen. Because of this, it is not possible to query the Windows OS and detect the cursor in use in order to redirect for client rendering.
 
AutoCAD from Autodesk is a common example of an application that uses custom cursors.
 
Lack of cursor compatibility with HDX Graphics and Citrix client in use
This is more of case with modern applications running in Citrix sessions configured with HDX Legacy Graphics mode and older Receiver clients. Not all cursors are created equal. Modern and more complex types such as 32-Bit color cursors may require use of new HDX graphics mode and recent/current versions of the Citrix client.

Performance Impact
Server-rendered cursors can be very costly for virtual desktops and applications. Every time the user moves the mouse, the client sends a message to the server, so the desktop or application can be redrawn and the resulting image (the new cursor position) is sent back to the client. This process may need to be executed hundreds or thousands of times to capture every change in cursor position, depending on the user movement of the mouse. This can generate high-bandwidth and, if the application is very complex (Ex. a complex CAD model where the application is recalculating the part), it can become a bottleneck. It can also result in a lot of redrawing of transient intermediate frames that are unnecessary, intermittent information that a user doesn’t need, like when scrolling or moving a window rapidly.
 
In this scenario, a user may perceive a slight delay when interacting with a server-rendered cursor because they are interacting with a graphical representation of the cursor that is being remoted across the network instead a local cursor rendered directly on the client hardware. The issue would be more apparent in low bandwidth and high latency network conditions. A user on a local area network may not perceive the issue compared to a user connecting over a WAN link, for example. The graphics mode and display configuration in use may also be a contributing factor. Using the H.264 video codec would perform a lot better than the lossless codec, just like a session on a 1080p display would be much better than on a 4K display.