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 (Charlie Brej)
2. Scripted plugin overview (Charlie Brej)
----------------------------------------------------------------------
Message: 1
Date: Mon, 15 Jun 2009 20:29:29 +0100
From: Charlie Brej <[email protected]>
Subject: Re: plymouth performance
To: Ray Strode <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 12/06/09 04:52, Ray Strode wrote:
> 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.
Could you take a look at this patch? It is a bit complicated but I think it
does
the job. The sprites in the plugins I wrote have the same problem and it may be
an idea to create a "ply-area" in libply to reuse the code.
> 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.
I have in the past used callgrind and kcachegrind for profiling plymouth, with
an added bonus of being able to see how the program behaves on a ~10 times
slower system.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: overlap.patch
Url:
http://lists.freedesktop.org/archives/plymouth/attachments/20090615/8d7f95e0/attachment-0001.ksh
------------------------------
Message: 2
Date: Tue, 16 Jun 2009 11:41:13 +0100
From: Charlie Brej <[email protected]>
Subject: Scripted plugin overview
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I have pushed the scripted plugin into the git as a branch "scripted-plugin".
It
has been written in my coding "style" and I will go through to correct it all
soon. The point of this email is to just present the syntax of the scripted
language and see if people have ideas to what is desired. Most of these are not
concious design choices but rather that's the way the pieces fell when trying
to
make a minimal language so please say which bits are undesirable.
The general syntax is pretty C like with semicolons. There are four internal
types: NULL, int, string and hash (float will be added soon). You don't have to
declare a variable or its type before you use it. If you read a variable which
has not been set its value will be NULL. Ints allow all the usual operations
and
comparisons. Strings can be concatenated using a plus. Operations between types
that are not compatible give a NULL. To access an element of a hash you can
either use or square brackets with the value to index by (hash["element"] or
index="element"; hash[index]) or if the index is a string you can use the dot
notation (hash.element). When using int as a hash index (equivalent of an
array)
it gets translated into a string (hash[10] is equivalent to hash["10"]). When
assigning one var to another, if it is a string or an int the object is
duplicated, otherwise a reference is made.
There are two contexts (local and global). If a variable is used (read or
written to) it is looked for in the local context (even if equal to NULL), if
not found then it is looked for in the global context, if not found it is
created in the local context. The two contexts are actually hashes and which
can
be accessed to force a variable to be looked for in that context only by using
"local" and "global" (e.g. global.var = 0). There is no scoping within {}
blocks.
Functions are defined with "fun function_name (par1, par2){body}". When called
par1 and par2 in the local context get set with the first two parameters passed
in. If fewer are passed in then they are unset (NULL when read). If a function
fails to return a value or reaches the end it returns a NULL.
On the implementation side the code is 3,000 lines of code so not too heavy and
runs at the order of 1 MIPS. The system allows additional native types and
functions to be added which can represent native C implementations. Image and
sprite are two examples where a new object type is introduces along with some
functions to interact with it. Some functions which do not need any raw C can
be
described directly in a script. These scripts are escaped (using perl) and
#included in the compiled code and parsed/executed at startup. Garbage
collection is done by reference counting which can lead to memory leaks in
cyclicly referencing objects.
------------------------------
_______________________________________________
plymouth mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/plymouth
End of plymouth Digest, Vol 9, Issue 4
**************************************
