Native Themes With Cairo

From MozillaWiki
Jump to: navigation, search
19:20 <@vlad> native theme stuff is ridiculously slow on linux
19:20 < roc> vlad: I know. What's your plan?
19:20 <@vlad> not sure yet
19:20 < roc> Do you remember my plan?
19:21 <@vlad> the one that you implemented? or another plan?
19:21 < roc> vlad: a speedup plan
19:21 <@vlad> render offsceen, recover alpha, composite?
19:21 <@vlad> hmm, no
19:23 < roc> vlad: whitelist native themes as being "well behaved". A well
             behaved theme draws the same contents for a given widget type,
             state and size
19:23 <@vlad> hmm, I'm not sure that I heard this plan
19:23 <@vlad> and if its well-behaved, we cache or something?
19:23 < roc> vlad: then, cache cairo surfaces for widget renderings
19:23 < roc> ALSO
19:24 < roc> for each widget type+state, keep track of the maximum width and
             maximum height we've seen rendered
19:24 <@vlad> oh, also.. do we really need to recover alpha?
19:25 < roc> vlad: yes. GNOME Industrial, for example, uses transparency in the
19:25 < roc> also, quite a lot of widget/state combos don't paint anything at
19:25 < roc> apparently
19:26 <@vlad> does it use 8-bit transparency or 1-bit transparency?
19:26 < roc> for each type+state, remember if we've ever seen 1) anything drawn
             at all 2) any transparency
19:26 < roc> vlad: 1-bit
19:26 <@vlad> ok
19:26 <@vlad> so for 1-bit
19:26 < roc> chromakey?
19:26 <@vlad> if we attach a picture to a Pixmap
19:26 <@vlad> and clear to fully transparent first
19:27 < roc> does it work?
19:27 <@vlad> yeah
19:27 < roc> sweet
19:27 < roc> okay
19:27 <@vlad> that should speed things up dramatically
19:27 < roc> then for each type+state, remember if we've ever seen 1) anything
             drawn at all 2) any transparency 3) any translucency
19:28 < roc> if we get a request to paint a widget type+state at a size that is
             smaller than we've already painted in both the horizontal and
             vertical directions, then we believe it's no more complex than
             what we've already seen
19:28 < roc> oh, we also check for 4) painting of a single solid color
19:28 <@pav> roc: ok, i fixed the os2 thing and a similar thing on windows
             (some errors in the patch)
19:28 <@vlad> yeah
19:28 < roc> then we can optimize in the obvious ways
19:28 <@pav> anything else?
19:29 < roc> any theme that does something silly like paint a translucent image
             for small widget sizes and an opaque one for large sizes will not
             be marked as "well behaved"
19:29 <@vlad> yep
19:29 < roc> and we will do the horrible slow thing
19:29 <@vlad> that's fine
19:29 < roc> yeah
19:29 < roc> it is
19:29 <@vlad> people who are using those themes are already horrible and slow
19:30 < biesi> how do you detect translucency?
19:30 < biesi> if all you have is a Pixmap with 1-bit transparency
19:30 < roc> paint onto white and paint onto black and analyze
19:30 < roc> "paint nothing" and "paint a solid color" are pretty darn common
             so if we detect those we'll actually end up with something faster
             than what we have now, I think
19:31 < biesi> can that go away with the cairo-using gtk 2.8?
19:31 < roc> no
19:31 < roc> it can't
19:31 < roc> because themes are still allowed to use X calls to draw
19:31 < roc> that's the biggie problem