Send plymouth mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/plymouth
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of plymouth digest..."
Today's Topics:
1. Re: plymouth performance (Ray Strode)
2. Re: plymouth performance (Daniel Drake)
3. patches for displaying messages (brejc8) and correctly
erasing dirty areas (halfline, brejc8, me) (Philip Stark)
4. Re: plymouth performance (Ray Strode)
----------------------------------------------------------------------
Message: 1
Date: Thu, 11 Jun 2009 15:26:34 -0400
From: Ray Strode <[email protected]>
Subject: Re: plymouth performance
To: Daniel Drake <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
> For the "without" tests, I removed the rhgb kernel parameter parameter
> and added console=tty0
Alright, so it's not actually "without plymouth" but "without plymouth
splash". plymouth is still running filtering and logging boot
messages.
> On the XO-1:
>
> Without plymouth: 61.53 seconds bootup time
> With plymouth: 79.82 seconds bootup time
> +18.29 seconds increase, or 30% regression
>
> On the XO-1.5:
>
> Without plymouth: 24.78 seconds bootup time
> With plymouth: 27.07 seconds bootup time
> +2.29 seconds increase, or 10% regression
>
> We have a similar problem with OLPC's boot animation code on the XO-1.
> We recently found out that it slows down boot by about 15 seconds with
> just a simple animation.
Which splash plugin are you using? Plymouth does all pixel
manipulation in software. There's no gpu acceleration, and we don't
use mmx or sse or anything like that, so there's no cpu acceleraton
either.
A splash plugin that loads a lot of images or does a lot of full
screen updates will be slower than one that loads a few images and
just updates small parts of the screen.
For instance, I would expect fade-throbber to be a lot faster than say two-step.
> However, two superheroes came along and implemented an awesome new
> algorithm which only redraws the parts of the screen that have changed
> from the last frame.
We're most of the way there in plymouth. We have a function:
ply_window_erase_area (window, x, y, width, height);
That calls into the splash plugin and tells it to clear just that area
of the screen.
So normally an animation on screen would do
/* queue future draw requests instead of going immediately to the hardware */
ply_frame_buffer_pause_updates (fb);
/* erase the old frame */
ply_window_erase_area (window, x, y, old_width, old_height);
/* draw the new frame */
ply_frame_buffer_fill_with_argb32_data (fb, {x, y, new_width,
new_height}, ... new frame data ...);
/* flush to the hardware */
ply_frame_buffer_unpause_updates (fb);
which in theory would cause only the changed parts to get drawn to the
framebuffer.
ply_frame_buffer_fill_with_argb32_data doesn't draw straight to the
frame buffer though. Instead it draws to an intermediary shadow
framebuffer so that blending is fast, and so that you don't end up
with intermediary drawing on the screen. It doesn't flush the shadow
framebuffer to the actual hardware until the
ply_frame_buffer_unpause_updates() is called. It knows how much of
the shadow buffer to flush to the hardware by keeping track of the
area of the rectangles passed to the frame buffer fill functions while
the frame buffer was paused.
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.
--Ray
------------------------------
Message: 2
Date: Thu, 11 Jun 2009 20:29:56 +0100
From: Daniel Drake <[email protected]>
Subject: Re: plymouth performance
To: Ray Strode <[email protected]>
Cc: [email protected]
Message-ID: <1244748596.2344.60.ca...@polyethylene>
Content-Type: text/plain
On Thu, 2009-06-11 at 15:26 -0400, Ray Strode wrote:
> Which splash plugin are you using? Plymouth does all pixel
> manipulation in software. There's no gpu acceleration, and we don't
> use mmx or sse or anything like that, so there's no cpu acceleraton
> either.
>
> A splash plugin that loads a lot of images or does a lot of full
> screen updates will be slower than one that loads a few images and
> just updates small parts of the screen.
>
> For instance, I would expect fade-throbber to be a lot faster than say
> two-step.
Thanks for the response! I'm using the spinfinity theme from F11 which
uses the throbgress module.
Daniel
------------------------------
Message: 3
Date: Fri, 12 Jun 2009 00:35:29 +0200
From: Philip Stark <[email protected]>
Subject: patches for displaying messages (brejc8) and correctly
erasing dirty areas (halfline, brejc8, me)
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi all,
My name is Philip Stark, i am a developer for the Chakra Project.
(chakra-project.org)
We want to use Plymouth as our bootsplash and thus I started to poke
halfline on IRC to help me to get Plymouth to work on our systems which
works like a charm now (thanks again, halfline)
because we would like to display some messages during boot, brejc8 was
so nice as to write a patch for two-step to implement that behaviour.
resulting from that functionality, we discovered a bug in the label
plugin which resulted in a failure to erase the area that a text box
occupied before it's content changed.
attached are the two patches.
cheers Philip Stark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: twostep_message.patch
Type: application/octet-stream
Size: 2890 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/plymouth/attachments/20090612/1d1ba024/attachment-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: erase_dirty_area.patch
Type: application/octet-stream
Size: 1301 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/plymouth/attachments/20090612/1d1ba024/attachment-0003.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url :
http://lists.freedesktop.org/archives/plymouth/attachments/20090612/1d1ba024/attachment-0001.pgp
------------------------------
Message: 4
Date: Thu, 11 Jun 2009 23:52:04 -0400
From: Ray Strode <[email protected]>
Subject: Re: plymouth performance
To: Daniel Drake <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi Daniel,
On Thu, Jun 11, 2009 at 3:26 PM, Ray Strode<[email protected]> 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
------------------------------
_______________________________________________
plymouth mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/plymouth
End of plymouth Digest, Vol 9, Issue 3
**************************************
