* rio: resize flash patch
@ 2020-11-22 4:36 Amavect
2020-11-22 5:33 ` [9front] " ori
2020-11-23 21:16 ` Ethan Gardener
0 siblings, 2 replies; 28+ messages in thread
From: Amavect @ 2020-11-22 4:36 UTC (permalink / raw)
To: 9front
[-- 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;
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [9front] rio: resize flash patch
2020-11-22 4:36 rio: resize flash patch Amavect
@ 2020-11-22 5:33 ` ori
2020-11-22 6:18 ` Amavect
` (2 more replies)
2020-11-23 21:16 ` Ethan Gardener
1 sibling, 3 replies; 28+ messages in thread
From: ori @ 2020-11-22 5:33 UTC (permalink / raw)
To: amavect, 9front
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?
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [9front] rio: resize flash patch
2020-11-22 5:33 ` [9front] " ori
@ 2020-11-22 6:18 ` Amavect
2020-11-22 10:33 ` hiro
2020-11-22 16:57 ` cinap_lenrek
2020-11-22 20:40 ` hiro
2 siblings, 1 reply; 28+ messages in thread
From: Amavect @ 2020-11-22 6:18 UTC (permalink / raw)
To: ori, 9front
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [9front] rio: resize flash patch
2020-11-22 5:33 ` [9front] " ori
2020-11-22 6:18 ` Amavect
@ 2020-11-22 16:57 ` cinap_lenrek
2020-11-22 17:10 ` Amavect
2020-11-22 17:14 ` ori
2020-11-22 20:40 ` hiro
2 siblings, 2 replies; 28+ messages in thread
From: cinap_lenrek @ 2020-11-22 16:57 UTC (permalink / raw)
To: 9front
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [9front] rio: resize flash patch
2020-11-22 16:57 ` cinap_lenrek
@ 2020-11-22 17:10 ` Amavect
2020-11-24 23:35 ` ori
2020-11-22 17:14 ` ori
1 sibling, 1 reply; 28+ messages in thread
From: Amavect @ 2020-11-22 17:10 UTC (permalink / raw)
To: 9front
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [9front] rio: resize flash patch
2020-11-22 17:10 ` Amavect
@ 2020-11-24 23:35 ` ori
2020-11-25 0:21 ` Amavect
0 siblings, 1 reply; 28+ messages in thread
From: ori @ 2020-11-24 23:35 UTC (permalink / raw)
To: amavect, 9front
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [9front] rio: resize flash patch
2020-11-24 23:35 ` ori
@ 2020-11-25 0:21 ` Amavect
2020-11-25 9:38 ` hiro
2020-11-25 12:34 ` Ethan Gardener
0 siblings, 2 replies; 28+ messages in thread
From: Amavect @ 2020-11-25 0:21 UTC (permalink / raw)
To: ori, 9front
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [9front] rio: resize flash patch
2020-11-25 0:21 ` Amavect
@ 2020-11-25 9:38 ` hiro
2020-11-25 12:34 ` Ethan Gardener
1 sibling, 0 replies; 28+ messages in thread
From: hiro @ 2020-11-25 9:38 UTC (permalink / raw)
To: 9front
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [9front] rio: resize flash patch
2020-11-25 0:21 ` Amavect
2020-11-25 9:38 ` hiro
@ 2020-11-25 12:34 ` Ethan Gardener
[not found] ` <379baa18-a67f-de65-98b5-d7e08cbb5101@gmail.com>
1 sibling, 1 reply; 28+ messages in thread
From: Ethan Gardener @ 2020-11-25 12:34 UTC (permalink / raw)
To: 9front, ori
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [9front] rio: resize flash patch
2020-11-22 16:57 ` cinap_lenrek
2020-11-22 17:10 ` Amavect
@ 2020-11-22 17:14 ` ori
1 sibling, 0 replies; 28+ messages in thread
From: ori @ 2020-11-22 17:14 UTC (permalink / raw)
To: cinap_lenrek, 9front
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [9front] rio: resize flash patch
2020-11-22 5:33 ` [9front] " ori
2020-11-22 6:18 ` Amavect
2020-11-22 16:57 ` cinap_lenrek
@ 2020-11-22 20:40 ` hiro
2020-11-22 21:18 ` ori
2020-12-03 2:17 ` magma698hfsp273p9f
2 siblings, 2 replies; 28+ messages in thread
From: hiro @ 2020-11-22 20:40 UTC (permalink / raw)
To: 9front
> 'cat /dev/mouse' acts a bit funny, for example
funny in which way exactly?
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [9front] rio: resize flash patch
2020-11-22 4:36 rio: resize flash patch Amavect
2020-11-22 5:33 ` [9front] " ori
@ 2020-11-23 21:16 ` Ethan Gardener
2020-11-23 22:06 ` Amavect
1 sibling, 1 reply; 28+ messages in thread
From: Ethan Gardener @ 2020-11-23 21:16 UTC (permalink / raw)
To: 9front
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.)
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [9front] rio: resize flash patch
2020-11-23 21:16 ` Ethan Gardener
@ 2020-11-23 22:06 ` Amavect
2020-11-23 23:17 ` Ethan Gardener
0 siblings, 1 reply; 28+ messages in thread
From: Amavect @ 2020-11-23 22:06 UTC (permalink / raw)
To: 9front
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [9front] rio: resize flash patch
2020-11-23 22:06 ` Amavect
@ 2020-11-23 23:17 ` Ethan Gardener
0 siblings, 0 replies; 28+ messages in thread
From: Ethan Gardener @ 2020-11-23 23:17 UTC (permalink / raw)
To: 9front
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!
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2020-12-03 3:22 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-22 4:36 rio: resize flash patch Amavect
2020-11-22 5:33 ` [9front] " ori
2020-11-22 6:18 ` Amavect
2020-11-22 10:33 ` hiro
2020-11-22 16:57 ` cinap_lenrek
2020-11-22 17:10 ` Amavect
2020-11-24 23:35 ` ori
2020-11-25 0:21 ` Amavect
2020-11-25 9:38 ` hiro
2020-11-25 12:34 ` Ethan Gardener
[not found] ` <379baa18-a67f-de65-98b5-d7e08cbb5101@gmail.com>
[not found] ` <19260358-767b-4746-a3ff-4ce456a646c5@www.fastmail.com>
[not found] ` <CAFSF3XN_vLb89F=CCzXLkiQvYFFHYm72aSbc1NRkPBtDqwPzFA@mail.gmail.com>
2020-11-29 20:55 ` Ethan Gardener
2020-11-29 22:15 ` cinap_lenrek
2020-11-29 22:55 ` Stuart Morrow
2020-11-29 23:35 ` cinap_lenrek
2020-11-30 0:10 ` Stuart Morrow
2020-11-30 0:13 ` Stuart Morrow
2020-11-30 0:21 ` Alex Musolino
2020-11-30 1:48 ` ori
2020-11-30 2:17 ` Stanley Lieber
2020-11-30 9:19 ` hiro
2020-11-30 18:26 ` Ethan Gardener
2020-11-22 17:14 ` ori
2020-11-22 20:40 ` hiro
2020-11-22 21:18 ` ori
2020-12-03 2:17 ` magma698hfsp273p9f
2020-11-23 21:16 ` Ethan Gardener
2020-11-23 22:06 ` Amavect
2020-11-23 23:17 ` Ethan Gardener
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).