plymouth performance

[Ray Strode]

Hi Daniel,

On Thu, Jun 11, 2009 at 3:26 PM, Ray Strode<halfline at gmail.com> wrote:
> This means, ideally, we should only redraw the parts of the screen
> that have changed when the frame buffer is unpaused. The
> implementation is a little naive, though.  It looks at the bounding
> rectangle of all the fill calls in aggregate.  That is if there's a
> drawing on the top-left corner of the screen and a drawing on the
> bottom-right corner of the screen, then it will essentially do a full
> screen update.
>
> To make this more efficient we'd need to introduce a  "region" data
> type that's composed of a list (or sorted tree) of area rectangles.
> We'd then flush each rectangle one by one, instead of flushing the one
> aggregate bounding box.  I don't think it would be *that* hard, it's
> just never been a priority before.
I worked a bit on this tonight:

http://cgit.freedesktop.org/plymouth/commit/?id=ffec2f1e6701773ddf399c15ab954ed08e561064
http://cgit.freedesktop.org/plymouth/commit/?id=a741222aca6b7bceebe002e5c01a3825088c2987
http://cgit.freedesktop.org/plymouth/commit/?id=bed202ac28519b4c23e75f017a41b024e49b8161

Instead of having one bounding box of what to flush, I now keep a list
of rectangles and flush them one by one.
Since the rectangles can in theory overlap, I had a little logic to
try to eliminate duplicate work, but it's not as sophisticated as it
could be.

I haven't given it a lot of testing yet, so I may have broken things.
I would appreciate it if you retimed things with these changes to see
if it makes a difference. I'd also appreciate if you did some timings
with different themes (maybe text and fade-in?), so we can see how
dependent on the splash the slow down is.

If those commits above don't help we may want to add some profiling
hooks into plymouth to get a clearer idea where the time is being
spent.

--Ray