Closed Bug 167884 Opened 22 years ago Closed 17 years ago

100% CPU load when viewing site [tiling transparent PNG]

Categories

(Core Graveyard :: GFX, defect, P3)

Product:
Core Graveyard
Component:
GFX
Platform:
x86
OS/2
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: boris, Assigned: mkaply)

References

(
URL
)

Details

(Keywords: perf)

Attachments

(1 file)

testcase without any images
4.93 KB, text/html
Details
User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.1) Gecko/20020827 Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.1) Gecko/20020827 100% CPU load when viewing http://www.w3.org/Style/CSS/learning Reproducible: Always Steps to Reproduce: 1. Open Mozilla 2. Point it to http://www.w3.org/Style/CSS/learning 3. Try to scroll page Actual Results: 100% CPU load Expected Results: CPU load must be less
OS: other → OS/2
Confirmed in OS/2 trunk 2002091008. Mike can probably tell why. I suspect a java/JS floating menu.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
Presumably a painting issue dealing with the transparency plus fixed positioning. Don't we have a bug on this already? I'm also seeing 100% CPU load on a very slow Linux box, but I don't think I see that on more current machines.
Assignee: dbaron → kmcclusk
Component: Style System → GFX Compositor
QA Contact: ian → petersen
I believe we are going down our slow tiling path in this case because we don't have code to do alpha blending on tiled PNGs.
Priority: -- → P3
-> dcone
Assignee: kmcclusk → dcone
I fixed problems under windows on this page.. the 8 bit alpha blend for tiled backgrounds on windows. I had to hand blend the alpha to increase the speed. Someone on OS2 needs to write some code that hand blends the 8 bit alpha background. The file that needs to be fixed is gfx/src/os2/nsImageOS2::DrawTile Mike.. I will assign this to you so it can get to the right 0S2 person to fix this. if you need more info.. email, AIM or call me.
Assignee: dcone → mkaply
1.1 (20020826) for Linux Mandrake KDE 3: Top shows 87% user 12% system load when scrolling that URL. In contrast, scrolling this page produces 93% user, 5% system. Either way, not much less crisp than yesterday's w32 trunk on the same machine running W98.
Please up the priority. I'm learning CSS now and would very much like to be able to use the W3 tutorials on my favorite OS. As it now is it is useless.
So this is hurting us also on Win98?
What I wrote in comment 6 means that Linux is OK, just not quite as fast as W98, both in contrast to OS/2, which is unusable.
Looks to me like comment 2 stated the issues. Testcase has no images at all, but OS/2 (K6/2-550) scrolls it terribly slow & glitchy, and pegs CPU trying. W32 (K6/2-550) breezes through it like a hot knife through butter. Linux (K6/2-550) falls between OS/2 and W32, loading the CPU very heavily, but nevertheless scrolling respectably.
I don't see this in the current build. Can anyone verify?
No improvement in my attachment 110088 [details]. Still creepy glitchy slowwww scrolling only in OS/2. Original URL has been redesigned. It now scrolls smoother in OS/2 than in Linux, but not quite as smooth as M$. CPU load is still maxed, but URL is plenty usable., scolls about the same as this bug page. See comment 10 for applicable CPU's.
I'm wagering this is video driver related. Are you using Scitech?
SDD Pro 7.1
The original site is redesigned, so there is no problems with scrolling. Also no problems with the bug's attachmet. If You may point me to apropriate site like old CSS page I will check.
Mike, I tried booting the W32 system in comment 10 to OS/2 FP12 with the native graphics card driver. Performance resembles Linux KDE 3, much better than SDD Pro. Is this purely a problem with SDD Pro? Nowhere else I can think of have I seen better speed from the native driver than from SDD.
Felix, I think you are seeing something other people aren't. Even with your testcase, I get great scrolling on Os/2 and I am using Scitech. I'm not sure what to do.
I've been in discussion with SciTech. Latest response is not encouraging as to possibility that it is something they could do anything about: "So, the page in question performs worse compared to others, using the VBE driver? That indicates the problem is not in the Tseng chipset driver. You could try it with GENGRADD, to compare against our drivers - it's sounding like it's something else..." It has always been my impression that GENGRADD was a generic driver, unlikely to outperform anything.
Here's another URL where scrolling performance is awful: http://my.opera.com/dev/discussion/openweb/20030206/
That site is slow on Windows as well...
No problems with Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.3b) Gecko/20030211, WSeB CP2, 1.2GHz Celeron, SciTech SNAP RC2, Asus 7100 64M
Yes. This site is slow on Windows too, but it's as slow as with IE. Athlon 1.8 Ghz, WinXP, Mozilla 20030414. On scrolling: IE: 56-65% of CPU Mozilla: ~63% of CPU Can we do something with this? (my feelings are similar to comment #2).
cc'ing some gfx people for input
Another page that shows the problem really well: http://www.intraplanar.net/projects/
The issue is tiling of 1x1 transparent PNGs. We don't do good tiling of transparent stuff.
Testing in yesterday's OS/2 trunk and a 3 day old Linux trunk, the original URL and that in comment 24 load right up and scroll reasonably in Linux. In OS/2, the original still scrolls poorly, while 24 pegs CPU for close to 2 minutes just loading, and not much less just to refocus the tab it's in. Comment 19 isn't nearly objectionable at all now, but this TBird standards compliance showcase page http://texturizer.net/thunderbird/features.html is terrible, worse than any of the others listed here, while working nicely in Linux. To say that scolling it at all is even possible in OS/2 is describing it too kindly, even though technically correct.
On my new Celeron 2.4G machine http://www.intraplanar.net/projects/ and http://texturizer.net/thunderbird/features.html remain horridly slow, pegging for quite some time just to load and/or switch to. http://www.w3.org/Style/CSS/learning remains unacceptably slow.
We understand the source of the problem - it's tiling transparent PNGs. Noone has the expertise to rewrite our code so that we do things differently. We're investigating.
I tried a much faster graphics card with no apparent improvement. Making summary reflect known problem.
Summary: 100% CPU load when viewing site → 100% CPU load when viewing site [tiling transparent PNG]
I am not completely sure at all, what is meant by "tiling transparent PNGs", although I clearly see the problem on the intraplanar site. Anyone care to explain in more detail? Are we by any chance talking about the code in nsImageOS2::DrawTile (at least the name is similar)? It is very unlikely that I may be able to do something about it, I don't have a clue about graphics programming. But perhaps I can get somebody else to take a look, once I can tell him which code he is supposed to deal with...
Yep, the problem is DrawTile. Basically we are blending transparent images and then tiling them and it is very slow.
Just a short status update: I got Harald Pollack (author of FaxView for OS/2, which despite the name is a nice multi-format image viewer) to look at the code. He likes very compact code and may want to rewrite the whole Mozilla. He is setting up the build environment and given enough time he will probably come up with optimal graphics code for OS/2 and so will eventually also solve the PNG problem this bug is about.
(In reply to comment #32) > Just a short status update: Any news on this one..?? Btw - another example: www.hamberg.dk Cheers
(In reply to comment #33) > Btw - another example: www.hamberg.dk Here I believe the use of 'fixed' is the problem. Regards
No, nothing new from Harald. I tried to help him with the setup to compile Mozilla but before he was successful he lost interest again. He probably has enough other stuff to work on... :-( On hamberg.dk as on the other problematic pages one small semi-transparent PNG image is used, in this case the 4x4 px PNG http://www.hamberg.dk/php/wp/446-70.png that is used to make the main background shine through the blue background in the boxes. On OS/2 a CPU intensive computation has to be run for each single one of these PNGs which takes a lot of time because of the background repeat it has to be done a few thousand times. If the author would instead use a normal background color and the CSS property "opacity: 0.7;" on the boxes instead, the effect would be the same without much computational effort. (I do this on http://star-www.dur.ac.uk/~pweilba/ to make the pictures shine through the menu box. As you can see there "fixed" is not as big a problem). Of course this method only works in a recent Mozilla and not in other browsers AFAIK where nothing shines through.
(In reply to comment #35) > No, nothing new from Harald. I tried to help him with the setup to compile > Mozilla but before he was successful he lost interest again. He probably has > enough other stuff to work on... :-( > > On hamberg.dk as on the other problematic pages one small semi-transparent PNG > image is used, in this case the 4x4 px PNG > http://www.hamberg.dk/php/wp/446-70.png that is used to make the main background > shine through the blue background in the boxes. On OS/2 a CPU intensive > computation has to be run for each single one of these PNGs which takes a lot of > time because of the background repeat it has to be done a few thousand times. If > the author would instead use a normal background color and the CSS property > "opacity: 0.7;" on the boxes instead, the effect would be the same without much > computational effort. (I do this on http://star-www.dur.ac.uk/~pweilba/ to make > the pictures shine through the menu box. As you can see there "fixed" is not as > big a problem). Of course this method only works in a recent Mozilla and not in > other browsers AFAIK where nothing shines through. I have found another rproducible case. Using Firefox 1.0.2 on WinXP SP2, browse to http://en.wikipedia.org/wiki/Image:Rpgwo_online_house.PNG. CPU utilization should spike up to 99% and stay there for several minutes. After approx. 5 minute,s the page will finish loading, and utilization drops down to 0. However, the page has a wide expanse of blank space both below and to the right of the image. Scrolling across this space spikes the CPU up to 85%. Scrolling away from the blank space reduces CPU usage to 0.
I have been playing with this a bit, I found that if I remove the if block here: http://lxr.mozilla.org/seamonkey/source/gfx/src/os2/nsImageOS2.cpp#757 that it renders very quickly then. The transparency is not right and it causes frequent crashes. I backed out some slow tile changes that Mike pointed out when I told him about the effects of removing the if block but those made no change. I see several options, either find a way to process the code in the faster tile section, find some way to optimize the slow tile (not sure but it may be faster to do the work in offscreen memory and blt it in), we could use cairo to render pngs, or as the work to get png's to render with cairo is probably as much work as thebes we could concentrate on thebes which should help us with this and I don't think be much if any slower for us overall.
(In reply to comment #37) > I have been playing with this a bit, I found that if I remove the if block > here: > http://lxr.mozilla.org/seamonkey/source/gfx/src/os2/nsImageOS2.cpp#757 > that it renders very quickly then. The transparency is not right and it causes > frequent crashes. Care to post a screenshot of one of the example sites with and without that block? If it's not too bad we could make a (hidden) pref option for that, off by default. When a user first visits a site that would need this block we could show a box asking him if he wants it switched on. Then we would just need to find out where it crashes and work around that. > I backed out some slow tile changes that Mike pointed out > when I told him about the effects of removing the if block but those made no > change. > I see several options, either find a way to process the code in the faster tile > section, find some way to optimize the slow tile (not sure but it may be faster > to do the work in offscreen memory and blt it in) That is actually what is done now. > we could concentrate on thebes which should help us with this and I > don't think be much if any slower for us overall. I have worked on Thebes for OS/2 the whole weekend but still didn't get it to start. What is needed is basically a rewrite of most of the code in gfx/src/os2, but in a fairly different way. And as I am not that familiar with the code there it just takes a while but I will get there. Although I am not sure how this will get around the problem. The alpha-blending has to be done somewhere and that just takes lots of CPU.
Just my penny of info: (ff 1.5.0.7) hamberg.dk is unreadable unless I use this in usercontent.css body>div#rap>div#content, body>div#rap>div#menu { background-image: none !important; background-color: #336699 !important; } https://bugzilla.mozilla.org/attachment.cgi?id=110088&action=view gives me no problems. Great to 'watch' your work.! Cheers
This is fixed in builds that use cairo for rendering (by the check in to bug 371504) and so hopefully in Firefox 3. It will never get fixed in branch builds (Firefox 2 and earlier).
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: