rio: resize flash patch

rio: resize flash patch

[Amavect]

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

All,

rio: don't redraw the text frame if a client is connected to /dev/mouse

When a window is resized, rio would redraw the text frame first before a 
client program is able to redraw, resulting in a flash.
An if statement masks the redraw.

Thanks,
Amavect

[-- Attachment #2: rio.diff --]
[-- Type: text/plain, Size: 670 bytes --]

diff -r a7cc619b0017 sys/src/cmd/rio/wind.c
--- a/sys/src/cmd/rio/wind.c	Tue Nov 17 18:37:38 2020 -0800
+++ b/sys/src/cmd/rio/wind.c	Sat Nov 21 22:14:39 2020 -0600
@@ -102,12 +102,14 @@
 	wsetcols(w, 1);
 	w->maxtab = maxtab*stringwidth(w->font, "0");
 	r = insetrect(w->i->r, Selborder);
-	draw(w->i, r, cols[BACK], nil, w->entire.min);
-	wfill(w);
-	wsetselect(w, w->q0, w->q1);
-	wscrdraw(w);
 	wborder(w, Selborder);
-	flushimage(display, 1);
+	if(!w->mouseopen){
+		draw(w->i, r, cols[BACK], nil, w->entire.min);
+		wfill(w);
+		wsetselect(w, w->q0, w->q1);
+		wscrdraw(w);
+		flushimage(display, 1);
+	}
 	wsetname(w);
 	w->topped = ++topped;
 	w->resized = TRUE;

Re: [9front] rio: resize flash patch

[ori]

Quoth Amavect <amavect@gmail.com>:
> All,
> 
> rio: don't redraw the text frame if a client is connected to /dev/mouse
> 
> When a window is resized, rio would redraw the text frame first before a 
> client program is able to redraw, resulting in a flash.
> An if statement masks the redraw.
> 
> Thanks,
> Amavect
> 

Nice work -- redraws are definitely a lot smoother here.
I'll take a closer look at the surrounding code, but it
doesn't look like there's too much that can go wrong.

The only question I have is whether there's an edge case
with a program that opens the mouse device without doing
any drawing of its own?

'cat /dev/mouse' acts a bit funny, for example -- does
this matter? Can we fix it?

Re: [9front] rio: resize flash patch

[Amavect]

On 11/21/2020 11:33 PM, ori@eigenstate.org wrote:
> The only question I have is whether there's an edge case
> with a program that opens the mouse device without doing
> any drawing of its own?
> 
> 'cat /dev/mouse' acts a bit funny, for example -- does
> this matter? Can we fix it?
> 

There are already quite a few if statements in rio that use 
Window->mouseopen. /sys/src/cmd/rio/wind.c:/^repaint/ is one of them 
affecting draw routines, but I'm not yet sure how it manifests.
Though I do enjoy printing out /dev/mouse on occasion, I don't think it 
matters very much. As a counterexample, 'cat /dev/kbd' is utterly broken 
as you cannot Delete to freedom. I'm not familiar with any non-gui mouse 
programs.

Having /dev/mouse signal window resize events was never the Right Thing.
/dev/wctl has a very similar output, and even signals on hide and on 
window activation, which may be nice to have. Taking control of a window 
would be opening wctl for reading. That kind of semantic sounds very 
nice. There are many edge cases, though, like winwatch.
Obviously, anything involving wctl would lead to a lot of retooling rio, 
and it would break a lot of things. Food for thought.

Thanks,
Amavect

Re: [9front] rio: resize flash patch

[hiro]

i wonder if synergy and other mouse sharing programs can still work
with this change...

Re: [9front] rio: resize flash patch

[cinap_lenrek]

also imagine what happens when a graphical program outputs
debug prints. or just sysfatal.

i guess you could catch this by disabling that optimization
once the program also writes to the windows cons file after
the mouse file has been opend.

--
cinap

Re: [9front] rio: resize flash patch

[Amavect]

On 11/22/2020 10:57 AM, cinap_lenrek@felloff.net wrote:
> also imagine what happens when a graphical program outputs
> debug prints. or just sysfatal.
> 
> i guess you could catch this by disabling that optimization
> once the program also writes to the windows cons file after
> the mouse file has been opend.
> 
> --
> cinap
> 

Debug prints work just fine (unless you see something I don't).
This patch only affects resizing or moving the window.

Thanks,
Amavect

Re: [9front] rio: resize flash patch

[ori]

Quoth Amavect <amavect@gmail.com>:
> On 11/22/2020 10:57 AM, cinap_lenrek@felloff.net wrote:
> > also imagine what happens when a graphical program outputs
> > debug prints. or just sysfatal.
> > 
> > i guess you could catch this by disabling that optimization
> > once the program also writes to the windows cons file after
> > the mouse file has been opend.
> > 
> > --
> > cinap
> > 
> 
> Debug prints work just fine (unless you see something I don't).
> This patch only affects resizing or moving the window.
> 
> Thanks,
> Amavect
> 

Thinking about this a bit more -- I *think* I'm ok with
documenting that the holder of /dev/mouse is responsible
for refreshing on resize.

If that's not something we want to do, it should also be
possible to write a message to wctl to claim responsibility
for refreshing a window, and making that explicit.

Re: [9front] rio: resize flash patch

[Amavect]

On 11/24/2020 5:35 PM, ori@eigenstate.org wrote:
> Thinking about this a bit more -- I *think* I'm ok with
> documenting that the holder of /dev/mouse is responsible
> for refreshing on resize.
> 
> If that's not something we want to do, it should also be
> possible to write a message to wctl to claim responsibility
> for refreshing a window, and making that explicit.
> 

More accurately, that if /dev/mouse is open, then rio will not refresh 
the window image on resize (except for the border), for the reason that 
/dev/mouse sends resize messages.

I have thought about what the Right Thing should be. Neither mouse nor 
wctl should be related to the act of drawing to the screen. That's 
/dev/draw's responsibility. But rio's design is to not exactly stand 
between the program and /dev/draw, so rio can't know anything.
Maybe this is one reason (among many) why I've never seen a text 
terminal get replaced with a gui program anywhere else...

Thanks,
Amavect

Re: [9front] rio: resize flash patch

[hiro]

did you play with rawon and consctl?

i think that's what it's for, together with keeping /dev/mouse open.
both are described in the rio man page, as it's rio-specific behavior
(unlike /dev/draw, rio actually serves these files).

my tests sadly failed, what i found is that since we are using kbdfs
consctl isn't really usable, not sure how it used to be before.

Re: [9front] rio: resize flash patch

[Ethan Gardener]

On Wed, Nov 25, 2020, at 12:21 AM, Amavect wrote:
> 
> I have thought about what the Right Thing should be. Neither mouse nor 
> wctl should be related to the act of drawing to the screen. That's 
> /dev/draw's responsibility. But rio's design is to not exactly stand 
> between the program and /dev/draw, so rio can't know anything.

Since Rio is responsible for governing the size and position of the windows implemented by the draw device, I have no problem at all with Rio supplying the redraw messages. Since Rio multiplexes the mouse and implements wctl, I think these seem reasonable channels for the messages.

As for which file the resize and reposition messages should be sent over; wctl or mouse, it currently comes over both of them. I'm happy with that. The wctl data is good for scripts which might want to re-run mc. The data over the mouse channel saves mouse-reading programs from having yet another file open. You may recall each open file requires a process under Plan 9.

General thought: designs which "feel right" can be unecessarily inefficient, complex and/or difficult to use. I liked Plan 9 for its pragmatic approach to problems: it doesn't take "this feels right" seriously; it does what works.

Re: [9front] rio: resize flash patch

[Ethan Gardener]

On Sun, Nov 29, 2020, at 7:52 PM, hiro wrote:
> > I'm still a little sore over refusal
> > to implement some very easy things in the area of UI options.
> 
> hmm, care to be more specific? you don't just mean stuff like themes or?

Sure. I mean the refusal to make turbo ultradrive scrolling optional. Also, not adopting an option database was a bit of a disappointment too, but I think I should have put work in there.

Re: [9front] rio: resize flash patch

[cinap_lenrek]

> I mean the refusal to make turbo ultradrive scrolling optional.

what is turbo ultradrive scrolling?

> Also, not adopting an option database was a bit of a disappointment too,
> but I think I should have put work in there.

yes. i do not like themes at all. it adds alot of complexity and once
there, it will ruin peoples lives as they'll making themes all day long.

look at linux window manager theming... its generations of people lost
theming their desktops.

and once rio has themes, EVERY program needs to have themes because of
consistency. and then why stop at colors? margins! fonts! layout!

for rio, i'v put all the color constants in a central data.c file so at
least you can change your colors without producing merge conflicts with
actual important changes.

but i'm not adding a REGISTRY to 9front for this, sorry.

--
cinap

Re: [9front] rio: resize flash patch

[Stuart Morrow]

> what is turbo ultradrive scrolling?

He probably means the giant leaps when you wheel-scroll near the
bottom of the window. With bar scrolling, the fact you use an 'odd'
button is a reminder that something funny is about to happen -
xterm-style scrolling. With the wheel, there's no such warning. I like
it though.

Random observation: I don't know if it's deliberate, but right-click
in the scroll bar to go-to... comports nicely with the fact that
generally everywhere else in Plan 9, right-click means go-to.

Re: [9front] rio: resize flash patch

[cinap_lenrek]

> He probably means the giant leaps when you wheel-scroll near the
> bottom of the window. With bar scrolling, the fact you use an 'odd'
> button is a reminder that something funny is about to happen -
> xterm-style scrolling. With the wheel, there's no such warning. I like
> it though.

Ah! i had no idea.

I'm the wrong one to ask about scroll-wheels as i dont have a hand
mouse on my desk. Wheres the code? Why was it rejected?

--
cinap

Re: [9front] rio: resize flash patch

[Stuart Morrow]

> Wheres the code?

Everywhere except Acme, I think...

> Why was it rejected?

I think you might misunderstand. The behavior is extant. (Assuming I'm
actually correct that that's what turbo scrolling means.)

Re: [9front] rio: resize flash patch

[Stuart Morrow]

'Turbo' technically relates to turbines (turbopump, turboprop), so if
any kind of scrolling is 'turbo' it's fitting that it would be the
wheel

Re: [9front] rio: resize flash patch

[Alex Musolino]

> Everywhere except Acme, I think...

Yeah, it *was* added for a time (changeset d0a53c92a84d) but later removed
because it caused some problems (changeset a43c3e5624da). For what it's worth,
I happen to like the ability to vary the stride of a scroll wheel click.  I'd
like to see this feature in acme.

Are people aware that by holding Shift, the scroll wheel can be made to
scroll only a single line at a time?  Works in rio at least.

Re: [9front] rio: resize flash patch

[ori]

Quoth Alex Musolino <alex@musolino.id.au>:
> 
> Yeah, it *was* added for a time (changeset d0a53c92a84d) but later removed
> because it caused some problems (changeset a43c3e5624da). For what it's worth,
> I happen to like the ability to vary the stride of a scroll wheel click.  I'd
> like to see this feature in acme.

Agreed, I like it too. Also: The distance down the window controls the speed
of scrolling everywhere else.

But I get it -- it's definitely something that threw me off until I realized
what was actually going on. If you don't know what changes scroll speed, having
things scroll half a page at a time sometimes, but only a line at a time at
other times can be disorienting.

Re: [9front] rio: resize flash patch

[Stanley Lieber]

On November 29, 2020 8:48:46 PM EST, ori@eigenstate.org wrote:
>Quoth Alex Musolino <alex@musolino.id.au>:
>> 
>> Yeah, it *was* added for a time (changeset d0a53c92a84d) but later removed
>> because it caused some problems (changeset a43c3e5624da). For what it's worth,
>> I happen to like the ability to vary the stride of a scroll wheel click.  I'd
>> like to see this feature in acme.
>
>Agreed, I like it too. Also: The distance down the window controls the speed
>of scrolling everywhere else.
>
>But I get it -- it's definitely something that threw me off until I realized
>what was actually going on. If you don't know what changes scroll speed, having
>things scroll half a page at a time sometimes, but only a line at a time at
>other times can be disorienting.

galaxy brain scrolling was my idea (although i didn't implement it). it's also in sam and mothtra. i urged for it to br added to acme, and it was, but as alex mentioned, the implementation was broken so it was removed. it works just like clicking at different places in the scrollbar, only it's with the scrollwheel used anywhere. to me, it makes scrolling more intuitive and efficient.

shift+scroll for one line at a time (currently implemented only in rio) was likewise my idea. i think cinap actually implemented that one. i wanted it elsewhere, too, but it's more complicated in other privrams.

coincidentally i'm working on an update to fqa8 that explains all the currently extant scrolling quirks.

sl

Re: [9front] rio: resize flash patch

[hiro]

> But I get it -- it's definitely something that threw me off until I
> realized
> what was actually going on. If you don't know what changes scroll speed,
> having
> things scroll half a page at a time sometimes, but only a line at a time at
> other times can be disorienting.

you know... it's also a parody on samscrolling, so it's working as intended! :P

Re: [9front] rio: resize flash patch

[Ethan Gardener]

So much I could reply to, so much potential for snark... but no. :)

On Mon, Nov 30, 2020, at 1:48 AM, ori@eigenstate.org wrote:
> Quoth Alex Musolino <alex@musolino.id.au>:
> > 
> > Yeah, it *was* added for a time (changeset d0a53c92a84d) but later removed
> > because it caused some problems (changeset a43c3e5624da). For what it's worth,
> > I happen to like the ability to vary the stride of a scroll wheel click.  I'd
> > like to see this feature in acme.
> 
> Agreed, I like it too. Also: The distance down the window controls the speed
> of scrolling everywhere else.
> 
> But I get it -- it's definitely something that threw me off until I realized
> what was actually going on. If you don't know what changes scroll speed, having
> things scroll half a page at a time sometimes, but only a line at a time at
> other times can be disorienting.

This is it, yup. My real problem with it is that when it appeared, my life was a whirlwind of socialisation and creativity. 9front was my tool for organizing everything, chatting, and creating for text-based MUSH games. I didn't have time to begin to consider thinking about trying to adapt to change when 9front changed something I used instinctively all the time.

Rio and Acme were great with MUSH games. I'd connect with Rio in noscroll mode so my reading wouldn't be thrown off by lines of text arriving, and of course scrolling down is a convenient key. In Acme, I'd write and edit room, object, and character descriptions with newlines and tabs They'd be between brackets which I'd double-click to select a whole description, and then middle-drag over a nearby line to encode the tabs and newlines, prepend the change command and object ID, and send the result to /dev/snarf. A middle-click in Rio (which was always on 'send'), and the game would get the change. Easy! Except for the middle-drag. I think it was ssam which made the changes since they needed to be transient. 

I do recall setting up the sam commands was tough, but once they were done they were reusable. A big part of why I didn't fork Acme & Sam after my life settled down was this difficulty I always had with regexps and Sam command language and other languages and even the way they wrote C. I struggled with all of them. I managed to get some skill with regexps by sheer force of effort, and of course the simplicity of the other languages helped, but I'm doing Forth and Plain English Programming now.

Re: [9front] rio: resize flash patch

[umbraticus]

> Specificially, it would make grepping for window names painful if
> not impossible, and complexify winwatch.  It would hurt the ease and
> simplicity with which even new users can write scripts to start
> subrios with custom labels; they could no longer `bind /dev/null
> /dev/winwatch` to preserve their label.

Sounds like you're confusing /dev/win^(name watch) with /dev/label.

umbraticus

Re: [9front] rio: resize flash patch

[Ethan Gardener]

On Sun, Nov 29, 2020, at 10:26 PM, umbraticus@prosimetrum.com wrote:
> > Specificially, it would make grepping for window names painful if
> > not impossible, and complexify winwatch.  It would hurt the ease and
> > simplicity with which even new users can write scripts to start
> > subrios with custom labels; they could no longer `bind /dev/null
> > /dev/winwatch` to preserve their label.
> 
> Sounds like you're confusing /dev/win^(name watch) with /dev/label.
> 
> umbraticus
>

Thanks. winwatch is correct, but winname should indeed be label. I thought there was something odd when I read "winname" in Amavect's post, but assumed he knew what he was talking about on the code side at least.

Re: [9front] rio: resize flash patch

[ori]

Quoth cinap_lenrek@felloff.net:
> also imagine what happens when a graphical program outputs
> debug prints. or just sysfatal.
> 
> i guess you could catch this by disabling that optimization
> once the program also writes to the windows cons file after
> the mouse file has been opend.

I don't think this patch should affect that -- the change is
only in wresise(). Wrepaint() already bails out if mousectl

Re: [9front] rio: resize flash patch

[hiro]

> 'cat /dev/mouse' acts a bit funny, for example

funny in which way exactly?

Re: [9front] rio: resize flash patch

[ori]

Quoth hiro <23hiro@gmail.com>:
> > 'cat /dev/mouse' acts a bit funny, for example
> 
> funny in which way exactly?
> 

It leaves the background in place when you resize the window.

Re: [9front] rio: resize flash patch

[magma698hfsp273p9f]

hiro <23hiro@gmail.com> writes:

>> 'cat /dev/mouse' acts a bit funny, for example
>
> funny in which way exactly?

the cat kills the mouse, but never actually eats it.

Re: [9front] rio: resize flash patch

[Ethan Gardener]

On Sun, Nov 22, 2020, at 4:36 AM, Amavect wrote:
> 
> When a window is resized, rio would redraw the text frame first before a 
> client program is able to redraw, resulting in a flash.

I'm curious, where are you seeing the flash? I remember it from when I first started using Plan 9, but a patch to speed up the vesa driver made it too fast to see. This was all before 9front. I think I've seen it with 9front too, but can't remember where.

(I have no problem with the patch. I always thought the needless redraw a bit of a waste even if it didn't matter to me.)

Re: [9front] rio: resize flash patch

[Amavect]

On 11/23/2020 3:16 PM, Ethan Gardener wrote:
> I'm curious, where are you seeing the flash? I remember it from when I first started using Plan 9, but a patch to speed up the vesa driver made it too fast to see. This was all before 9front. I think I've seen it with 9front too, but can't remember where.
> 
> (I have no problem with the patch. I always thought the needless redraw a bit of a waste even if it didn't matter to me.)
> 

I see it in a drawterm to a local VM. It doesn't show every time I 
resize a program, but it occurs about half the time.
It's much more noticeable in a connection to a remote cpu server.
If you wish to simulate the experience, add a sleep call right after the 
flushimage call.

Thanks,
Amavect

Re: [9front] rio: resize flash patch

[Ethan Gardener]

On Mon, Nov 23, 2020, at 10:06 PM, Amavect wrote:
> On 11/23/2020 3:16 PM, Ethan Gardener wrote:
> > I'm curious, where are you seeing the flash? I remember it from when I first started using Plan 9, but a patch to speed up the vesa driver made it too fast to see. This was all before 9front. I think I've seen it with 9front too, but can't remember where.
> > 
> > (I have no problem with the patch. I always thought the needless redraw a bit of a waste even if it didn't matter to me.)
> > 
> 
> I see it in a drawterm to a local VM. It doesn't show every time I 
> resize a program, but it occurs about half the time.
> It's much more noticeable in a connection to a remote cpu server.
> If you wish to simulate the experience, add a sleep call right after the 
> flushimage call.

Oh yeah, remote would show it. Thanks!