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?
in-monitor hardware cursor?
Re: in-monitor hardware cursor?
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?
Steam • GitHub • Stack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
Re: in-monitor hardware cursor?
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).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?
Re: in-monitor hardware cursor?
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.
Re: in-monitor hardware cursor?
depends... afaik what you're saying is sort of how the mouse cursor is drawn in windows when you have graphics drivers installed.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.
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
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)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?
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
- Chief Blur Buster
- Site Admin
- Posts: 11653
- Joined: 05 Dec 2013, 15:44
- Location: Toronto / Hamilton, Ontario, Canada
- Contact:
Re: in-monitor hardware cursor?
<GEEK-TALK>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.
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>
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter
Forum Rules wrote: 1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
2. Please report rule violations If you see a post that violates forum rules, then report the post.
3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!