[9fans] rio bug

[9fans] rio bug

[andrey mirtchovski]

if a rio window is being moved while it disappears it'll leave a white
rectangle at the last position it is placed at. to trigger try selecting a
terminal window with the right mouse button and hit ^D, then move it
around and deselect.

i guess a solution would be to add a control message to redraw the
grey, but i can just see someone 'fixing' it to allow random images to
be put as background and it's all downhill from there :)

andrey

Re: [9fans] rio bug

[Russ Cox]

andrey mirtchovski wrote:

>if a rio window is being moved while it disappears it'll leave a white
>rectangle at the last position it is placed at. to trigger try selecting a
>terminal window with the right mouse button and hit ^D, then move it
>around and deselect.
>
>i guess a solution would be to add a control message to redraw the
>grey, but i can just see someone 'fixing' it to allow random images to
>be put as background and it's all downhill from there :)
>  
>

that sounds like a workaround rather than a solution.
the solution is to make the behavior go away completely.

russ

Re: [9fans] rio bug

[rog]

it looks like the problem is a spurious image is being left behind, as
the white rectangle redraws itself (which it wouldn't if it was just
background corruption)

so andrey's workaround wouldn't actually work anyway...

Re: [9fans] rio bug

[andrey mirtchovski]

> that sounds like a workaround rather than a solution.
> the solution is to make the behavior go away completely.
> 
> russ

it is a more serious problem that requires changes deep in Plan 9's
drawing library and we see it all the time without it even bothering
us -- try dragging a window border over something that does draw() in
the meantime and you'll get a leftover red streak from the border.
the solution is to slightly resize the original window causing a new
draw() to refresh it.

yes, it's a workaround.  nobody seems bothered by it enough to solve
the problem though (well, in my case i don't know how, so i'm excused)

oops, looks like my "workaround" won't work anyway, so it's only an
"around" -- back to where we started :)

andrey

Re: [9fans] rio bug

[rog]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

> it is a more serious problem that requires changes deep in Plan 9's
> drawing library and we see it all the time without it even bothering
> us -- try dragging a window border over something that does draw() in
> the meantime and you'll get a leftover red streak from the border.
> the solution is to slightly resize the original window causing a new
> draw() to refresh it.

that's a different problem as far as i'm aware - due to the fact that
rio uses unbuffered windows to draw the borders.

[-- Attachment #2: Type: message/rfc822, Size: 2383 bytes --]

From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] rio bug
Date: Tue, 23 Mar 2004 12:19:30 -0700
Message-ID: <67c9a432fcc5efbb15356107e3a5b658@plan9.ucalgary.ca>


> that sounds like a workaround rather than a solution.
> the solution is to make the behavior go away completely.
> 
> russ

it is a more serious problem that requires changes deep in Plan 9's
drawing library and we see it all the time without it even bothering
us -- try dragging a window border over something that does draw() in
the meantime and you'll get a leftover red streak from the border.
the solution is to slightly resize the original window causing a new
draw() to refresh it.

yes, it's a workaround.  nobody seems bothered by it enough to solve
the problem though (well, in my case i don't know how, so i'm excused)

oops, looks like my "workaround" won't work anyway, so it's only an
"around" -- back to where we started :)

andrey

Re: [9fans] rio bug

[rob pike, esq.]

> that's a different problem as far as i'm aware - due to the fact that
> rio uses unbuffered windows to draw the borders.

not exactly. it's a consequence of the one major change in design between
8½ and rio.  8½ muxed all graphics ops, but rio only works as a true
window manager.  under rio, programs write directly to the screen
through their own connection to /dev/draw.  the border bug is a
consequence of that coupled with my unwillingness to provide a 'grab'
operation to lock out drawing access.

-rob

Re: [9fans] rio bug

[rob pike, esq.]

> i guess a solution would be to add a control message to redraw the
> grey, but i can just see someone 'fixing' it to allow random images to
> be put as background and it's all downhill from there :)

i'd rather just fix the bug.

-rob

Re: [9fans] rio bug

[rog]

sorry, i was talking rubbish.

the bug is nothing to do with unbuffered windows, and is documented in
the rio code:

/*
 * BUG: should interlock so applications don't change screen
 * while tmp[] holds backing store
 */

it's not a problem deep in the drawing code at all - it's just that
rio (well drawgetrect()) is trying to be efficient and drawing the red
borders directly on the screen.

to be honest, it should be quite fast enough if it just allocates new
windows every time it moves the border - that's what i did in the
inferno wm and it works fine, as smooth as you like.

Re: [9fans] rio bug

[rob pike, esq.]

> to be honest, it should be quite fast enough if it just allocates new
> windows every time it moves the border - that's what i did in the
> inferno wm and it works fine, as smooth as you like.

i tried that and the current code is a consequence of my inability
(incompetence?) to get it to work.  horrible lockup problems and
other disasters.  it was also slow, but modern machines are faster.
i believe much of the old code was still in rio.c, commented out,
until fairly recently.

if you think you can make it work, please do.

-rob

Re: [9fans] rio bug

[boyd, rounin]

> i'd rather just fix the bug.

yup

Re: [9fans] rio bug

[Geoff Collyer]

I think there's another bug.  Suppose you "cpu -c rio" and in the
inner rio (the one on the cpu server), create windows and hide one or
more of them.  Then move the inner rio slightly (I dragged the border
a few pixels).  I think that hiding and exposing the inner rio will
also trigger the bug.  The inner rio then redraws its windows but now
it thinks the hidden windows are visible.  If you select Move on
button 3, point the cursor where an invisible window was (but now you
can only see background) and click, you'll see a red border until you
release, then the hidden window will reappear.

Not only that, but if you now click button 3, the hidden window will
still be on the menu and can be selected, at which point it drops off
the menu.

If you often hide windows and have lots of overlap of windows, this
can lead to very mysterious behaviour.

Re: [9fans] rio bug

[rob pike, esq.]

yes, there are two bugs. one isn't worth fixing, one is.
but rog might fix the one not worth fixing, if he thinks
it's worthwhile.

-rob

Re: [9fans] rio bug

[Fco.J.Ballesteros]

> unwillingness to provide a 'grab'
> operation to lock out drawing access.

A grab that is timed out shouldn't be a problem.
At least if nobody but rio uses it.
Or is there something else?

Re: [9fans] rio bug

[matt]

I've often noticed border droppings and other bits of crud left behind

Like Andrey says - does it matter really?

I would say that it's not very professional, if you'd paid someone to write it for you, you'd send it back until it was fixed.

It certainly doesn't affect any ability to work, though now I have an annoying white square on my desktop I can't get rid of !