[Image Tiling] Windows Platform Cleanup



Core Graveyard
Image: Painting
15 years ago
8 years ago


(Reporter: paper, Assigned: paper)



Windows 2000

Firefox Tracking Flags

(Not tracked)




(1 attachment, 4 obsolete attachments)



15 years ago
Smarter Image Tiling:

- Don't create temporary tiling DC if not needed

- Don't draw full image on areas not in tile region. Presently, if we have a div
of 50x50, with a dotted border of 1 (making the total 52x52), and a image of
50x50 tiled over the div, we make an offscreen DC and blit the image 9 times..
topleft (1x1px seen), top (50x1px seen), topright (1x1px seen), left (1x50px
seen), middle (50x50px), right (1x50px), bottomleft, bottom, and bottomright.

- Stop progressively doubleblitting when 1/2 the tile area is blitted, and do
two draws to the screen.  This is always faster than p. doubleblitting the whole
image and drawing to screen once.  We used to do it the fast way before I mucked
it up in another patch.  Oops


Perf tests: 

Verification that tiling still works properly:

Comment 1

15 years ago
Created attachment 115041 [details] [diff] [review]

ProgressiveDoubleBlit is pretty much rewritten.  For reviewers/SRs, it's
probably easier to apply the patch and review the function instead of trying to
read the diff.

Comment 2

15 years ago
Comment on attachment 115041 [details] [diff] [review]

ere, since you r'd one of my other tiling patches, could you r this one?

Comment #1 & #2 has all the good info on the patch.  I went through the code
and added extra comments as well, so hopefully that will make things easier.
Attachment #115041 - Flags: review?(ere)

Comment 3

15 years ago
I've yet to go through the actual functionality, but here are the notes from the
first pass:

- ((nsDrawingSurfaceWin *)aSurface)->ReleaseDC() missing from most early returns
- oldMaskBits not selected back, maskDC and maskBits not destroyed at 978
- oldBits and oldMaskBits at 1004 should be renamed to avoid (my) confusion
- oldBits and oldMaskBits not selected back, maskDC, maskBits and mTmpHBitmap
not destroyed at 1029 and 1063

And the mandatory nits: 

- in .h: "Progressivly" -> Progressively
- in .cpp: "drawn a tall" :)

With these fixed it's easier to check if there was even more :)
Now to functional check..

Comment 4

15 years ago
Created attachment 115173 [details] [diff] [review]
mwhaha!! do break while(0)!

bah, too many exit points with lots of unreleased resources.
I put a "do { stuff; if (fail) break; stuff; } while (0);"  loop in there and
break instead of return.  After the "loop", cleanup takes place.

I checked every exit point twice, but that doesn't mean I haven't missed
something again, so have a go at it. :)

Also changed oldBits and oldMaskBits to oldImgBits, oldDstBits, oldImgMaskBits,
and oldDstMaskBits.

And fixed the typos.
Attachment #115041 - Attachment is obsolete: true


15 years ago
Attachment #115041 - Flags: review?(ere) → review-


15 years ago
Attachment #115173 - Flags: review?(ere)

Comment 5

15 years ago
The patch looks good to me. I'll give it r= as soon as I can test it (as soon as
I get my tree working).

Comment 6

15 years ago
Created attachment 115304 [details] [diff] [review]
Patch, with Win95/98/ME 0xFF0000 limit check

Forgot about the 0xFF0000 DC memory limit for Win95/98/ME.  That's there now. 
Also made the logic better for choosing whether to just draw "up to 4 image
parts" or p. double blitting.
Attachment #115173 - Attachment is obsolete: true

Comment 7

15 years ago
Created attachment 115305 [details]
Changes between last 2 patches

This should make it easier for Ere to review.  It contains only the changes
between the last patch and the new one.


15 years ago
Attachment #115173 - Flags: review?(ere) → review-


15 years ago
Attachment #115304 - Flags: review?(ere)

Comment 8

15 years ago
Comment on attachment 115304 [details] [diff] [review]
Patch, with Win95/98/ME 0xFF0000 limit check

Otherwise it's good, but I stumbled on something suspicious. I run it under
CodeWatch to check for any leaks I didn't notice (there wasn't anything, btw)
but crashed at CreateDIBSection(). It was fixed by changing the ppvBits
parameter to non-NULL. This could be caused by CodeWatch instrumentation, but
MSDN doesn't state whether it can be NULL or not, so to be safe I'd change all
of them to something like this (I know it was NULL before your patch, but

void *maskBitValues;
maskBits  = ::CreateDIBSection(theHDC, (LPBITMAPINFO)&bmi,
	DIB_RGB_COLORS, &maskBitValues, NULL, 0);
Attachment #115304 - Flags: review?(ere) → review-

Comment 9

15 years ago
Created attachment 115330 [details] [diff] [review]

Never had a problem with it, but there's no perf difference, so better safe
than sorry :)

There were 3 CreateDIBSection in ProgressiveDoubleBlit(..), so I did them all.
Attachment #115304 - Attachment is obsolete: true
Attachment #115305 - Attachment is obsolete: true

Comment 11

15 years ago
Comment on attachment 115330 [details] [diff] [review]

roc, is this something you're willing/able to SR?

perf gain is somewhere around 30% for JPG and GIF tiling, and about 5% gain for
PNG tiling.
Attachment #115330 - Flags: superreview?(roc+moz)
Attachment #115330 - Flags: superreview?(roc+moz) → superreview+

Comment 12

15 years ago
checked in
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 13

15 years ago
Perf Results:

% are in comparison to 0224 (+ means 0224 was faster, - means the other browser
was faster)

Test -->    PNG    JPG     GIF  RealPNG NoTiling
20030224   9163   7090   12738   9493   6950

20030223  10044   9012   17205  10004   6990
            10%    27%     35%     5%     1%
IE6        6950*   7010  72276   7001*  8061
           -24%*   -1%    467%   -26%*   16%
Op7       12197   6739   10175  11907   6400
            33%    -5%    -20%    25%    -8%

* = Did not draw correctly

Overall, a big win for GIF tiling from today and yesterday, a moderate win for
JPG tiling, and a small win for PNG tiling.  The only place that really needs
improving is GIF tiling, since OP7 does it much faster.
hey Arron, I'm not asserting on every message I load in mailnews.
(see bug #194791).

can you jump in there and comment?  

I have a feeling it isn't your fault, but some bad xul or css in mailnews.


8 years ago
Component: Image: Painting → Image: Painting
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.