Blur Busters Forums

When you have a game with a mouse cursor, the cursor isn't rendered in the framebuffer, it's added in after the fact, in order to minimize input latency. So I heard someone talk about mouse precision with g-sync and couldn't really think of a reason Nvidia couldn't move the hardware cursor into the next version of g-sync module. That way you could have the mouse updated however fast the panel can manage(anywhere up to 1khz would make sense, as that's the limit of most gaming mice), with the underlying picture updated as quickly as it can be rendered and pushed across displayport.

Is there something that makes this impractical?

I don't get it. How's the monitor supposed to display a mouse cursor without displaying it? If the monitor refreshes at 30Hz, how's the cursor going to be updated faster than that?

RealNC wrote:I don't get it. How's the monitor supposed to display a mouse cursor without displaying it? If the monitor refreshes at 30Hz, how's the cursor going to be updated faster than that?

You don't have to overwrite the entire display at once, just the pixels that the cursor is now covering or revealing. The main image sent by the GPU wouldn't have a cursor on it, the cursor position and bitmap information would be sent separately(displayport supports secondary data packets).

The idea makes sense, though current LCD panels probably couldn't take advantage because AFAIK they don't allow partial updates, only transferring the entire frame to the matrix. So the only difference would be that there wasn't activity on the PC-to-monitor cable, just on the board-to-panel cable.

Sparky wrote:When you have a game with a mouse cursor, the cursor isn't rendered in the framebuffer, it's added in after the fact, in order to minimize input latency.

depends... afaik what you're saying is sort of how the mouse cursor is drawn in windows when you have graphics drivers installed.
and x.org for *nix when "HWcursor" is on in xorg.conf (i think it is by default though)

many games draw their own cursors though

So I heard someone talk about mouse precision with g-sync and couldn't really think of a reason Nvidia couldn't move the hardware cursor into the next version of g-sync module. That way you could have the mouse updated however fast the panel can manage(anywhere up to 1khz would make sense, as that's the limit of most gaming mice), with the underlying picture updated as quickly as it can be rendered and pushed across displayport.

Is there something that makes this impractical?

this would be nice because in the current situation for the windows cursor, the position is only updated at the start of a refresh cycle. this is why you never see the cursor tear, and this means that at the bottom of your screen the windows cursor movement is delayed by almost an entire refresh cycle. i'm not familiar enough with the graphics card pipeline to see any complications in this idea (independent cursor and game drawing)

but i do know that for any game that runs at decent fps (>100), having it draw its own cursor is good enough in most cases

flood wrote:this would be nice because in the current situation for the windows cursor, the position is only updated at the start of a refresh cycle.

<GEEK-TALK>
Depends. Sometimes the mouse cursor is a hardware sprite (it has been before, in some "Windows accelerators"). If it's a hardware sprite, it could technically be the most recently updated position right before the raster hit the cursor position. Basically, the most recent mouse cursor position update for that particular raster scanline being scanned. These always felt low latency. Back in those days, mouse cursor positions could change (and be made visible to eye) long after the refresh cycle had already started, and the mouse cursor would visibly show up at its newer position, provided it hadn't yet been scanned out, because it took a finite time for the refresh to scan(refresh) the display downwards to the cursor's veritcal position. (You Atari 2600 programmers & Commodore 64 "raster interrupt" programmers would understand this 100%)

This could theoretically be done similiarly for in-monitor mouse cursors, if the position updates are transmitted to the monitor continually in a side channel (or embedded data in the horizontal sync interval, etc).

Hardware cursors CAN be lower latency, and hardware cursor HAS been done before (via the graphics card, not monitor), though it depends on how it's done.

Modern graphics architectures pipeline/abstract things so much that it's really hard or impossible to do old-style software-commanded hardware raster graphics operations (of yesteryear that used to be common from Atari, Nintendo, Commodore 64, Amiga, etc), with the modern graphics drawing pipeline adding latency to our hardware mouse cursors.

Also, an optimal graphics card mouse cursor isn't necessarily any more latency than an optical monitor-generated mouse cursor. But given the way graphics cards are so highly abstracted, transmitting mouse cursor positions continually via a sidechannel or horizontal sync interval, can theoretically produce lower latency in mouse cursors, at least to a similiar level of latency back in the days where we had more direct control over the rasters.

Also on GSYNC, mouse cursors would not necessarily refresh more frequently, unless the monitor executed continual re-refreshes while waiting for the next refresh cycle (re-refreshes don't occur until running less than 30fps/30Hz). So even with a monitor hardware mouse cursor on a GSYNC monitor, the cursor may still run very choppy at lower frame rates.
</GEEK-TALK>