The second testcase at http://www.world-direct.com/mozilla-opacity-crash-testcase/ illustrates the performance problem when fading an element Mozilla flickers and is extremely slow. Using trunk build 2003022709 on winxp pro sp1, 1.1ghz, 512ram
Win98, build 2003022814, I see the performance problem, but wouldn't describe it as flickering. The fading occurs in noticeable steps, but I think this is correct.
Well, the performance is so bad that "flickering" would be too fast to say :) But seriously, don't know why Mozilla is that slow when fading through the individual steps of opacity. Maybe a profile would help here.
Assignee: other → roc+moz
Depends on: 193849
16 years ago
The testcase uses percentage opacity instead of number opacity. As I've repeatedly stated, percentage opacity is slower (due to it reframing every single time, unlike number opacity, which only reframes when changing to/from 1). I've also repeatedly stated that there are no plans to fix that, since percentage opacity should be removed rather than improved. So I'm very tempted to just mark this bug "stop wasting people's time, dammit". Not doing that for now in the feeble hope that Matic will fix the testcase to properly set opacity and there will still be a problem to fix.
I changed the code to use number opacity. The testcase has been updated. This seems to work fine, although it sometimes still shows a short flicker. Nonetheless it will crash in 1.3 builds. I would recommend to remove the percentage capability if it works so bad and can't be fixed as its presence draws people to just use it; one would normally await it to work correctly just like the other method.
Correction: the fader will not crash!
Sorry, i'm agreeing with Boris here. Lets stop duplicating bugs where we all know that someone works on it. You want this bug tio be fixed? Then help Robert with bug 193849. It's about opacity performance. To Comment #5. Percent opacity is not bugged right now (it was bugged long time ago - bug 144832 ), it's only slower. I'd leave this as it is. Suggesting DUPLICATE of bug 193849.
I can go with that decission - marking dupe. *** This bug has been marked as a duplicate of 193849 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
I think we should remove percentage opacity. It's just hurting us, it's not according to spec, and the sooner we remove it, the better. I'm reopening this bug to do just that. http://www.w3.org/TR/2002/WD-css3-color-20020418/#transparency Clearly a %-value is not valid according to CSS3.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Fading with moz-opacity flickers and is very slow → Remove %-based opacity values
16 years ago
Comment on attachment 116270 [details] [diff] [review] disable %-values for '-moz-opacity' Thank you.
Comment on attachment 116270 [details] [diff] [review] disable %-values for '-moz-opacity' Please wait for David to comment before checking in, though -- I seem to recall him having a definite opinion on this issue, but not what the opinion was.....
Sounds good to me.
Fix checked in.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
> From code wise, I prefer to use % -- it's much easy, intuitive. Really? You DO realize that "0.5" and "50%" typically mean DIFFERENT things in CSS properties that support both formats? And in particular that they meant different things for -moz-opacity? There was nothing easy or intuitive about percentage opacity. It's removed. It will NOT be reinstated. Trivial changes to your JS (replacing |+ "%"| with |/ 100|) will make it work.
You need to log in before you can comment on or make changes to this bug.