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. Two plugin-rework patches (Charlie Brej)
2. Re: olpc boot splash (Charlie Brej)
3. Re: Two plugin-rework patches (Ray Strode)
4. Re: Two plugin-rework patches (Charlie Brej)
5. Re: Two plugin-rework patches (Ray Strode)
----------------------------------------------------------------------
Message: 1
Date: Thu, 07 May 2009 23:28:04 +0100
From: Charlie Brej <[email protected]>
Subject: Two plugin-rework patches
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
test.patch has some additional lines to the makefiles to allows the tests
compile. (ply-list.c/h were needed whenever ply-logger was used and
DPLYMOUTH_PLUGIN_PATH were needed by boot_splash_test)
fade.patch is a review request as I am unsure about a couple things. It creates
a new image data block with the fade being done by weighting the data from each
image. This is then drawn on the screen.
Firstly it breaks progress_animation->transition type choice as there isn't one
any more. Secondly I am unsure why when transitioning between images of
different sizes but keeping a single frame_area didn't draw squiggles across
the
area. Its probably OK, but better just check if I have the right end of the
stick.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fade.patch
Type: text/x-patch
Size: 4046 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/plymouth/attachments/20090507/75d67133/attachment-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.patch
Type: text/x-patch
Size: 4207 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/plymouth/attachments/20090507/75d67133/attachment-0003.bin
------------------------------
Message: 2
Date: Fri, 08 May 2009 11:14:12 +0100
From: Charlie Brej <[email protected]>
Subject: Re: olpc boot splash
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Ray Strode wrote:
> Hi,
>
> On Thu, May 7, 2009 at 5:54 AM, Charlie Brej <[email protected]> wrote:
>> Re. the ply-key-file.c key reading code. You know there are hash tables now?
> I do remember you adding them, but admittedlly I forgot it was
> available when I through together ply-key-file.c
>
>> I can migrate the code from key lists to hash tables if you like.
> Sure, it makes a lot of sense. Although, in practice I dont know that
> we'll get much in the way of wins out of it just because the files are
> so small (1 to 2 groups per file, a handful of entries per group).
>
> When I wrote GKeyFile for glib, I ended up using both a hash table and
> a list because I needed to retain ordering when saving. Saving isn't
> relevant here though.
>
> --Ray
Patch attached. I did a deep free but value fetches are strdupped so it should
cause no problems.
btw Ignore that frame_area thing in the prev email. I thought there images of
different sizes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: key-file-hash.patch
Type: text/x-patch
Size: 4433 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/plymouth/attachments/20090508/586fd3e3/attachment-0001.bin
------------------------------
Message: 3
Date: Fri, 8 May 2009 10:27:38 -0400
From: Ray Strode <[email protected]>
Subject: Re: Two plugin-rework patches
To: Charlie Brej <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
On Thu, May 7, 2009 at 6:28 PM, Charlie Brej <[email protected]> wrote:
> test.patch has some additional lines to the makefiles to allows the tests
> compile. (ply-list.c/h were needed whenever ply-logger was used and
> DPLYMOUTH_PLUGIN_PATH were needed by boot_splash_test)
Sounds good, please push.
> fade.patch is a review request as I am unsure about a couple things. It
> creates a new image data block with the fade being done by weighting the
> data from each image. This is then drawn on the screen.
Isn't image_fade() nothing more than:
/* Fill with the old frame at full opacity */
ply_image_buffer_fill_with_argb32_data (...,previous_frame_data, ...)
/* Blend the new frame OVER the old frame at the current fade percentage */
ply_image_buffer_file_with_argb32_data_at_opacity (..., frame_data, percentage);
? If image_fade() doesn't add anything over doing those two lines,
then I guess I'd rather just have those two lines.
Looking at the orignal code, what I wrote was clearly broken, though.
It looks like it would blend the background into the result even in
areas where the object is opaque.
> Firstly it breaks progress_animation->transition type choice as there isn't
> one any more.
That's probably okay, although we should take it out of the api if it
doesn't work.
> Secondly I am unsure why when transitioning between images of
> different sizes but keeping a single frame_area didn't draw squiggles across
> the area.
Yea, I don't think we have a defined behavior for using frames of
different sizes around.
--Ray
------------------------------
Message: 4
Date: Fri, 08 May 2009 17:05:45 +0100
From: Charlie Brej <[email protected]>
Subject: Re: Two plugin-rework patches
To: Ray Strode <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Ray Strode wrote:
> Hi,
>> fade.patch is a review request as I am unsure about a couple things. It
>> creates a new image data block with the fade being done by weighting the
>> data from each image. This is then drawn on the screen.
> Isn't image_fade() nothing more than:
>
> /* Fill with the old frame at full opacity */
> ply_image_buffer_fill_with_argb32_data (...,previous_frame_data, ...)
>
> /* Blend the new frame OVER the old frame at the current fade percentage */
> ply_image_buffer_file_with_argb32_data_at_opacity (..., frame_data,
> percentage);
>
> ? If image_fade() doesn't add anything over doing those two lines,
> then I guess I'd rather just have those two lines.
The difference being that any partially transparent parts of the overlay frames
will be drawn twice (although not as strongly the second time) and thus receive
a double dose of the partly transparent foreground colour. On the filling
circle, the only parts this effects is the edges which throb as there is a
sudden step between showing two superimposed images and a single image. You can
only see it properly in the last frames of the filling sequence.
------------------------------
Message: 5
Date: Fri, 8 May 2009 14:41:53 -0400
From: Ray Strode <[email protected]>
Subject: Re: Two plugin-rework patches
To: Charles Brej <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
> The difference being that any partially transparent parts of the overlay
> frames will be drawn twice (although not as strongly the second time) and
> thus receive a double dose of the partly transparent foreground colour. On
> the filling circle, the only parts this effects is the edges which throb as
> there is a sudden step between showing two superimposed images and a single
> image. You can only see it properly in the last frames of the filling
> sequence.
Oh that makes sense. Yea, please push it. Thanks!
At some point i'd like to move all the pixel munging functions (like
bluring, blending, the halo thing in solar) to convenience functions
so each plugin doesn't have to do it itself.
On a different note, I think at some point it may make sense to merge
parts of ply_image and ply_frame_buffer into a new ply_pixel_buffer.
At the end of the day both things are just pixels after all and it
would be useful if there was a common interface for manipulating those
pixels. Also, having to do
ply_image_get_data() all the time just to feed it back into the
framebuffer is less than ideal.
Anyway, thanks for the review and fixes.
--Ray
------------------------------
_______________________________________________
plymouth mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/plymouth
End of plymouth Digest, Vol 8, Issue 6
**************************************
