Mozilla Still Isn't Ready To Enable OpenGL By Default In Firefox For Linux

[grok]

I suspect window managers quite often support client side decorations. e.g. Mate did a few years back, with gnome 3 apps as well as Chromium's option. I wonder if recent Openbox does, seems not hard just don't draw title bar and catch minimize etc. actions.
Many systems may have gnome-disks installed, you might try it (or the openstreetmap client e.g.)

[Charlie68]

Can you post a screenshot please?

I put the chrome / mium screenshot

[M@GOid]

Can you post a screenshot please?

Strange, after 5 min searching on Google I cannot find a good screenshot of Chromium running on KDE 5 with their tab over window decoration. Looks like few people know or bother in doing it.

Anyway, a guy already posted a screenshot above.

[Zan Lynx]

Nice trolling.

desktop environments are unrelated to rendering.

Yes they are. The desktop is running the compositor which is using OpenGL. Depending on the resources and rendering modes used it can change the results of a windowed OpenGL application.

[starshipeleven]

Yes they are. The desktop is running the compositor which is using OpenGL. Depending on the resources and rendering modes used it can change the results of a windowed OpenGL application.

No, the DE only renders the window decorations (if you are using server-side windows decorations like KDE, GNOME's are client-side so rendered by the application).
Most applications render their own window by calling OpenGL (or 2D acceleration) on their own, then send the rendered frame to the compositor that only splices it with other windows to create a full desktop frame.
This is what happens on Xorg currently (and Xorg can and does add its own quirks and crap), and what happens with Wayland compositors.

There may be some simple applications that use DE libraries fully and don't do anything by themselves (especially on KDE) but this is not the case for Firefox or even Chrome, or any half-serious large multiplatform application.

Or even games. A game (any application) can ask to bypass the compositor and run alone full-screen.

[Zan Lynx]

No, the DE only renders the window decorations (if you are using server-side windows decorations like KDE, GNOME's are client-side so rendered by the application).
Most applications render their own window by calling OpenGL (or 2D acceleration) on their own, then send the rendered frame to the compositor that only splices it with other windows to create a full desktop frame.
This is what happens on Xorg currently (and Xorg can and does add its own quirks and crap), and what happens with Wayland compositors.

There may be some simple applications that use DE libraries fully and don't do anything by themselves (especially on KDE) but this is not the case for Firefox or even Chrome, or any half-serious large multiplatform application.

Or even games. A game (any application) can ask to bypass the compositor and run alone full-screen.

I explicitly said "windowed OpenGL" because, yes, if it has exclusive full-screen access then the compositor should have got out of the way.

For a very basic example of what I mean, consider what happens to that windowed OpenGL application if the desktop compositor has taken ALL the graphics RAM in order to hold screen buffers for 87 4K terminal windows.

[starshipeleven]

I explicitly said "windowed OpenGL" because, yes, if it has exclusive full-screen access then the compositor should have got out of the way.

Still does not change my main point (most of my post, you know, not just the last line of it when I talked about fullscreen stuff).

Each window is still rendered by the application, not by the compositor. Xorg stopped being a true "display server" (i.e. doing all the rendering for applications) eons ago. Now it is basically a compositor (i.e. taking rendered windows from applications and generating a single desktop frame) with tons of legacy crap interfering in its operation.

For a very basic example of what I mean, consider what happens to that windowed OpenGL application if the desktop compositor has taken ALL the graphics RAM in order to hold screen buffers for 87 4K terminal windows.

That's a very abnormal situation, it's pretty much a deliberate DoS (denial of service), which can be done by anything, really.

And still does not change my main point above. Applications render their own windows, THEN send the frame to the compositor.

Here the issue is in FF (the application) having issues dealing with OpenGL providers, so with Mesa/drivers.

Compositors are just one of the applications that may use OpenGL.

[shmerl]

I put the chrome / mium screenshot

I see, thanks. Looks like rather bloated title bar to me. Personally, I'd prefer either no title bar, or normal title bar.

[edgar444]

Any information on when firefox will drop the title bar on linux? I mean that one with "minimize, maximize, close" and also shows domain name.
On Windows and Mac its already like like, it's integrated where you see the tabs. Chrome is using that style for a long time already on linux.

It's just annoying. Nearly 100 wasted vertical pixels ...

Actually I have the exact opposite problem, where it used to be implemented by WM, now it's integrated within app. I'm AwesomeWM user, and least amount of UI aka minimalistic UI is my goal, and apps that *force* needles title-bars, my own subjective opinion ;-), just trigger me. Where as WM implementing it means I get to have a choice, whether I want it or not. I like efficient screen-space.

[edgar444]

By the way, really cool trick only available on chrome.

Go into fullscreen mode (F11), then leave fullscreen mode (AwesomeWM - Meta+F), and you got a chrome window without UI! I beg and hope chrome developers never fix that, it's a great feature, that I'm sad I don't have on firefox...