WebSite Information > Comments, Suggestions & Questions
os2world website script problem?
Pete:
Hi All
Posted last message too soon as the cpu peaking is back ...
I've tried with 2 newly created, standard - no extensions added, profiles to see if this is profile related and I get similar behaviour.
The cpu peaking with the 2 new profiles seems to be centred on https://www.os2world.com/cms/ as selecting to open a forum post in a new tab then switching to that tab "calms" cpus down - until switching back to https://www.os2world.com/cms/
I've tried to show this with the attached files
home.png - 1st peak shows Seamonkey having just loaded os2world followed by a small (2 second?)gap then continuous peaking
forum.png - switched to a forum topic, cpus not peaking
home_af.png - after closing forum tab, back to cpus peaking
Opening a forum post in a new tab and switching to that tab does not "calm" cpu's in my usual profile, they carry on peaking. So my usual profile may have a problem...
The cpu's peaking with the new profiles after loading os2world homepage should not be a profile problem though.
Could it be a Seamonkey/support dll problem?
@Rich
Yep, it is an oldie
It is Ye Olde Warpcenter cpu meter - I prefer Warpcenter to Xcenter.
Regards
Pete
Dave Yeo:
Hi Pete, try going to about:config and changing layout.frame_rate. Try 1, -1 and large numbers. IIRC, have to restart between changes.
Did you say you are using no-script? Do you have os2world scripting disabled?
Pete:
Hi Dave
Changed layout.frame_rate to 1 and restarted Seamonkey.
Seems to have cured the cpu peaking problem but introduced noticable sluggishness into Seamonkeys response time.
Changed layout.frame_rate to -1, restarted Seamonkey.
No cpu's peaking and Seamonkey seems as responsive as I am used to.
Yes, NoScript in use with options to Allow os2world if needed.
Thanks
Pete
Dave Yeo:
OK, I usually have scripting on OS2World turned off. It does seem like the gif bug. See https://bugzilla.mozilla.org/show_bug.cgi?id=1744499 and, with better examples, https://bugzilla.mozilla.org/show_bug.cgi?id=1793279.
Thing is we don't have the a refresh driver (idea is only draw during refresh cycles) and fake it, which is what that preference is about and why it is much worse on our platform.
The usual workaround for sites that we can control is to change the gifs to pngs. I did that for a bunch of sm/ff theme gifs. Not all gifs cause the problem and it may well be one frame animated gifs or our bug is different. One way to test is to load each gif one by one to see which produces the high CPU load.
The refresh driver was introduced with 45esr.
https://github.com/bitwiseworks/mozilla-os2/issues/208 delayed/choppy response
https://github.com/bitwiseworks/mozilla-os2/issues/277 the gif bug
Lars:
I had written a device driver to sync on the VGA sync signal:
https://github.com/lerdmann/vsync
And here, it has already been discussed:
https://github.com/bitwiseworks/mozilla-os2/issues/220
It reads the VSYNC sync bit from some VGA register and blocks on it to toggle (waits for the beam to return from bottom right to top left, so to say). It is somewhat system friendly in that it will yield the CPU if the yielding flag indicates that there is some other thread waiting to be continued.
1) I have no clue if every graphics card still contains the original VGA register set
2) I have no clue how and where to integrate this into Firefox
If someone could either point me to the place in Firefox where to add this or if someone could build Firefox (of which I also have no clue) then maybe it would be worth giving it a try.
Lars
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version