Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Fakefullscreen: some youtube not scaling properly to the window #89

Open
misterhackerman opened this issue Feb 1, 2025 · 12 comments

Comments

@misterhackerman
Copy link

misterhackerman commented Feb 1, 2025

How to reproduce:

  1. open chrome
  2. youtube
  3. and while in tiled mode make the video fullscreen ( it will be cut-off)
    Like this:
    Image

expected behavior:
for the video to be scaled properly to the window

workaround:
any update to dwm fixes this, like for example increasing the master stack number, or toggling dwm fullscreen.
Here is a video of the problem.

01Feb03.00.57.am.mp4

What i think is going on
I have no idea.

I use the following patches

  • changeScheme.me
  • dwm-ewmhtags-6.2.diff
  • dwm-fullgaps-6.4.diff
  • dwm-hide_vacant_tags-6.4.diff
  • dwm-movestack-20211115-a786211.diff
  • fakefullscreen.diff
  • focusonnetactive.diff
  • fullscreen.diff
  • uselessgap-modified_by_me.diff

& thanks a lot for all your work.
it also happens for the browser itself,

  1. open the browser.
  2. press f11
    -> the screen will be cut off
@bakkeby
Copy link
Owner

bakkeby commented Feb 1, 2025

I think this is one that is fairly straightforward to answer.

You are using a browser and you press F11 to make it go into fullscreen. It doesn't matter which browser you are using as they all pretty much behave the same way in this context.

When the browser goes into fullscreen it naturally assumes that the entirety of the screen will be at its disposal; it works like that in Gnome and KDE after all. As such the fullscreen rendering in the browser is scaled according to the size of the screen.

The main thing that the fakefullscreen patch does is to remove the lines of code that resizes the window when it goes into, and out of, fullscreen - as such allowing the window to remain tiled while the content goes into fullscreen.

The reason why the issue corrects itself when you change mfact or do any other update is that it will trigger a resize call which will ultimately send a message to the browser window saying that "hey, the window size has changed, you'd better update your content".

I believe that we addressed issues like this in the fullscreen-compilation patch, but in the case of a plain fakefullscreen patch I think that this would be corrected by adding a call to resizeclient at the end of the setfullscreen function:

resizeclient(c, c->x, c->y, c->w, c->h);

Semi-related; if you mainly use fake fullscreen in the context of browser windows playing YouTube videos for example then you don't actually need the patch for dwm.

A better experience, imho of course, is to use the "app" or "kiosk" mode of the browser. This is where the browser opens a URL in kiosk mode which means that it opens a standalone window that is fullscreen (i.e. no bar, tabs or buttons) and it behaves like fake fullscreen does. So I can have simple scripts such that I open dmenu and start "youtube" and it will open a dedicated fake-fullscreen browser window on the YouTube home page. I can show you how I have that set up if you are interested.

@misterhackerman
Copy link
Author

I have added the line, recompiled and It worked like a charm, thanks you brother. you are amazing.

@misterhackerman
Copy link
Author

misterhackerman commented Feb 1, 2025

After I added the line, i noticed a weird behaviour, the window size gets smaller each time i toggle app fullscreen
video:

02Feb01.05.07.am.mp4

the window becomes smaller each time i full screen.
I'm sorry I don't understand the internals of dwm. trying to read and learn...

@bakkeby
Copy link
Owner

bakkeby commented Feb 2, 2025

Ah, I think that the width and height passed to resizeclient are expected to include the window border as well.

So something like:

resizeclient(c, c->x, c->y, WIDTH(c), HEIGHT(c));

or

resizeclient(c, c->x, c->y, c->w + 2 * c->w, c->h + 2 * c->bw);

@misterhackerman
Copy link
Author

I think you meant
resizeclient(c, c->x, c->y, c->w + 2 * c->bw, c->h + 2 * c->bw);
i tried this, and the one you have written, none of those worked, each with a weird behavior, e.g. this one, the left top gets towards the middle faster than the right bottom corner when i toggle fullscreen on and off.

@misterhackerman
Copy link
Author

I think it also wants the gapps, i don't know the pointers -> something for them? :/ I'm new to C

@misterhackerman
Copy link
Author

#define WIDTH(X)                ((X)->w + 2 * (X)->bw + gappx)
#define HEIGHT(X)               ((X)->h + 2 * (X)->bw + gappx)
	resizeclient(c, c->x, c->y, WIDTH(c), HEIGHT(c)); <-- i have no idea why this isn't working?

@bakkeby
Copy link
Owner

bakkeby commented Feb 2, 2025

It may very well be that the gaps are interfering. These kind of issues are also typical with the noborder patch.

Looking at the fakefullscreen patch:
https://dwm.suckless.org/patches/fakefullscreen/dwm-fakefullscreen-20170508-ceac8c9.diff

we have that the original code did have a resizeclient call when exiting fullscreen. It was also accompanied by an arrange for good measure.

If you have your build available somewhere then I can have a closer look.

@misterhackerman
Copy link
Author

misterhackerman commented Feb 2, 2025

It worked finally:

resizeclient(c, c->x, c->y, c->w - gappx, c->h - gappx);
arrange(c->mon);

Edit: Actually this fixed it:

arrange(c->mon)

Does this approach have any downsides?

@bakkeby
Copy link
Owner

bakkeby commented Feb 2, 2025

Having an arrange call in there shouldn't have any downsides that I can think of.

But I am thinking that if the uselessgap patch is indeed interfering then it may result in other subtle bugs. It sounds like the gap adjustment for the client ends up being stored in c->w and c->h, which is probably something that may be best avoided.

Worth noting that resizeclient calls XConfigureWindow with the new size and position, then it calls configure to send an event to the window informing it of the new size and position. In practice if we make adjustments in resizeclient then we want to ensure that the same adjustments are sent in the configure function.

@misterhackerman
Copy link
Author

exactly, so is useless gaps bugged?

@bakkeby
Copy link
Owner

bakkeby commented Feb 4, 2025

Having looked at the uselessgap patch(es) I am inclined to say yes.

I think for the most part that patch alone will not cause a lot of issues, but there are a few patches that call resize or resizeclient this way.

Another minor side effect the patch may have is that the gaps are applied after size hints have been accounted for, so when the gaps are applied the window may have a size that does not adhere to the desired size hints. Highly unlikely to make a difference in practice given that most people will be setting the resizehints config to 0 anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants