Last Comment Bug 167884 - 100% CPU load when viewing site [tiling transparent PNG]
: 100% CPU load when viewing site [tiling transparent PNG]
Status: RESOLVED WORKSFORME
: perf
Product: Core Graveyard
Classification: Graveyard
Component: GFX (show other bugs)
: Trunk
: x86 OS/2
: P3 normal with 1 vote (vote)
: ---
Assigned To: Mike Kaply [:mkaply]
: Chris Petersen
:
Mentors:
http://www.w3.org/Style/CSS/learning
: 382024 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-10 21:57 PDT by Boris Kovalenko
Modified: 2009-01-22 10:17 PST (History)
14 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
testcase without any images (4.93 KB, text/html)
2002-12-24 06:56 PST, Felix Miata
no flags Details

Description Boris Kovalenko 2002-09-10 21:57:47 PDT
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
Comment 1 Felix Miata 2002-09-10 22:58:29 PDT
Confirmed in OS/2 trunk 2002091008. Mike can probably tell why. I suspect a
java/JS floating menu.
Comment 2 David Baron :dbaron: ⌚️UTC-10 2002-09-11 06:11:41 PDT
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.
Comment 3 Mike Kaply [:mkaply] 2002-09-11 07:56:28 PDT
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.
Comment 4 Kevin McCluskey (gone) 2002-09-12 13:30:07 PDT
-> dcone
Comment 5 dcone (gone) 2002-09-16 11:24:58 PDT
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.
Comment 6 Felix Miata 2002-12-05 16:46:30 PST
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.
Comment 7 Felix Miata 2002-12-05 16:50:03 PST
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.
Comment 8 Markus Hübner 2002-12-11 01:52:40 PST
So this is hurting us also on Win98?
Comment 9 Felix Miata 2002-12-11 04:23:19 PST
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.
Comment 10 Felix Miata 2002-12-24 06:56:36 PST
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.
Comment 11 Mike Kaply [:mkaply] 2003-02-11 10:56:43 PST
I don't see this in the current build. Can anyone verify?
Comment 12 Felix Miata 2003-02-11 11:23:59 PST
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.
Comment 13 Mike Kaply [:mkaply] 2003-02-11 12:01:50 PST
I'm wagering this is video driver related. Are you using Scitech?
Comment 14 Felix Miata 2003-02-11 12:29:03 PST
SDD Pro 7.1
Comment 15 Boris Kovalenko 2003-02-11 19:10:31 PST
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.
Comment 16 Felix Miata 2003-02-11 20:19:11 PST
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.
Comment 17 Mike Kaply [:mkaply] 2003-02-11 21:14:10 PST
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.
Comment 18 Felix Miata 2003-02-14 07:19:24 PST
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.
Comment 19 Felix Miata 2003-02-14 07:25:15 PST
Here's another URL where scrolling performance is awful:
http://my.opera.com/dev/discussion/openweb/20030206/
Comment 20 Mike Kaply [:mkaply] 2003-02-14 08:38:52 PST
That site is slow on Windows as well...
Comment 21 Boris Kovalenko 2003-02-16 19:07:10 PST
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
Comment 22 Zibi Braniecki [:gandalf][:zibi] 2003-04-20 11:58:23 PDT
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).
Comment 23 Markus Hübner 2003-04-24 01:53:23 PDT
cc'ing some gfx people for input
Comment 24 Steve Wendt 2003-05-21 11:07:08 PDT
Another page that shows the problem really well:
http://www.intraplanar.net/projects/
Comment 25 Mike Kaply [:mkaply] 2003-05-21 11:50:53 PDT
The issue is tiling of 1x1 transparent PNGs. We don't do good tiling of
transparent stuff.
Comment 26 Felix Miata 2003-12-08 10:08:05 PST
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.
Comment 27 Felix Miata 2004-04-06 11:05:43 PDT
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.
Comment 28 Mike Kaply [:mkaply] 2004-04-06 11:22:30 PDT
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.
Comment 29 Felix Miata 2004-04-06 11:44:17 PDT
I tried a much faster graphics card with no apparent improvement.

Making summary reflect known problem. 
Comment 30 Peter Weilbacher 2004-08-02 13:35:44 PDT
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...
Comment 31 Mike Kaply [:mkaply] 2004-08-02 13:52:57 PDT
Yep, the problem is DrawTile.

Basically we are blending transparent images and then tiling them and it is very
slow.
Comment 32 Peter Weilbacher 2004-08-05 02:55:06 PDT
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.
Comment 33 steen 2004-12-29 12:59:45 PST
(In reply to comment #32)
> Just a short status update:

Any news on this one..??

Btw - another example: www.hamberg.dk

Cheers
Comment 34 steen 2004-12-29 13:08:22 PST
(In reply to comment #33)

> Btw - another example: www.hamberg.dk

Here I believe the use of 'fixed' is the problem.

Regards
Comment 35 Peter Weilbacher 2004-12-29 15:10:43 PST
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.
Comment 36 morlamweb 2005-03-25 11:16:03 PST
(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.
Comment 37 Andy Willis (abwillis) 2006-10-08 07:45:49 PDT
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.
Comment 38 Peter Weilbacher 2006-10-08 11:41:27 PDT
(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.
Comment 39 steen 2006-10-08 12:52:23 PDT
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
Comment 40 Peter Weilbacher 2007-05-20 07:05:21 PDT
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).
Comment 41 Peter Weilbacher 2007-05-26 13:05:31 PDT
*** Bug 382024 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.