Native Themes With Cairo: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
m (Reverted edit of Pawxava, changed back to last version by VladVukicevic) |
||
| Line 1: | Line 1: | ||
<pre> | |||
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 | |||
buttons | |||
19:25 < roc> also, quite a lot of widget/state combos don't paint anything at | |||
all | |||
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 | |||
</pre> | |||
Latest revision as of 10:59, 25 November 2006
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
buttons
19:25 < roc> also, quite a lot of widget/state combos don't paint anything at
all
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