Closed Bug 187822 (TileCache) Opened 22 years ago Closed 1 year ago

Tile Cache!

Categories

(Core Graveyard :: Image: Painting, enhancement)

Product:
Core Graveyard
Component:
Image: Painting
Platform:
x86
Windows 2000
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE
Milestone:
Future

People

(Reporter: paper, Assigned: paper)

References

(
URL
)

Details

(Keywords: perf, testcase)

Attachments

(1 file, 1 obsolete file)

TileCache w/array
22.67 KB, patch
paper
: review-
Details | Diff | Splinter Review
Windows only, although other platforms may benifit if they do this. What really slows us down when tiling is those small images, usually something like 2x1. Every time an area is repainted, we make a memory DC and blit the image onto it. Using doubleblitting speeds this process up, but we can do more. Proposal: If imageSize < 2k, make a cache memory DC of up to 2k. This would use doubleblitting to create the DC, until the doubling would cause more than 2k memory usage (or it should stop if the whole tile area is covered). Store this DC in nsImageWin. Next time we have to tile paint an area, use the DC. I think we'd see a big perf gain, in exchange for 2k more memory usage (only on images who have been tiled) 2k is just a number too.. it could be changed, although I think a pref would be going too far.
http://mozilla.animecity.nu/IMGTest/TileTest01.html is the test I'm using to verify performance. Surprisingly, IE tiling speed sucks. Opera is currently faster than Moz. I plan to change that :) There's also http://mozilla.animecity.nu/IMGTest/TileTest02.html which is just the JPG tile test (IE croaks on the stylesheet changer script in TileTest01) Some notes on the test: The test shows and hides PNG (or JPG) 50 times (total of 100), counts the time, and averages it. After changing your resolution, you'll have to clear your cache (memory and HD), or restart Mozilla. This is due to reload (and Control-Reload) not reloading background images. There's a bug on that somewhere. 32bit we are terribly slow at. I can get it close to 24/16 bit speeds. Also, 10k seems to be a nice tile cache size. 2k just doesn't do very much when you look at examples that have a 2x1 PNG tiled over your 1280x1024 display. 20k, of course, is even better, but then I start worrying about wasting memory. There's very little I can do for perf on Win95/98 and tiled PNGs other than to check if Win98SE fixed the GDI AlphaBlend bug. Oh, the forthcoming patch will also fix messed up tiling when you have viewmanager.do_doublebuffering off. Unless I make a new bug for it, but it's only a 3 line code change.
Alias: TileCache
URL: http://mozilla.animecity.nu/IMGTest/T...
Keywords: perf
very nice approach, paper!
Is there any danger that if those small images _should_ be repainted, they wont be, Because, they'll be loaded from cache?
Zbigniew, I'm not sure if I understand your question. The tile cache is just a bit of memory containing the image tiled.
And this part is loaded from cache everytime it's needed, yes?
Paper, can you add some code to see how many of these tile caches get allocated and what the peak usage is? I suspect (hope!) that it's not very much ... I assume not many pages have many small tiled images on them. Cool idea ...
roc, what kind of data are you exactly looking for? A PR_LOG of everytime a tile job can be/is cached? With stats on how many blitting operations it saved? Or a PR_LOG of every tile mozilla comes across, so an average image size & tile area size can be calculated? Or just comfirmation that sites do use small tiles a lot? Out of the 10 sites in Debug->Verification, 3 use small image tiling. When I go to a alexa.com, and click on some of the top 100 sites there, about 70% of them have small image tiling, many of those 70% have multiple small images that they tile (mind you, most of alexa's top 100 are Korean sites). Even http://www.w3.org/Style/CSS/ tiles a small image .. http://www.w3.org/Style/semi2x2b.png for it's hovering menu. The biggest use of small image tiling I find is for <BODY BACKGROUND=blah.gif> where blah.gif is a small pattern of some sort. People seem to like that. The second biggest use of small iamge tiling I see is in table cells.. such as http://www.mozillazine.org/forums/ (the divider rows with the color strips)
I'm wondering what the maximum amount of memory devoted to tile caches is during a typical browsing session.
Attached patch TileCaching with logging (obsolete) — — Splinter Review
heh, the biggest problem is a typical browsing session is different for each user. So here's the patch with logging. Do your typical evironment variable settings like: NSPR_LOG_MODULES=TileCacheLog:5 NSPR_LOG_FILE=E:\TileCache.log and you should get a log file with two usefull colums, NumActive, and TotalMemory. Tabbed-delimited, so you can paste it into a spreadsheet and do calculations. I ran a small test and opened 10 pages at random from Alexa's top 100. Memory usage for Mozilla before pages opened was 76M. Memory after pages were opened and viewed: 114M. Difference: 48M. Peak tile cache memory usage: 180k (21 tile caches)
10 pages in 10 windows or one after the other in the same window?
That's 10 pages in seperate 10 windows. I'd imagine if I loaded them one after another into the same window, I'd only have 10 - 20k of tile cache memory.
Well, please check ... if it's only 10-20K per window *max*, then I'm all for it and I'll go ahead and review the patch.
I checked and it all depends on your memory cache settings. I tested it on top 20 sites at http://www.alexa.com/site/ds/top_500?p=BrowseCat_W_b_40_T1 with a 0 memory cache, and the peak was 65k from msn.com. With the standard 4M cache, I see peak tilecache size of 200k. (Sidenote: the tilecache memory isn't included in the Memory Cache, since nsIImage doesn't have a reference to mCacheEntry.)
How about just caching the last N (say 5) tilings? That bounds your memory usage and probably has little noticeable performance effect (tilings for the current page(s) will probably stay in the cache).
The way it's set up now is that each nsIImage can have it's own tile cache. In order to do a last N, we'd have to have some sort of static array storing which nsIImages have tilecaches. Do-able, but I'm not sure if that's the best choice. If only there was a way to tell when a images is not linked to an open window/page. Well, there probably is in layout, but not accesible in nsIImage. hmm, I'll try the static array.
Attachment #111733 - Attachment is obsolete: true
Comment on attachment 111941 [details] [diff] [review] TileCache w/array oh, there no longer appears to be a needs-work status for patches... hmm..
Attachment #111941 - Flags: review-
I'm futuring work on this bug. Although I can get a 30% speed increase for PNGs & GIFs and an even greater increase for GIFs, I have found another way to get similar speed gains with less work and wihout using a tile cache. I'll file a bug.
Target Milestone: --- → Future
That should read "30% speed increase for PNGs & JPGs" Other bug is Bug 189620.
Keywords: testcase
Paper, since bug 189620 isn't going anywhere, is there any progress to be reported here ?
Blocks: 203448
QA Contact: tpreston → image.gfx
Product: Core → Core Graveyard
No longer blocks: 203448
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: