> the issue, and this fact this fix works must mean that > devdraw(3)'s 'd' command usually doesn't cause (much) > cursor flicker, but the 'y' command does. > > so either there is a timing or locking problem on the pi, > or swcursoravoid(r) is not called for the 'y' command.
Correct: swcursoravoid is called from hwdraw; memdraw (the 'd' case) does call hwdraw, memload (the 'y' case) does not. Other programs avoid the issue because the programs do not load images directly to screen. I guess what happens is the cursor draw scheduled after swcursoravoid saves part of the remote cursor image which is being drawn in meantime. This is yet to be verified. > (and allocating new images might amplify latency.) The potential latency hit could be avoided by pre-allocating an offscreen storage big enough (double-buffering); this would cost more kernel draw memory though. So until latecy suffers in practice the cost doesn't worth paying. Yaroslav
