> by the way, hz should have nothing to do with it since i'm
> using cinap's technique of a mouse process that redraws the
> cursor when asked, or every 20ms, whichever comes first
This might as well explain the fact 9atom users don't experience the
problem: local cursor is redrawn sooner than bit
> i think the assertion that memload "loads directly to the screen" is not
> correct.
> at least to my walking through memload.
i read wrong. i think this may fix the issue in a systemic, but not
entirely satisfying way. it does seem rather optimistic that we can
just scribble on the screen.
On Tue May 7 14:51:13 EDT 2013, yari...@gmail.com wrote:
>
> > 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 s
> 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: swcursoravo
> I use 9atom on the pi daily and vncv often a d have never observed this
> behavior.
does 9atom uses a higher HZ setting which could make swcursor be drawn sooner?
> i am using the memdraw from p9p which fixes a number of
> bad drawing cases. (no more blue pngs.) and i don't use
> vnc, so it's hard for me to replicate.
I use 9atom on the pi daily and vncv often a d have never observed this
behavior.
> This problem happens in 386 too (I mean the original
> problem this patch is addressing or tries to address).
the problem is still in the kernel. hacking around it in
vnc won't fix the problem for other programs. hwdraw
should behave the same for either, so something in
the kernel should be c
On Tue, May 7, 2013 at 4:10 PM, erik quanstrom wrote:
> On Tue May 7 05:03:57 EDT 2013, yari...@gmail.com wrote:
> > When using vncv on a terminal with software cursor (vesa, rpi) the
> > mouse cursor leaves a trail. This seem to be caused by the fact that
> > vncv loads picture updates with loa
On Tue May 7 05:03:57 EDT 2013, yari...@gmail.com wrote:
> When using vncv on a terminal with software cursor (vesa, rpi) the
> mouse cursor leaves a trail. This seem to be caused by the fact that
> vncv loads picture updates with loadimage(2) directly to screen.
> Loading to an offscreen image f
> Submitted as /n/sources/patch/vncv-curtrail
It's been long overdue! Thank you.
++L
When using vncv on a terminal with software cursor (vesa, rpi) the
mouse cursor leaves a trail. This seem to be caused by the fact that
vncv loads picture updates with loadimage(2) directly to screen.
Loading to an offscreen image followed by a draw(2) to screen removes
the artifact:
/n/dump/2013
11 matches
Mail list logo
