Closed Bug 159512 Opened 22 years ago Closed 22 years ago

Poor performance on moving images that need to be scaled

Categories

(Core :: Layout, defect, P3)

x86
Windows XP
defect

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: markushuebner, Assigned: dcone)

References

()

Details

(Keywords: perf, testcase)

Attachments

(1 file)

There are two testcases: http://www.formula-one.nu/mozilla/timeouttest.htm [mozilla has to scale and move the image] http://www.world-direct.com/mozilla/timeouttest.htm [mozilla has to move the image / no scaling] using trunk build 2002072408 on win-xp pro,1.1ghz,512ram the first testcase is taking double the time than the second. attaching testresults ...
Attached file testresults with latest trunk build (deleted) —
Blocks: 117436
Keywords: perf, testcase
FYI: The scale-and-move testcase is only about 12% slower than the move-only testcase on Linux/X11/GTKfe.
So... The issue is just that we don't keep scaled versions of images in memory to save RAM. In this case that means we have to scale it every ... what? Reflow? Repaint?
bz, my guess, based on no data whatsoever, is that the scaling is done in nsImageWin::Draw, which (I suppose) gets called for every Repaint.
win2k, sp2, 512 mb ram, pIII 1Ghz. the scaled image test takes 40% more time consistently 140 vs 100.
We do scale the images every time.. the reason is that the high resolution.. normal verions could be needed for printing (high res ouput), or an unscaled version is needed somewhere else.. so we cache this unscaled version.
we scale at draw time for numerous reasons. we've all discussed them in the past so i'm not going to hash them all back out here.
Pav is correct this has been hashed out before, and we do things the way we do for good reasons. There are cases (some DHTML, pages with repeated copies of the same scaled image) where a cached copy of the scaled image would come in handy). The only idea I have would be some form of separate (and small) scaled-image-cache, perhaps with size limits. This would speed up the more common usages without costing a lot of memory. If someone would like to try out this idea, we could certainly test how it helps/hurts performance and memory usage. Post a patch and it will get attention.
I have the same thoughts as Randal does in Comment #8. If a scaled version of the image is < xxxx bytes, then create a cache of it. Maybe make xxxx a *cough*yet another*cough* pref. IMO, this bug is the only way Bug 98971 will get implemented. Bilinear (or bicubic) scale only once, and cache it. This bug is on the list of things I want done (and may eventually do if no one else does it), but it's probably just above Bug 36351 in my list, and that's pretty darn low.
Sorry Randell for mispelling your name so badly :O
QA Contact: petersen → moied
Priority: -- → P3
-> dcone
Assignee: attinasi → dcone
Target Milestone: --- → Future
Blocks: 21762
Tested with 10 ms delay and 60 balls. Mozilla 20021210: 120 :: 50 200 :: 20 290 :: 30 370 :: 30 451 :: 20 531 :: 20 611 :: 20 691 :: 20 781 :: 20 861 :: 20 941 :: 20 1021 :: 20 1112 :: 31 1192 :: 20 1272 :: 20 1352 :: 20 1432 :: 20 1522 :: 30 1602 :: 20 1682 :: 20 1772 :: 20 1853 :: 20 1943 :: 30 2033 :: 20 2113 :: 20 2193 :: 20 2283 :: 30 2373 :: 20 2453 :: 20 2544 :: 30 2624 :: 20 2704 :: 20 2794 :: 30 2874 :: 20 2954 :: 20 3044 :: 30 3124 :: 20 3205 :: 20 3285 :: 20 3375 :: 30 3455 :: 20 3535 :: 20 3615 :: 20 3705 :: 30 3805 :: 30 3886 :: 21 3966 :: 20 4056 :: 30 4136 :: 20 4216 :: 20 IE6: 110 :: 90 230 :: 100 340 :: 90 451 :: 91 561 :: 90 671 :: 90 781 :: 90 891 :: 90 991 :: 80 1091 :: 80 1192 :: 81 1292 :: 80 1392 :: 80 1482 :: 80 1582 :: 80 1682 :: 80 1772 :: 80 1873 :: 81 1973 :: 80 2063 :: 80 2163 :: 80 2273 :: 90 2393 :: 100 2503 :: 90 2614 :: 91 2714 :: 80 2814 :: 80 2904 :: 70 3014 :: 90 3104 :: 80 3194 :: 70 3285 :: 71 3375 :: 70 3465 :: 70 3555 :: 70 3655 :: 80 3745 :: 80 3835 :: 70 3926 :: 71 4016 :: 70 4106 :: 70 4186 :: 60 4276 :: 70 4366 :: 70 4446 :: 60 4536 :: 70 4637 :: 81 4717 :: 70 4807 :: 70 4887 :: 70 Opera7: 981 :: 100 1983 :: 101 2964 :: 110 3925 :: 80 4887 :: 80 5868 :: 100 6830 :: 91 7811 :: 90 8742 :: 60 9654 :: 40 10585 :: 50 11506 :: 50 12448 :: 50 13409 :: 90 14370 :: 80 15322 :: 80 16283 :: 90 17254 :: 90 18216 :: 90 19147 :: 50 20089 :: 50 21000 :: 40 21931 :: 50 22853 :: 51 23774 :: 50 24685 :: 40 25647 :: 91 26598 :: 80 27559 :: 90 28531 :: 80 29492 :: 80 30474 :: 91 31435 :: 90 32366 :: 50 33288 :: 51 34209 :: 50 35130 :: 50 36052 :: 51 36963 :: 40 37904 :: 50 38836 :: 51 39777 :: 50 40698 :: 50 41650 :: 81 42631 :: 90 43582 :: 80 44554 :: 90 45515 :: 80 46477 :: 81 47448 :: 90
Basing on my last comment, we can probably close this as wfm or fixed.
this one is wfm
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
No longer blocks: 21762
Blocks: 21762
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: