Last Comment Bug 98252 - [win32,mac]New W3C CSS page hurts Mozilla
: [win32,mac]New W3C CSS page hurts Mozilla
Status: RESOLVED FIXED
[Hixie-P2][Hixie-1.0]
: perf
Product: Core Graveyard
Classification: Graveyard
Component: GFX (show other bugs)
: Trunk
: All All
: -- major with 3 votes (vote)
: mozilla0.9.8
Assigned To: dcone (gone)
: Chris Petersen
Mentors:
http://www.w3.org/Style/CSS/
: 106294 108182 110051 111482 111687 (view as bug list)
Depends on:
Blocks: 100951 advocacybugs 107067
  Show dependency treegraph
 
Reported: 2001-09-04 14:32 PDT by Keith Briscoe
Modified: 2014-04-25 15:15 PDT (History)
42 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
background image with a reduced color palette (for testcase) (100 bytes, image/png)
2001-09-17 09:54 PDT, basic
no flags Details
testcase using original 32bit image (2.51 KB, text/html)
2001-09-17 09:59 PDT, basic
no flags Details
testcase using 2bit image (faster) (2.82 KB, text/html)
2001-09-17 10:02 PDT, basic
no flags Details
256 x 256 2 colour png image (147 bytes, image/png)
2001-09-17 10:17 PDT, basic
no flags Details
testcase no-repeat using attachment 49596 (3.04 KB, text/html)
2001-09-17 10:18 PDT, basic
no flags Details
256x256 32bit png image (827 bytes, image/png)
2001-09-17 10:19 PDT, basic
no flags Details
testcase using attachment 49598 (3.27 KB, text/html)
2001-09-17 10:23 PDT, basic
no flags Details
patch that assumes 8-bit alpha images are really 1-bit alpha until proven otherwise (8.05 KB, patch)
2001-09-25 17:03 PDT, tor
no flags Details | Diff | Splinter Review
same plus add back optimization for fully-opaque 8-bit alpha PNG (8.22 KB, patch)
2001-09-25 17:25 PDT, tor
rjesup: review+
attinasi: superreview+
Details | Diff | Splinter Review
tiny PNG that is used to make semi-opaque fixed pos banner (148 bytes, image/png)
2001-12-13 14:02 PST, Marc Attinasi
no flags Details
Reduced testcase of the CSS page: this shows that the perf problem is the use of a tiny semi-opaque PNG for transparency. (5.21 KB, text/html)
2001-12-13 14:07 PST, Marc Attinasi
no flags Details
Speeds the alphablend of 8.. I saw at least 4x improvment. (8.70 KB, patch)
2002-01-04 14:51 PST, dcone (gone)
no flags Details | Diff | Splinter Review
More error checking and scaling fix in this patch. (9.18 KB, patch)
2002-01-04 15:24 PST, dcone (gone)
attinasi: superreview+
Details | Diff | Splinter Review
added just a few speedups.. optimized some math. (9.39 KB, patch)
2002-01-08 13:33 PST, dcone (gone)
kmcclusk: review+
Details | Diff | Splinter Review

Description Keith Briscoe 2001-09-04 14:32:35 PDT
The W3C has recently updated their CSS page to use even fancier styles, etc. 
The transparent background used on the fixed positioned banner element
completely nails Mozilla's performance on rendering and scrolling, making it
pretty much unusable.

To make matters worse, even though IE6 STILL can't render this page correctly
(it couldn't render the old version right either), its performance is so much
better that it's a "more pleasant browsing experience" overall.

I'd consider this a very high-visibility bug, if not a very critical one.
Comment 1 Hixie (not reading bugmail) 2001-09-04 14:48:51 PDT
wow, that's bad.
Comment 2 Markus Hübner 2001-09-09 05:37:53 PDT
this page is also refering to bug 96088
Comment 3 Johnny Stenback (:jst, jst@mozilla.com) 2001-09-14 17:07:39 PDT
Hmm, this really does suck, any chance of getting some traction on this on the
m094 branch?
Comment 4 basic 2001-09-17 00:26:14 PDT
marking "OS: All" based on DBaron's comment in bug 96088
propose for mozilla0.9.5
Comment 5 basic 2001-09-17 09:19:04 PDT
there seem to be some problems with the way mozilla handles transparent PNGs.
I'll post 2 testcases.
Comment 6 basic 2001-09-17 09:54:27 PDT
Created attachment 49591 [details]
background image with a reduced color palette (for testcase)
Comment 7 basic 2001-09-17 09:59:32 PDT
Created attachment 49592 [details]
testcase using original 32bit image
Comment 8 basic 2001-09-17 10:02:42 PDT
Created attachment 49593 [details]
testcase using 2bit image (faster)
Comment 9 basic 2001-09-17 10:14:19 PDT
err the testcase above was meant to say 2 color not 2 bit.

I've also noticed that when the image (32bit) is made bigger and is not repeated
it is also faster than original testcase but still have more visible "lag"
effect than the 2 color image. The thing is that when the bigger image is
reduced to a 2 color image it does not affect the "lag". I'll post another testcase.
Comment 10 basic 2001-09-17 10:17:22 PDT
Created attachment 49596 [details]
256 x 256 2 colour png image
Comment 11 basic 2001-09-17 10:18:59 PDT
Created attachment 49597 [details]
testcase no-repeat using attachment 49596 [details]
Comment 12 basic 2001-09-17 10:19:42 PDT
Created attachment 49598 [details]
256x256 32bit png image
Comment 13 basic 2001-09-17 10:23:19 PDT
Created attachment 49599 [details]
testcase using attachment 49598 [details]
Comment 14 Alvaro Munoz-Aycuens 2001-09-19 07:55:39 PDT
Changing platform to all after testing on Mac with build id: 2001091804
Comment 15 Jens-Uwe 2001-09-19 16:31:48 PDT
is bug 100575 connected to or a dupe of this one?
Comment 16 Daniel Bratell 2001-09-19 23:04:57 PDT
The page scroll time of the original page is on Windows dominated by:
nsViewManager::RenderViews
 nsViewManager::RenderDisplayListElement
  nsView::Paint
   PresShell::Paint
    nsBlockFrame::Paint
     nsCSSRendering::PaintBackground
      nsRenderingContextImpl::DrawTile
       nsImageWin::DrawTile
        nsImageWin::Draw
         nsImageWin::DrawComposited

nsImageWin::DrawComposited is ~80% of the scroll time. It and nsImageWin::Draw 
is called 170000 times for 4-5 page downs. nsImageWin::DrawTile is called only 
227 times. 
Comment 17 Chris Waterson 2001-09-20 10:11:59 PDT
cc'ing pavlov & sfraser. Read bratelle's analysis, above.
Comment 18 Keith Briscoe 2001-09-20 14:26:28 PDT
If we can't fix this on the NS branch, I'd suggest that the branch kludgily
disable transparency in fixed-positioned elements, period.  This bug is so
painful I don't think emojo should allow it to see the light of day.  I think
the W3C page is normally a good place to show off our CSS2 support, but this
cancels out all the good things and leaves the user feeling like Moz is buggy.
Comment 19 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2001-09-20 16:13:31 PDT
I saw on Linux something very similar to what Daniel Bratell saw on on Windows,
except s/Win/GTK/ in the profile.  (Also note that there's some recursion
between nsBlockFrame::Paint and nsContainerFrame::Paint in there too.)
Comment 20 Keith Briscoe 2001-09-24 08:14:41 PDT
A somewhat embarrassingly public discussion of this bug:
http://dot.kde.org/1001290684/
Comment 21 Cindy Roberts 2001-09-24 11:19:45 PDT
Dave, can you give your assessment of how bad this bug is?  The behavior seems
bad but was wondering a) how many sites will exhibit this problem and b) how
badly this will hurt our standards compliance story.  We're only accepting "stop
ship" bugs for the nsbranch now so let us know if we should consider this one.
Comment 22 Dave Barrowman 2001-09-24 12:11:43 PDT
Is this specifically a problem with fixed-position, transparent, 32bit PNGs?  

If so, I don't think this is "stop ship", based on the low number of cases where
this is likely to crop up.

If there is a simple way to "turn off" the transparency, we should investigate
it as an option for the branch.
Comment 23 Kevin McCluskey (gone) 2001-09-24 12:29:50 PDT
This bug is specific to having a page that includes a fixed position png image
with transparency.  This causes scrolling performance to degrade because the
entire image must be composited with the background pixel by pixel every time
the user scrolls. 

There isn't an easy solution for this. If we turn off transparency for PNG files
then a much larger number of sites will be impacted. One of the big advantages
of using a PNG image is it's support for transparency. 

To speed up the compositing operation we need to investigate platform specific
rendering api's which may contain acceleration for compositing operations such
as DirectX on WIN32. I'm not sure if there analogous capabilities on Mac and Linux. 

As a short term solution, we may be able to turn off transparency on any page
which has a fixed-position element. 



Comment 24 Daniel Bratell 2001-09-24 12:40:00 PDT
There is no problem in nsImageWin::DrawTile then? The almost one thousand
nsImageWin::Draw calls for each call to nsImageWin::DrawTile seems a little high
to me. This shouldn't be such a tough problem that we require special hardware
accelerated graphics I think. Not on modern computers with CPU:s in the GHz
class, and still it does.
Comment 25 Eric A. Meyer (dead account) 2001-09-24 12:59:55 PDT
I did some testing on 2001091311/Mac (where the scroll problem seemed much worse
than NS6.1/Win, for example) and discovered the following:

 - upon making the background of the "banner" (the fixed-position menu) a 2x2
GIF instead of a 2x2PNG, the scroll speed sped up a bit.
 - altering the background image to be 8x8 or 16x16 really sped up scrolling,
although it left "ghosts" of the banner littered through the page as I scrolled
up and down.

See http://www.meyerweb.com/eric/css/tests/moz/w3css/style-css8.html for the 8x8
GIF version, and
http://www.meyerweb.com/eric/css/tests/moz/w3css/style-css2.html for the 2x2 GIF
version.  In Win2KPro I can't see a difference in scroll speed, but on a Mac I
definitely can.
Comment 26 Eric A. Meyer (dead account) 2001-09-24 13:03:28 PDT
"This bug is specific to having a page that includes a fixed position png image
with transparency.  This causes scrolling performance to degrade because the
entire image must be composited with the background pixel by pixel every time
the user scrolls."

If someone could send me an 8x8 or 16x16 version of the PNG, I can add it to my
test cases (mentioned above) and see if that speeds things up or not.  I'd
create my own, but apparently Photoshop 5.5 doesn't want to play nice with PNG.
 Anyway, I've seen cases where tiling a 1x1 GIF (not PNG, but GIF) in the
background of a non-fixed element really grinds MacMoz to a halt, so perhaps the
two are related.
Comment 27 Simon Fraser 2001-09-24 13:08:33 PDT
Tiling optimizations have gone in on the Mac since the 2001091311 build, and I 
think these optimizations would eliminate any perceived speed difference between 
the 2x2 and 16x16 background images.
Comment 28 Kevin McCluskey (gone) 2001-09-24 13:12:43 PDT
Note: Neither I.E 6 or Opera 5 Renders this page correctly.  I.E completely
ignores the fact that the translucent menu is fixed position and scrolls it up
and down. Opera honors the fixed positioning of the translucent menu, but does
NOT render it by combining the background image with the menu. It seems to
render the menu as either having an opaque background or treats the background
as transparent.  Mozilla renders the page correctly, but is very slow to scroll.
Comment 29 Adam D. Moss 2001-09-24 13:56:18 PDT
Yow!  Both of those GIF versions are so much faster it's
terrifying.  Is the problem endemic to PNGs?  Is it because
of their 'real' alpha support?  In that case are we having to
do get/blend/put X-server round-trips for every tile repetition?
Comment 30 Jens-Uwe 2001-09-24 14:18:28 PDT
i am not sure if this is png specific. Please look at the following page:
http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html
The author (eric?) says there are no PNGs involved and it still scrolls very
slow with a fixed background.
Comment 31 Eric A. Meyer (dead account) 2001-09-24 14:27:38 PDT
"Tiling optimizations have gone in on the Mac since the 2001091311 build, and I 
think these optimizations would eliminate any perceived speed difference between 
the 2x2 and 16x16 background images."

Not for me, at least in 2001092303.  The ghosting is gone, but the scroll speeds
seem about the same to me.  They might be a little faster than 2001091311, of
course, but I'm going by what my eye sees.  The 2x2 PNG is still dog-slow, the
2x2 GIF is slowish but not bad, and the 8x8 GIF is pretty fast.
"i am not sure if this is png specific. Please look at the following page:
http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html
The author (eric?) says there are no PNGs involved and it still scrolls very
slow with a fixed background."

In which version on what platform?  The speed seems pretty good to me in
2001092303/Mac and also NS6.1/Win2KPro.  In terms of images, each stylesheet
uses exactly four JPGs and nothing else, and also no opacity property calls. 
Anyway, PNGs are obviously a lot slower for me (on Mac) and while smaller images
tile more slowly, the biggest speed hit does seem to happen with PNG files.
Comment 32 Jens-Uwe 2001-09-24 14:45:50 PDT
eric: i am using 2001092409 on linux. P3-500, 256MB, TnT2-M64.
Comment 33 Daniel Lichtenberger 2001-09-25 09:45:27 PDT
"Please look at the following page:
http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html
The author (eric?) says there are no PNGs involved and it still scrolls very
slow with a fixed background."

Here it scrolls smoothly on a 16 bit desktop (Windows 2000), but lags a bit in
32 bit. IMHO this isn't necessarily related to mozilla itself, this page really
puts some load on the graphics card in high resolutions/bit depths... 
Comment 34 tor 2001-09-25 17:03:37 PDT
Created attachment 50793 [details] [diff] [review]
patch that assumes 8-bit alpha images are really 1-bit alpha until proven otherwise
Comment 35 tor 2001-09-25 17:09:31 PDT
The small "8-bit" alpha image was killing performance under gtk because we
round trip the server for each tile.  The attached patch for nsImageGTK
checks if an 8-bit alpha channel image is really just a masked image and
goes through the fast path if possible.  Makes a night/day difference for
the w3 css page.

I'm working on proper tiling support for true alpha images, but this is
probably a worthwhile change since avoiding the compositing path will be
faster.
Comment 36 tor 2001-09-25 17:25:35 PDT
Created attachment 50800 [details] [diff] [review]
same plus add back optimization for fully-opaque 8-bit alpha PNG
Comment 37 Randell Jesup [:jesup] 2001-09-26 07:51:39 PDT
I've looked at this code in detail before in relation to another bug, and this
looks like a very well-done solution to the most common case of the problem.  My
only quibble (which is a quibble to the original code, not the patch) is
that there's an assumption inherent in the Alpha code (and quite possibly in
other code as well) that a row is no more than 32K bytes long - and for 8-bit
alpha, that means 32K pixels wide (and no more than 32K pixels high):

   PRInt16       mAlphaRowBytes;     // alpha bytes per row
+  PRInt16       mTrueAlphaRowBytes; // alpha bytes per row
   PRInt16       mAlphaWidth;        // alpha layer width
   PRInt16       mAlphaHeight;       // alpha layer height

Other than that (which is really a separate issue anyways, and probably
shouldn't be addressed in this bug) r=rjesup@wgate.com for what it's worth.  I
imagine pav or some such should review as well, since I'm not a gfx/gdk guru, so
I'm not marking it as reviewed on the attachment.
Comment 38 Kevin McCluskey (gone) 2001-09-26 11:04:41 PDT
Pav, can you review tor's patch?
Comment 39 Stuart Parmenter 2001-09-26 11:51:48 PDT
r=pavlov
Comment 40 Marc Attinasi 2001-09-26 12:41:50 PDT
Comment on attachment 50800 [details] [diff] [review]
same plus add back optimization for fully-opaque 8-bit alpha PNG

sr=attinasi. But, what is this cast to (PRUint8*) for? 

delete[] (PRUint8*)mTrueAlphaBits;

Seemse unnecessary...
Comment 41 Randell Jesup [:jesup] 2001-09-26 13:30:06 PDT
That cast is required to avoid violating C++ specs.  The HPUX compiler will
complain/break if it's removed.  (Found that out the hard way a ways back - HPUX
gives very good error messages.)
Comment 42 Randell Jesup [:jesup] 2001-09-26 15:18:13 PDT
My apologies if I'm wrong - I assumed it was being casted because it was a void
*.  delete [] (void *) is what gives HPUX fits.  Perhaps the code was stolen
from such a case.
Comment 43 tor 2001-09-26 18:25:43 PDT
Checked in with attinasi's comment addressed (casted delete copied from
other unnecessarily casted deletions in nsImageGTK [now fixed]).

Leaving bug open for macos/win32 performance problems.
Comment 44 Adam D. Moss 2001-09-27 01:00:51 PDT
(verified fixed on linux)
Comment 45 Kevin McCluskey (gone) 2001-09-27 12:51:47 PDT
Marking nsbranch-
Comment 46 Hogarth 2001-09-28 19:48:29 PDT
The 32bit testcase is muchly imporved here. It's still not keeping up with my
keyrepeat events and so when I lift my finger from the up-arrow key it still
keeps on scrolling up. it should stop scrolling as soon as I lift my finger off
the button. but that's another bug entirely... :)

Build: 2001092813;
OS: Linux 2.2.19; Glibc: 2.1.3; Distro: Debian 2.2r3;
System: 700Mhz, Pentium III, 256MB RAM.
Comment 47 [not reading bugmail] 2001-11-01 08:54:17 PST
Daniel, 32 bit depths are 24bits color + 8 bits of alpha channels..  which is
what we are seeing here.. 16bit will probably not run the code for the 8bits of
alpha channels of an 32bit image.  Hence feeling of faster in transparency,
Opacity, Alpha.. etc, when its not being used in 16bit.
Comment 48 Ashley Bischoff (blog at handcoding.com) 2001-11-02 08:43:38 PST
*** Bug 108182 has been marked as a duplicate of this bug. ***
Comment 49 Oliver Klee 2001-11-14 09:27:07 PST
*** Bug 110051 has been marked as a duplicate of this bug. ***
Comment 50 Boris Zbarsky [:bz] 2001-11-22 10:11:43 PST
*** Bug 111482 has been marked as a duplicate of this bug. ***
Comment 51 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2001-11-23 22:16:07 PST
*** Bug 111687 has been marked as a duplicate of this bug. ***
Comment 52 Koike Kazuhiko 2001-11-30 06:26:08 PST
*** Bug 106294 has been marked as a duplicate of this bug. ***
Comment 53 Kevin McCluskey (gone) 2001-12-13 14:01:58 PST
Reassigning to Don. The performance problem is caused by tiling a 1X1 png with
opacity.
Comment 54 Marc Attinasi 2001-12-13 14:02:10 PST
Created attachment 61618 [details]
tiny PNG that is used to make semi-opaque fixed pos banner
Comment 55 Marc Attinasi 2001-12-13 14:07:00 PST
Created attachment 61619 [details]
Reduced testcase of the CSS page: this shows that the perf problem is the use of a tiny semi-opaque PNG for transparency.

Compare the performance with this testcase as-is, and with the comment-out
style rule for opacity instead of the background PNG
Comment 56 Simon Fraser 2001-12-13 15:15:25 PST
Something that is interesting about the w3c page is that when it first lays out, 
and I scroll (on Mac), the floating transparent badge leaves turds. If I resize 
the window slightly, the floater moves a little to the left (by the width of the 
scroll bar?), and thenceforth scrolling is clean. So it looks like the initial 
layout of the floater is incorrect, possibly because of scrollbars showing up.
Comment 57 Diego Biurrun 2001-12-21 03:50:44 PST
Scrolling speed is OK on Linux 2001122008 (K6-2 500, 512MB, Matrox G200 8MB).
Comment 58 Adam D. Moss 2001-12-21 05:28:05 PST
Yeah Diego, this is already fixed on unix/GTK.  See comment #43, comment #44 etc.
Comment 59 Andrew Hagen 2001-12-21 18:16:20 PST
Still very slow on Windows 98, Mozilla 0.9.7, 380Mhz K6-2.
Comment 60 Jesse Houwing 2001-12-22 03:04:00 PST
I'm not sure if this is already the case, but couldn't this be sped up in
windows by using DirectX (DirectDraw to be more precise)? Those are the
functions IE uses and IE is fine with this page...
Comment 61 gavin long 2001-12-23 10:57:31 PST
Jesse: IE doesn't do the transparency on the floating toolbar, and it's the use
of PNG alpha-transparency causing the performance hit in Moz.  See comment #23,
comment #28, above.

Comment 62 Jesse Houwing 2001-12-27 13:37:22 PST
ahhh never mind then... But maybe DirectX or Quicktime (Win32 and Mac
respectively) could be used to speed up this process.
Comment 63 Randell Jesup [:jesup] 2001-12-27 14:24:14 PST
It is possible that DirectX/Draw might help here, or at least make better use of
available HW support/acceleration.  However, that's not a trivial change, and
there might be some ramifications.  In general, though, DirectDraw/etc are
pretty well optimized and very usable.
Comment 64 Jesse Houwing 2001-12-28 05:10:54 PST
I think it could speed up quite some stuff in Mozilla... But indeed it would be
a large change with it's implications etc. It may just be worth it.
Comment 65 Sören 'Chucker' Kuklau (gone) 2001-12-29 15:04:19 PST
I think such big changes shouldn't be checked in before the "magical" 1.0
release. They would either "make 1.0 suck" or make 1.0 be released a lot later,
I guess. Sure, it would be nice to have this stuff fixed in an optimum way, but
do we rather want a (too?) late 1.0, a too buggy 1.0 or a rock-solid 1.0 with a
small list of lacking features and performance issues?
Comment 66 Jesse Houwing 2001-12-30 08:13:08 PST
Should we then open a bug with Direct X optimizations for Mozilla and mark it
future, that way it can be tracked and other places that could use such
optimizations could also.
Comment 67 dcone (gone) 2002-01-04 14:51:34 PST
Created attachment 63583 [details] [diff] [review]
Speeds the alphablend of 8.. I saw at least 4x improvment.

Please test and let me know if this is good enough with Marc's tests.
Comment 68 dcone (gone) 2002-01-04 15:24:56 PST
Created attachment 63588 [details] [diff] [review]
More error checking and scaling fix in this patch.
Comment 69 Marc Attinasi 2002-01-07 11:20:56 PST
Comment on attachment 63588 [details] [diff] [review]
More error checking and scaling fix in this patch.

sr=attinasi
Comment 70 dcone (gone) 2002-01-08 13:33:49 PST
Created attachment 64016 [details] [diff] [review]
added just a few speedups.. optimized some math.
Comment 71 Kevin McCluskey (gone) 2002-01-08 14:09:10 PST
Comment on attachment 64016 [details] [diff] [review]
added just a few speedups.. optimized some math.

r=kmcclusk@netscape.com
Comment 72 [not reading bugmail] 2002-01-10 02:43:09 PST
This page is rendered way faster now.. and scrolls real fast, w2k.
Comment 73 dcone (gone) 2002-01-10 06:59:42 PST
Windows fix checked in.
Comment 74 Peter Nilsson 2002-01-11 01:49:35 PST
It works good now. (Win)

Except that the background near the rounded corners just above the headline
'learning css' get trashed.

Maybe this is a bug in -moz-border-radius ?

Comment 75 [not reading bugmail] 2002-01-12 03:06:12 PST
looks like other platforms have tried in bug 64188
Comment 76 Tuukka Tolvanen (sp3000) 2002-01-12 06:00:30 PST
Peter, background near the rounded corners mess is bug 101130. (20020111003 win
scrolls fine, sweet.)
Comment 77 gavin long 2002-01-13 01:37:05 PST
Yup, win32 is much improved in 2002011103.  Is the patch win32 only, or do we
need to find someone to test on mac?  And is this a problem on any of the more
obscure OS's?
Comment 78 Simon Fraser 2002-01-14 11:52:03 PST
That patch is windows only. Mac already performs OK on this page.
Comment 79 dcone (gone) 2002-01-14 14:45:26 PST
Mac and Linux are fine.. according to comments.. so I am closing out this bug.

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