mondoshawan

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. :(