Login animation eats 100% CPU and produces lag

  • Using chromium that does not happen. Looks like it is not possible to disable the animation in OMV :(


    Not sure if OMV or firefox is to blame. I can reproduce the issue on different maschines.


    I dont know of any other website for which that happens, so I suppose OMV at least could be improved here.


    OMV Version: 6.0.10-1 (Shaitan)

    Firefox Version: 91.6.0esr (64-bit)

    OS: Debian 12 bookworm (testing)


    On slow maschines, entering user/pw is hardly possible during the animation.


    Does that happen only to me ? Any ideas would be welcome !


    Edit: As well happens for chromium ... though chromium balances the load on two separate processes and keeps beeing responsive.

  • votdev

    Hat das Label OMV 6.x (RC1) hinzugefügt.
    • Offizieller Beitrag

    I dont know of any other website for which that happens, so I suppose OMV at least could be improved here.


    OMV Version: 6.0.10-1 (Shaitan)

    Upgrade to the latest OMV version (6.0.15). It will be limited to 5 animation cycles. Don't forget the ctrl-shift-R.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    Upgrade to the latest OMV version (6.0.15). It will be limited to 5 animation cycles. Don't forget the ctrl-shift-R.

    This.


    I just tested on FF, and it hovered right around 25% when the animation was running. After 5x, it was done.


    When I checked Chrome.. I closed everything but Chrome and xfce terminal.. top did show it spiking my CPU (like 200%) but everything was running fine.. i could open other tabs without issue, opened thunar w/o issue, even opened Firefox and it fired right up... so that has to be a reporting error somehow.. but after 5 animations it dropped to like 4%

  • Thank you for helping !


    Upgraded to 6.0.15-1, rebootet the omv server, cleared the firefox cache, pressed ctrl-shift-R., but still >100% CPU and lag for > 1minute here with firefox.


    I "think" I can now type the user/pw a bit more fluent, though in firefox.


    Just took another try with chromium, and found out that it actually as well eats 100% CPU, but divided into two processes. However unlike firefox, it keps beeing responsive.


    Suppose you need some old CPU/GPU, like mine, to fully reproduce the problem ;)

    • Offizieller Beitrag

    What CPU/GPU are you using? I'm using a almost 11yr old Celeron (just using the onboard GPU, intel something or other).

  • What CPU/GPU are you using? I'm using a almost 11yr old Celeron (just using the onboard GPU, intel something or other).

    Hmm, than it seems to be something else. I can now reproduce on 3 different systems:


    1. Debian 12 (bookworm), AMD Phenom II X4 955, / GeForce GT 710 (~12 years old)
    2. MXLinux 21, AMD E2-2000 with onboard GPU (~9 years old)
    3. Debian 11 (bullseye), Acer Travelmate 5742Z with 2 Ghz Pentium (P6200) and onboard graphics (~10 years old)

    The lag in Firefox interestingly does not happen on the MXLinux machine (maybe firefox vs firefoxESR)... though it still shows 100% CPU for some time (until the animiation was shown 5 times .. which takes something like 1 minute)


    Imho a checkbox to toggle the animtaion on/off would be great ... I can imagine that such effects anyhow are not welcome by everybody. Should I open an issue ?

    • Offizieller Beitrag

    Imho a checkbox to toggle the animtaion on/off would be great ... I can imagine that such effects anyhow are not welcome by everybody. Should I open an issue ?

    Probably not, as this has been discussed multiple times. It used to run continuously.. but then he capped it at 5. I have another newer laptop (correction I was thinking of my server itself, the one earlier is about a 5yr old celeron)... All you can do is try however, if you think it's something that needs suggested.


    On my i5 laptop (i5-1035G1.. almost 3yrs old).. it is hitting about 18% on Firefox, and Chrome is still showing 175-180% despite no noticeable slowdown on the laptop. Not really sure what is going on there.

  • alexxcons

    Hat den Titel des Themas von „Login animation eats 100% CPU on Firefox“ zu „Login animation eats 100% CPU and produces lag“ geändert.
  • I think the problem is not OMV because this is only a simple CSS animation/transition; i see the problem in the browser or the hardware of the client that does not support hardware acceleration which is considered standard today.

    Well, it happens on 3 different systems, all using hardware accel (youtube is regulary used by my kids) and it does not happen with any other website I regulary use. If my hardware can play youtube with 1024p while keeping respinsiveness, imo the hardware should be pretty much able to show such small animation without lag.


    Maybe the design of the web-frontend somewhat is the problem ... I dont know. In any way, meanwhile I am pretty sure that OMV is to blame here.

    • Offizieller Beitrag

    This isn't a bug. The login screen is doing animation and shifting a good size image.


    The Phenom X4 system with an nvidia card shouldn't have this problem. I blame the very old version of Debian 8 and kernel and probably firefox-esr. I would be curious to see how it would perform with a new kernel (giving you a much newer nouveau driver) and the latest firefox.


    The AMD e2-2000 is slower than an RPi3 probably since the RPi doesn't have this issue. Probably not much that will help this system.


    The Pentium running debian 7 is just ridiculously old. You need to update to a supported version of Debian. I have a very old Dell 2 core celeron laptop that runs Xubuntu 20.04 well and doesn't have an issue with the OMV 6 login screen.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Sorry, but I think you dont get my point. My point is, with all 3 systems I can visit hundreds of webpages without having any issue. But when I visit the page of my omv server, the CPU goes 100% for a minute on 3 different systems. That has a very bad smell to me.


    > . I blame the very old version of Debian 8 ...


    Sorry, I confused the debian version numbers. I am using Debian 12 (bookworm, testing) on the Phenom II and Debian 11 (Bullseye, stable) on the Travelmate ... I will fix all my postings accordingly. Sorry for the fuzz.

  • The animation is, as votedev already mentioned, simple css animation. On css animations there are some basic rules what should be avoided in order to prevent performance issues and what is ok. Checking the code in question you can find only animations are being used that browsers can execute very cheaply (position transform, scale transform, opacity) as long as there is hardware-acceleration. I was just wondering if this may be about using 10yo hardware? Maybe, but: Here you can find an article from 2013 where these css animation types are already stated to enable smooth high performance animations. So you're not dealing with the latest state-of-the-art-stuff here.


    I think your old hardware or some misconfiguration could be the issue. But this is clearly not a bug. Maybe some browser extension like this one can help you.

  • Zitat

    you can find only animations are being used that browsers can execute very cheaply (position transform, scale transform, opacity) as long as there is hardware-acceleration.


    So you want to make hardware accel a requirement for using the omv-webgui ? (Actually I am using a GPU .. though maybe as well that GPU is too old for a 100s animation ? What about smartphones, or other weak devices ?).


    From the Article you linked:

    Zitat

    Styles that affect pain

    ..., background-position, background-image, ...


    If you animate any of the above properties the element(s) affected are repainted, and the layers they belong to are uploaded to the GPU. On mobile devices this is particularly expensive because CPUs are significantly less powerful than their desktop counterparts, meaning that the painting work takes longer;


    Possibly your article already points at the problem in the omv code ... probably better to dont put an animation on the background-image, but rather put the image into some div, and do the animation there to prevent excessive repaints.


    Zitat

    I think your old hardware or some misconfiguration could be the issue. But this is clearly not a bug. Maybe some browser extension like this one can help you.


    Well, so far websites I visit dont do heavy (100seconds !) anymations, with the omv site as an exception. Though I might need to go that way, if more websites decide to show cosy animations and other resource-hungry bloat, instead of just showing me the content.

    • Offizieller Beitrag

    Sorry, but I think you dont get my point. My point is, with all 3 systems I can visit hundreds of webpages without having any issue. But when I visit the page of my omv server, the CPU goes 100% for a minute on 3 different systems. That has a very bad smell to me.

    I do get your point. I have had issues with the animation being ultra slow over a bad RDP connection. The difference is that I just login and forget about instead of getting seemingly angry about it and criticizes a dev's choice.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Possibly your article already points at the problem in the omv code ... probably better to dont put an animation on the background-image, but rather put the image into some div, and do the animation there to prevent excessive repaints.

    Dude, look at the code. The css property background-image is not being animated here. The image is animated using the property transform. votdev has literally applied all the stuff that is mentioned to avoid performance issues. How would you not get that? You are on the wrong track. You are totally confused. Animating a background image does not necessarily mean animating the css property background-image...


    Zitat

    So you want to make hardware accel a requirement for using the omv-webgui ?

    No, I don't wanna make any requirements. I just try to inform you about the very basics of css animations and their requirements. You can discuss that with votdev. He writes this software in his free-time and you are free to use it or to use something else if you don't like it. Or just fork it and make your changes :)

  • Dude, look at the code. The css property background-image is not being animated here. The image is animated using the property transform. votdev has literally applied all the stuff that is mentioned to avoid performance issues. How would you not get that? You are on the wrong track. You are totally confused. Animating a background image does not necessarily mean animating the css property background-image...

    If you know how to solve it, why not provide a PR?

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!