The default bug view has changed. See this FAQ.

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

RESOLVED WORKSFORME

Status

Core Graveyard
GFX
P3
normal
RESOLVED WORKSFORME
15 years ago
8 years ago

People

(Reporter: Boris Kovalenko, Assigned: mkaply)

Tracking

({perf})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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
(Reporter)

Updated

15 years ago
OS: other → OS/2

Comment 1

15 years ago
Confirmed in OS/2 trunk 2002091008. Mike can probably tell why. I suspect a
java/JS floating menu.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

15 years ago
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
(Assignee)

Comment 3

15 years ago
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.

Updated

15 years ago
Priority: -- → P3
-> dcone
Assignee: kmcclusk → dcone

Comment 5

15 years ago
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

Comment 6

15 years ago
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

15 years ago
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

15 years ago
So this is hurting us also on Win98?

Comment 9

15 years ago
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

14 years ago
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.
(Assignee)

Comment 11

14 years ago
I don't see this in the current build. Can anyone verify?

Comment 12

14 years ago
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.
(Assignee)

Comment 13

14 years ago
I'm wagering this is video driver related. Are you using Scitech?

Comment 14

14 years ago
SDD Pro 7.1
(Reporter)

Comment 15

14 years ago
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

14 years ago
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.
(Assignee)

Comment 17

14 years ago
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

14 years ago
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

14 years ago
Here's another URL where scrolling performance is awful:
http://my.opera.com/dev/discussion/openweb/20030206/
(Assignee)

Comment 20

14 years ago
That site is slow on Windows as well...
(Reporter)

Comment 21

14 years ago
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).

Comment 23

14 years ago
cc'ing some gfx people for input

Comment 24

14 years ago
Another page that shows the problem really well:
http://www.intraplanar.net/projects/
(Assignee)

Comment 25

14 years ago
The issue is tiling of 1x1 transparent PNGs. We don't do good tiling of
transparent stuff.

Comment 26

14 years ago
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

13 years ago
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.
(Assignee)

Comment 28

13 years ago
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

13 years ago
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]

Comment 30

13 years ago
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...
(Assignee)

Comment 31

13 years ago
Yep, the problem is DrawTile.

Basically we are blending transparent images and then tiling them and it is very
slow.

Comment 32

13 years ago
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

12 years ago
(In reply to comment #32)
> Just a short status update:

Any news on this one..??

Btw - another example: www.hamberg.dk

Cheers

Comment 34

12 years ago
(In reply to comment #33)

> Btw - another example: www.hamberg.dk

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

Regards

Comment 35

12 years ago
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

12 years ago
(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.

Comment 38

11 years ago
(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

11 years ago
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

10 years ago
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
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME

Updated

10 years ago
Duplicate of this bug: 382024
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.