The default bug view has changed. See this FAQ.

Make sure CSS text attributes are performant - use nsIFrame instead of computed style

RESOLVED FIXED in mozilla13

Status

()

Core
Disability Access APIs
RESOLVED FIXED
9 years ago
5 years ago

People

(Reporter: Aaron Leventhal, Assigned: surkov)

Tracking

(Blocks: 3 bugs, {access, perf})

unspecified
mozilla13
access, perf
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
In patch for bug 34759 Surkov is implementing text attributes. For now he uses GetComputedStyle(), which is fine for testing. However, Roc expressed concerned that GetComputedStyle() is very slow -- much slower than getting info from the frame. We should either just take his word for it or do some testing and possibly change to use the frame.
(Reporter)

Updated

9 years ago
Summary: Make sure text attributes are performant → Make sure CSS text attributes are performant - use nsIFrame instead of computed style
(Assignee)

Comment 1

9 years ago
(In reply to comment #0)
> In patch for bug 34759 Surkov is implementing text attributes. For now he uses
> GetComputedStyle(), which is fine for testing. However, Roc expressed concerned
> that GetComputedStyle() is very slow -- much slower than getting info from the
> frame. We should either just take his word for it or do some testing and
> possibly change to use the frame.
> 

GetComputedStyle() uses nsComputedDOMStyle that calculates styles on response and has complicated logic at the first glance. I don't get why this logic is surplus for us and how nsIFrame can help here.
I would do testing before changing anything, although you might find that getting information from the frame (e.g. via GetStyleText etc) actually gives simpler code.

OTOH I'm not 100% sure the accessibility module can get that data since you don't link to gklayout.
(Assignee)

Comment 3

9 years ago
(In reply to comment #2)
> I would do testing before changing anything, although you might find that
> getting information from the frame (e.g. via GetStyleText etc) actually gives
> simpler code.

nsComputedDOMStyle uses GetStyleText(). I just can't understand why the logic of nsComputedDOMStyle is overkill for us? Or is the code nsComputedDOMStyle not optimal? Or does creation of nsComputedDOMStyle takes long time/much memory? Where is a weak place of nsComputedDOMStyle?
It converts everything to an nsIDOMCSSValue XPCOM object, which involves memory allocation, and often converts values to strings which you have to then parse again to use. It's not a huge problem, just extra overhead and more work for you as the user of the API.
(Assignee)

Updated

9 years ago
Blocks: 389800
Status?  Maybe bug 467146 should wait on this?
(Assignee)

Comment 6

8 years ago
(In reply to comment #5)
> Status?  Maybe bug 467146 should wait on this?

I think they aren't related. Sure if the current approach doesn't fit to this then you can use approach suggested here like we have for background-color.

Updated

7 years ago
Depends on: 531850

Updated

7 years ago
Blocks: 531850
No longer depends on: 531850
(In reply to comment #0)
> In patch for bug 34759

This was actually bug 345759
(Assignee)

Comment 8

5 years ago
fixed by bug 728907
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
You need to log in before you can comment on or make changes to this bug.