mangaupdates Cover Preview

Previews covers in mangaupdates.com when hovering over hyperlinks that lead to serie pages.

< 脚本 mangaupdates Cover Preview 的反馈

评价:好评 - 脚本运行良好

§
发布于:2020-11-20

The latest upgrades (1.6.0 ; 1.6.1 ; 1.6.3) are making everything laggy as soon as I open mangaupdates
(I really love this script tho. It helps a lot. Ty for working at it. But for now, I'll use the downgraded version)

sz作者
§
发布于:2020-11-21
编辑于:2020-11-21

ok. Haven't seen a lag on my system. What browser/userscript extension(tampermonkey/violentmonkey/greasemonkey/...) are you using?
I'll see if i can find out why it could get laggy or what i can further optimize.

Some question to narrow down the most likely code parts.
- Does the lagginess finish after sometime or does it keep being laggy the whole time? (lag during initialisation or some lag that is slowing down the page all the time?)
=> if only during initialisation: maybe will safe the tested init values (css)

- Does it lag on first load of each popup?
- Does it lag on a new image/showing the loading spinner? (First load of seriepage. Lag on getting the serie page?)
=> Maybe userscript browser extension? Installed newest version?
- Does it lag on loading the image? (Lag for loading the cached image?)
=> Maybe making additional cache for each image of seriepage parsed.

sz作者
§
发布于:2020-11-22

Have just put another version up.
- CSS check is only enforced if debugCSSClasses is true.
- loading spinner animation gets removed when popup is hidden.
- possible to switch to alternative eventListenerStyle

Without further details i have to assume that you directly hovered over a link at the load of the page and the image has not finished loading. The Animation was then still running in the background. Otherwise there should be no always running script/animation.

If it is still laggy for you, you could try to change "const eventListenerStyle = 0;" to "const eventListenerStyle = 1;"
This could speed up the start of the script in exchange for a bit slower live check of hovering over serie page links. (possible reason https://gomakethings.com/why-event-delegation-is-a-better-way-to-listen-for-events-in-vanilla-js/#web-performance)

§
发布于:2020-11-22

I forgot to answer the questions. I'm sorry.


I've recorded a video so I could show the problem I'm having.
https://youtu.be/8yEsfbflohU

I'm using chrome with the tampermonkey extension.

sz作者
§
发布于:2020-11-24
编辑于:2020-11-24

Thats weird. I am also testing with chrome and tampermonkey(and firefox/violentmonkey and sometimes opera)
could you test
https://greasyfork.org/de/scripts/416660-mangaupdates-cover-preview-dev-log
and tell me which point the script has reached? (Open Chrome DevTools and take a look at the Console Tab.)
When it has reached "cover preview end" there should be no more running cpu processing from the script if there are no links to serie pages.

- cover preview start
- started main function of coverPreview
- before starting checkDataVersion
- before starting loadStyleSheets
- before starting createPopover
- before starting hidePopOver
- before starting changeToNewDetailStyle
- before starting preloadCoverData
- []
- preloadCoverData
- parseSeriePage for each url with a link to individual seriepage
- before starting prepareEventListener
- finished main function of coverPreview
- cover preview end

I have just installed adblock and have both active and it is running without the cpu spike. But just to be sure that the adblocker is not blocking some loading of the page. Could you temporary deactivate ublock and your adblocker?

I have also tried to find your userscripts that are used on mangaupdates/every page. I haven't found your used version of adguard popupblocker. Can you update it to the newest version? https://github.com/AdguardTeam/PopupBlocker
Currently i have installed release version 2.5.30

§
发布于:2020-11-24

So... I deactivated all of the other scripts on Tampermonkey and all of my extensions (excluding tampermonkey) so I could test the script like that. It still had the same problem.

After doing that, I've realized that I probably should've tested it in another "user" of chrome too (like... my main google account is synced with chrome, so I tried it with my alt).
It actually worked in the alt. I'm sorry about that QWQ
I still don't know what is happening, but I'll try to find out here.
Tyvm for the help and sorry again...

sz作者
§
发布于:2020-11-24

No worry. There are a lot of possible errors that can happen. Everything can be helpful to narrow potential bugs.

While looking at your video i searched for: chrome stuck "processing request"
This is an old thread but may be one possible solution to your problem. Even though it doesn't explain why it has worked with the older version.
Maybe your harddrive has not enough free space?
"My chrome was pinning the CPU at 40% with just 4 tabs opened, sustained (not just during chrome startup,)

After freeing my drive from 900MB to 3G, the sustained CPU usage of Chrome drop instantly to 5% (without relaunch)."
https://support.google.com/chrome/thread/49032533?hl=en

§
发布于:2020-11-25

I've fixed it by creating another user on chrome. I synced my main account. Everything is the same except for the new user, so it pretty much worked out e.e
I just saw your reply, so I couldn't try the method you told me here, but I really appreciate your help anyway.

Tyvm

发布留言

登录以发布留言。