Posted
·
Edited by mondoshawan Misunderstood the previous poster's earliest point.
With all due respect - that's not quite how it works.
The framebuffer passes everything to the display - cursor and all - which is then remapped to the display itself, which does it's own thing to render the final view depending on it's inherent capabilites.
Erm, not quite. :j:
The OP actually had it more technically correct -- a hardware cursor is an image overlay added in the near last stage in the rendering pipeline on the card just before the blitting step. The displays connected to your video card do very little aside from use phase-lock-loops to sync to the output display data and turn on and off pixels on the display. True, they do some image modification, depending on the display, but they do flatly nothing with mouse cursors. All the display sees is a stream of bits representing each frame.
The mouselag is not caused by any hardware, it's a rendering effect. It cannot be solved by any hardware, who is going to code that for multiple hardware platforms when there is a nice easy software API?
I don't think the OP was talking about hardware creating this effect -- they know it's caused by rendering a mouse cursor in software routines instead of letting the video hardware take care of it. He's asking that BI implement the use of a hardware cursor instead to get rid of the lag caused by the extra compositing step in software.
The problem can, in fact, be alleviated by using a hardware cursor -- especially since the DirectX APIs actually call for it. See also this MSDN article about the mouse functionality in DX9 and the last line which states that DX9 will use hardware cursors when it can.
Also note the following changelog link which notes that standard Windows GDI calls are used in DX10 and up, which should directly manipulate hardware mouse cursors.
I should also note that the hardware cursor technically is being used insofar as they are disabling it and simply reading mouse events from the xinput event queue or polling for mouse coordinates. This is likely because hardware cursors are less colorful and are generally less attractive than a comparable software cursor.
mouse lag & how it can be fixed for good (not by the users though)
in CARRIER COMMAND: GAEA MISSION - TROUBLESHOOTING
Posted · Edited by mondoshawan
Misunderstood the previous poster's earliest point.
Erm, not quite. :j:
The OP actually had it more technically correct -- a hardware cursor is an image overlay added in the near last stage in the rendering pipeline on the card just before the blitting step. The displays connected to your video card do very little aside from use phase-lock-loops to sync to the output display data and turn on and off pixels on the display. True, they do some image modification, depending on the display, but they do flatly nothing with mouse cursors. All the display sees is a stream of bits representing each frame.
I don't think the OP was talking about hardware creating this effect -- they know it's caused by rendering a mouse cursor in software routines instead of letting the video hardware take care of it. He's asking that BI implement the use of a hardware cursor instead to get rid of the lag caused by the extra compositing step in software.
The problem can, in fact, be alleviated by using a hardware cursor -- especially since the DirectX APIs actually call for it. See also this MSDN article about the mouse functionality in DX9 and the last line which states that DX9 will use hardware cursors when it can.
Also note the following changelog link which notes that standard Windows GDI calls are used in DX10 and up, which should directly manipulate hardware mouse cursors.
I should also note that the hardware cursor technically is being used insofar as they are disabling it and simply reading mouse events from the xinput event queue or polling for mouse coordinates. This is likely because hardware cursors are less colorful and are generally less attractive than a comparable software cursor.
It's still no excuse for usability. :(