Re: [dev] unsubscribe
:(
Re: [dev] [st] terminal app resizing redraw artifacts
To answer my own question, I seem to have found the issue:
Basically the tclearregion in resize uses whatever is left in
term.c.attr.bg to paint the background. I bet sometimes there are left
over values ( in this case the cursor background is purple/yellow) and
it got painted all over the newly created region. I added the fix
below to clear the bg to default in tresize before the tclearregion()
/* Clearing both screens (it makes dirty all lines) */
term.c.attr.bg = defaultbg;
c = term.c;
for (i = 0; i < 2; i++) {
if (mincol < col && 0 < minrow) {
tclearregion(mincol, 0, col - 1, minrow - 1);
I guess most people don't really care or the redraw is usually fast
enough to hide this. In my case I work on very slow virtual machines
where this issue is exacerbated.
Thanks,
Kai
On Wed, Jun 24, 2020 at 8:55 AM Kai Ting wrote:
>
> Hi,
> By "default background color" do you mean the default ST color? I tried that
> already. I tried the default config.def.h colors and also set ST's background
> to the same color as VIM's background.
>
> Please see attached gifs for a more pronounced example - here vim is busy
> running and the resize somehow picked up the color of the status bar (purple)
> in this case. In the xterm version, you can see the redraw just paints the
> new space with default black background which is much less jarring. I'm
> trying to see where in ST's code is picking up this background color that
> seems to be random part of the original screen. I suspect some clearing
> /resetting is missing before the redraw.
>
> Thanks,
>
> Kai
>
>
>
> On Wed, Jun 24, 2020 at 2:11 AM Ivan Tham wrote:
>>
>> On Tue, Jun 23, 2020 at 10:34:59PM -0700, Kai Ting wrote:
>> >Hello!
>> >
>> >I have been using st for a while trying to transition fully from xterm.
>> >However one issue I couldn't resolve for the life of me is that under dwm
>> >and st, changing the windows size sometimes results in colored flashes
>> >around the window area before the running application redraws the screen.
>> >Apart from resizing windows, fast scroll back/forward also results in very
>> >bright flashes. I cannot reproduce the same issue with xterm. Please see
>> >attached gif capturing this issue using vim 8.2, st 0.8.4 and dwm 6.2.
>> >
>> >Any hints/guidance? I looked at the code briefly (xresize() etc) and don't
>> >see anything obvious that can change such behavior.
>>
>> I believe that may be the color you set on vim or the colors set on st.
>> I never experience these behavior using the default color settings.
>>
>> Most likely is because my background color is black, sometimes if the
>> background colors is not the same as the default background color, the
>> default background color will fill up the extra space.
>>
>> Regards,
>> Ivan Tham
>>
Re: [dev] On how dwm hides windows
Dear Laslo Laslo Hunhold wrote: > On Wed, 24 Jun 2020 14:39:03 +0200 > "Silvan Jegen" wrote: > > Dear Silvan, > > > The first beginnings are here (not by me): > > > > https://github.com/djpohly/dwl > > > > It uses the wlroots[0] wayland compositor library which a lot of > > people may not consider suckless however. I think the decision to use > > this library is sound (as long as you don't want to depend on > > swc[1]/wld for this). You end up replacing ~100K SLOC of X (AFAIR) > > with ~100K SLOC of wlroots. > > it would not be suckless to just write a wrapper around wlroots. Same > applies to just writing a weston-plugin for that purpose. I know that > there's lots of repitition in wayland, but I'm positive there can be a > way to do it on our own. I also feel like there should be a slimmer solution, but since you will want most of the Wayland protocol support that is already implemented in wlroots, I expect a lot of duplicated code in any case. BTW, I just quickly checked and Xorg[0] actually contains more like 500K lines of code according to wc -l $(find . -type f -name '*.c' -o -name '*.h') Not sure how much of that is actually currently still in use of course. Cheers, Silvan [0] https://github.com/freedesktop/xorg-xserver
Re: [dev] On how dwm hides windows
On Wed, 24 Jun 2020 14:39:03 +0200 "Silvan Jegen" wrote: Dear Silvan, > The first beginnings are here (not by me): > > https://github.com/djpohly/dwl > > It uses the wlroots[0] wayland compositor library which a lot of > people may not consider suckless however. I think the decision to use > this library is sound (as long as you don't want to depend on > swc[1]/wld for this). You end up replacing ~100K SLOC of X (AFAIR) > with ~100K SLOC of wlroots. it would not be suckless to just write a wrapper around wlroots. Same applies to just writing a weston-plugin for that purpose. I know that there's lots of repitition in wayland, but I'm positive there can be a way to do it on our own. With best regards Laslo
Re: [dev] On how dwm hides windows
Hi Anselm Garbe wrote: > On Tue, 23 Jun 2020 at 14:48, wrote: > > [...] > > IMO the next evolutionary step of dwm will be considering to migrate > to wayland at some point. X has always been a nightmare. The first beginnings are here (not by me): https://github.com/djpohly/dwl It uses the wlroots[0] wayland compositor library which a lot of people may not consider suckless however. I think the decision to use this library is sound (as long as you don't want to depend on swc[1]/wld for this). You end up replacing ~100K SLOC of X (AFAIR) with ~100K SLOC of wlroots. Cheers, Silvan [0] https://github.com/swaywm/wlroots [1] https://github.com/michaelforney/swc
Re: [dev] On how dwm hides windows
On Tue, 23 Jun 2020 at 14:48, wrote: > I am writing a wm for myself and I have a question about how dwm (and > a lot of other WMs that copies dwm, such as katriawm and berry) hides > clients. > > dwm manage() a client when it receives a MapRequest event and unmanage() > it when it receives both a UnmapNotify or a DestroyNotify event, while > hide clients by moving it to WIDTH(c) * -2. Moving windows off-/on-screen is usually faster for quick view manipulation than unmap/map. It doesn't offer an opportunity for mouse pointer triggered focus/configure events either (I have observed such in the older days as well with pointer warping in areas of unmapped windows). All those reasons might have been bugs in the X server or of some X clients at the time. But I would argue that unmap/map remains slower than moving an unwanted window off-/onscreen. > Well, a window unmapped by a client can be mapped again later until it > be destroyed, so dwm can end up manage()ing a client twice if this > client chooses to unmap and then map again one of its windows. If a client unmaps a window, it has reason to do so and dwm will unmanage such a window, even if it's offscreen (aka not in the current view). > Why doesn't dwm hide windows by unmapping them, ignore UnmapNotify > events, and only manage() a client after a MapRequest event if this > client was not found by wintoclient()? > > I think that hiding a window by unmaping it is a way more obvious > approach than moving it to a invisible place. Is there any reason why > dwm hides windows like that? See above, there were reasons at the time. They might not be valid anymore today, but I think the strategy chosen has had no adverse effects even today. IMO the next evolutionary step of dwm will be considering to migrate to wayland at some point. X has always been a nightmare. Best regards, Anselm
Re: [dev] [st] terminal app resizing redraw artifacts
On Tue, Jun 23, 2020 at 10:34:59PM -0700, Kai Ting wrote: Hello! I have been using st for a while trying to transition fully from xterm. However one issue I couldn't resolve for the life of me is that under dwm and st, changing the windows size sometimes results in colored flashes around the window area before the running application redraws the screen. Apart from resizing windows, fast scroll back/forward also results in very bright flashes. I cannot reproduce the same issue with xterm. Please see attached gif capturing this issue using vim 8.2, st 0.8.4 and dwm 6.2. Any hints/guidance? I looked at the code briefly (xresize() etc) and don't see anything obvious that can change such behavior. I believe that may be the color you set on vim or the colors set on st. I never experience these behavior using the default color settings. Most likely is because my background color is black, sometimes if the background colors is not the same as the default background color, the default background color will fill up the extra space. Regards, Ivan Tham
