[Webkit-unassigned] [Bug 37308] [Chromium] Support HTML5 <progress> element on Windows.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=37308





--- Comment #11 from MORITA Hajime <morrita at google.com>  2010-04-21 10:20:04 PST ---
Hamaji-san, Tamura-san, thank you for reviewing.

(In reply to comment #8)
> So, please add a comment about why you chose 0.033 and 60, and add FIXME if you
> think we need to improve them.
Added a comment.

> 
> BTW,
> http://msdn.microsoft.com/en-us/library/bb760842(v=VS.85).aspx
> It seems the default interval is 30 msec.  So progressAnimationFrameRate=0.033
> is reasonable.
Thank you for your investigation! I included this link in the comment.

(In reply to comment #9)
> > +double RenderThemeChromiumWin::animationDurationForProgressBar(RenderProgress* o) const
> I'm not sure if the name 'o' is good for an object of RenderProgress. I would
> say renderProgress or something like this.
Fixed.

> 
> > +    if (o->position() < 0)
> 
> I couldn't understand why this is necessary. If this is necessary, don't we
> need to modfify RenderThemeMac as well?
Progress bars on windows bar has an animation only when it is indeterminate.
Progress bars on mac has animations both for determinate and for indeterminate. 
So we need this only for Windows port.

> > +    int fillPart;
> > +    IntRect fillRect;
> > +
> > +
> 
> Unnecessary blank line(s). I guess we need no blanklines here.
Fixed.

> 
> > +        int dx = r.width() * renderProgress->animationProgress() * 2.0 - r.width();
> 
> Maybe we should use 2 instead of 2.0. (See Floating point literals in
> http://webkit.org/coding/coding-style.html)
Fixed.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.