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
Steps to Reproduce:
1. Open Mozilla
2. Point it to http://www.w3.org/Style/CSS/learning
3. Try to scroll page
100% CPU load
CPU load must be less
Confirmed in OS/2 trunk 2002091008. Mike can probably tell why. I suspect a
java/JS floating menu.
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
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.
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.
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.
Created attachment 110088 [details]
testcase without any images
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
Here's another URL where scrolling performance is awful:
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.
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:
The issue is tiling of 1x1 transparent PNGs. We don't do good tiling of
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
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.
I tried a much faster graphics card with no apparent improvement.
Making summary reflect known problem.
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
Yep, the problem is DrawTile.
Basically we are blending transparent images and then tiling them and it is very
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
(In reply to comment #33)
> Btw - another example: www.hamberg.dk
Here I believe the use of 'fixed' is the problem.
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:
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
> 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
> 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 18.104.22.168)
hamberg.dk is unreadable unless I use this in usercontent.css
background-image: none !important;
background-color: #336699 !important;
https://bugzilla.mozilla.org/attachment.cgi?id=110088&action=view gives me no
Great to 'watch' your work.!
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).
*** Bug 382024 has been marked as a duplicate of this bug. ***