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)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: markushuebner, Assigned: dcone)
References
()
Details
(Keywords: perf, testcase)
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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 ...
Reporter | ||
Comment 1•22 years ago
|
||
Reporter | ||
Updated•22 years ago
|
Comment 2•22 years ago
|
||
FYI: The scale-and-move testcase is only about 12% slower
than the move-only testcase on Linux/X11/GTKfe.
Comment 3•22 years ago
|
||
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?
Comment 4•22 years ago
|
||
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.
Comment 5•22 years ago
|
||
win2k, sp2, 512 mb ram, pIII 1Ghz. the scaled image test takes 40% more time
consistently 140 vs 100.
Assignee | ||
Comment 6•22 years ago
|
||
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.
Comment 7•22 years ago
|
||
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.
Comment 8•22 years ago
|
||
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.
Comment 9•22 years ago
|
||
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.
Comment 10•22 years ago
|
||
Sorry Randell for mispelling your name so badly :O
Updated•22 years ago
|
QA Contact: petersen → moied
Comment 12•22 years ago
|
||
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
Comment 13•22 years ago
|
||
Basing on my last comment, we can probably close this as wfm or fixed.
Reporter | ||
Comment 14•22 years ago
|
||
this one is wfm
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•