[Webkit-unassigned] [Bug 36113] Optimize painting for HTMLProgressElement

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Mar 15 09:27:21 PDT 2010


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


Darin Adler <darin at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #50699|review?                     |review-
               Flag|                            |




--- Comment #2 from Darin Adler <darin at apple.com>  2010-03-15 09:27:21 PST ---
(From update of attachment 50699)
Thanks for tackling this.

> +    if (attribute->name() == valueAttr) {
> +        if (renderer())
> +            renderer()->updateFromElement();
> +    } else if (attribute->name() == maxAttr) {
> +        if (renderer())
> +            renderer()->updateFromElement();
> +    } else

Looks good.

> +    int position = (100 * element->position());

Where does this 100 come from? I don't think it makes sense to store a value
between 0 and 100. The progress indicator could be more than 100 pixels wide or
less than 100 pixels wide. I'm not sure exactly how to handle this, but what we
want to store is the actual number of pixels used in the theme's progress bar
drawing, which might mean some kind of cooperation with theme theme so you can
know how much of the progress indicator is devoted to the progress display. In
the mean time, the RenderProgress could instead just store the progress value
from the progress element as-is. Multiplying by 100 and converting to an
integer is unnecessary if that value, 100, is just an arbitrarily chosen
constant.

It seems that the Qt progress bar rendering code does require that the use of
integers to render the progress element. So the theme should multiply the
position value by something, but I suggest a value greater than 100, perhaps
numeric_limits<int>::max() to make best use of the precision available in an
integer.

I don't think the rule "repaint the entire indicator any time the value
changes" is optimal for the long run. If the indicator moves a very short
distance it would be best to repaint only the affected area. This may not be
possible for some platforms, such as Qt, but it would be good to design the
mechanism so we can do it.

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



More information about the webkit-unassigned mailing list