Yes , I tried this solution on my end once as per Alsroot's
suggesstion of implementing alpha pulsing instead of the present
scenario but that did not solve the problem much as you may have
noted due to the main problem lying in the rendering time of the
startup frame of the animation.
On Thu,
On Sun, Oct 31, 2010 at 3:44 AM, Martin Dengler mar...@martindengler.comwrote:
On Sat, Oct 30, 2010 at 12:09:53AM +0530, Anurag Chowdhury wrote:
Uptill now what we have gathered from this issue is:
1) We can improve this issue by using a cache system or cairo operation:
I think
Since , now we all seem to reach on a common proposal of agreement for
the above issue . And since Gary has confirmed a noticeable
improvement in the reduction of the delay time due to the changes
applied by the v5 patch and some more tweaks
discussed in the thread , so I think we can move to
On Mon, Nov 01, 2010 at 03:42:05PM +, Gary Martin wrote:
Just to be clear, I preferred Martin Dengler's resolution of the
issue, it fixes an inefficiency rather than adding code to work around
it: [...]
I agree.
I'm not sure consensus has been reached on the other changes.
--
James
On Sat, Oct 30, 2010 at 12:09:53AM +0530, Anurag Chowdhury wrote:
Uptill now what we have gathered from this issue is:
1) We can improve this issue by using a cache system or cairo operation:
I think the problem is the code is rendering the svg icon every time
the color is
On Fri, Oct 29, 2010 at 05:51:35PM -0400, Martin Langhoff wrote:
The same (potentially complex) SVG is being rendered in 2 tones, many
times. This is nonsense.
Render it once to a B/W grayscale raster. Then use/abuse whatever
cairo bitblit blend operators.
[...]
Maybe I am making wild
On Thu, Oct 28, 2010 at 03:44:37PM -0300, Gonzalo Odiard wrote:
I think the problem is the code is rendering the svg icon every time
the color is changed.
Indeed. As James Cameron pointed out, we're setting the stroke and
fill in rapid succession, resulting in two calls to render().
There
On Fri, Oct 29, 2010 at 10:56:25AM +1100, James Cameron wrote:
On Thu, Oct 28, 2010 at 03:44:37PM -0300, Gonzalo Odiard wrote:
I think the problem is the code is rendering the svg icon every time
the color is changed. There are not cache or cairo operation used to
avoid this.
I agree.
On Fri, Oct 29, 2010 at 09:47:33AM +0100, Martin Dengler wrote:
On Fri, Oct 29, 2010 at 10:56:25AM +1100, James Cameron wrote:
On Thu, Oct 28, 2010 at 03:44:37PM -0300, Gonzalo Odiard wrote:
I think the problem is the code is rendering the svg icon every time
the color is changed. There
On Fri, Oct 29, 2010 at 09:47:33AM +0100, Martin Dengler wrote:
+N = 10.0
+self._level = round((math.sin(self._phase) + 1) / 2, 3)
...and I didn't see much change with my test program[1]:
Ah, right. Sorry I missed that. round(x, 3) will get you 1000 unique
images. Perhaps
On 29 Oct 2010, at 09:12, Martin Dengler mar...@martindengler.com wrote:
On Thu, Oct 28, 2010 at 03:44:37PM -0300, Gonzalo Odiard wrote:
I think the problem is the code is rendering the svg icon every time
the color is changed.
Indeed. As James Cameron pointed out, we're setting the stroke
On Thu, Oct 28, 2010 at 1:42 PM, Martin Dengler
mar...@martindengler.com wrote:
There is a better way: use cProfile and gprof2dot.py. You will get
graphs (and of course the raw data) like this:
http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-stats-graph.png
Excellent graph.
But
On Wed, Oct 27, 2010 at 11:15:01PM +0530, Anurag Chowdhury wrote:
I carried out the same benchmark test, which I earlier conducted on an
XO-1.5 , on a X0-1 .
Please tell us what the test is/was. How many times did you run it?
How did you make sure nothing else interfered with the system cpu
I have attached the pulsingicon.py file in which I placed the
benchmark script to test the time taken by update function everytime
it is called.
I used the time.time() function to measure the time taken to process
the update step.
And If you may compare the odd steps of both logs i.e the numbers
I'm sorry to harp on this, but I hope you can see it actually takes
quite some effort to communicate this stuff well...
On Thu, Oct 28, 2010 at 09:27:18PM +0530, Anurag Chowdhury wrote:
I have attached the pulsingicon.py file
Thanks - very useful to understand what you're timing.
in which I
I think the problem is the code is rendering the svg icon every time
the color is changed.
There are not cache or cairo operation used to avoid this.
Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
Certainly that seems to me as a possible reason behind this issue ,
but in the present state we need to decide exactly on what future we
want for this pulsing icon i.e. keep it , improve it or replace it.
On Fri, Oct 29, 2010 at 12:14 AM, Gonzalo Odiard gonz...@laptop.org wrote:
I think the
On Thu, Oct 28, 2010 at 11:12 PM, Martin Dengler
mar...@martindengler.com wrote:
I'm sorry to harp on this, but I hope you can see it actually takes
quite some effort to communicate this stuff well...
On Thu, Oct 28, 2010 at 09:27:18PM +0530, Anurag Chowdhury wrote:
I have attached the
On Thu, Oct 28, 2010 at 06:42:53PM +0100, Martin Dengler wrote:
http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-stats-graph.png
Nice. A question on interpretation ... is the number of renderings
consistent with the number of __pulse_cb callbacks?
Looking at the bright green costly
On 28 Oct 2010, at 00:17, James Cameron qu...@laptop.org wrote:
On Wed, Oct 27, 2010 at 11:15:01PM +0530, Anurag Chowdhury wrote:
I carried out the same benchmark test, which I earlier conducted on an
XO-1.5, on a XO-1. And I have attached the log files obtained in both
the cases.
I have
On Fri, Oct 29, 2010 at 01:36:08AM +0100, Gary Martin wrote:
The main issue was that kids quickly start clicking (and did!) on
other visible buttons/activities, quickly stalling out the whole
system through impatience. The fullscreen launcher was designed to
remove this case given our multi
On Fri, Oct 29, 2010 at 05:26:40AM +0530, Anurag Chowdhury wrote:
On Thu, Oct 28, 2010 at 11:12 PM, Martin Dengler
mar...@martindengler.com wrote:
to test the time taken by update function everytime
it is called.
I used the time.time() function to measure the time taken to process
the
On Fri, Oct 29, 2010 at 05:26:33AM +0530, Anurag Chowdhury wrote:
On Fri, Oct 29, 2010 at 12:14 AM, Gonzalo Odiard gonz...@laptop.org wrote:
I think the problem is the code is rendering the svg icon every time
the color is changed.
There are not cache or cairo operation used to avoid this.
On Fri, Oct 29, 2010 at 11:05:45AM +1100, James Cameron wrote:
On Thu, Oct 28, 2010 at 06:42:53PM +0100, Martin Dengler wrote:
http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-stats-graph.png
Nice. A question on interpretation ... is the number of renderings
consistent with the
I was wondering about this as well.
I am more of a backend programmer, but the most obvious thing that
stands out to me is that Sugar activities do not seem to regularly
change their launch icons. They are not like system tray or Sugar frame
icons which alter themselves to tell us
G'day Samuel,
Yes, I think you're right, pre-rendering, either to RAM or to a file on
disk, would likely speed things considerably.
I suggest rendering 12 views at linear levels, then switching between
them using varying timing rather than fixed timing. The visual effect
would not appear to be
On Tue, Oct 26, 2010 at 7:50 PM, James Cameron qu...@laptop.org wrote:
On Tue, Oct 26, 2010 at 05:41:58PM +0530, Anurag Chowdhury wrote:
The conclusion of XO-1.5 being nearly 2.5 times faster than the XO-1
could be verified by comparing their hardware specifications. at
Hi Steven,
On 27 Oct 2010, at 15:55, Steven Parrish wrote:
On Tue, Oct 26, 2010 at 7:50 PM, James Cameron qu...@laptop.org wrote:
On Tue, Oct 26, 2010 at 05:41:58PM +0530, Anurag Chowdhury wrote:
The conclusion of XO-1.5 being nearly 2.5 times faster than the XO-1
could be verified by
On Wed, Oct 27, 2010 at 11:15:01PM +0530, Anurag Chowdhury wrote:
I carried out the same benchmark test, which I earlier conducted on an
XO-1.5, on a XO-1. And I have attached the log files obtained in both
the cases.
I have reviewed them. Can you show me the patch you used for benchmark
Excerpts from Anurag Chowdhury's message of Mon Oct 25 19:22:09 +0200 2010:
In my logs I noted an average processing time of 0.85 sec for running the
first run of the update () function (i.e. while rendering of the first frame
) and since a XO-1.5 is nearly 2.5 times faster than a XO-1 so
On Tue, Oct 26, 2010 at 10:57:03AM +0200, Sascha Silbe wrote:
Excerpts from Anurag Chowdhury's message of Mon Oct 25 19:22:09 +0200 2010:
In my logs I noted an average processing time of 0.85 sec for running the
first run of the update () function (i.e. while rendering of the first frame
On Tue, Oct 26, 2010 at 05:41:58PM +0530, Anurag Chowdhury wrote:
The conclusion of XO-1.5 being nearly 2.5 times faster than the XO-1 could
be verified by comparing their hardware specifications.
at http://en.wikipedia.org/wiki/OLPC_XO-1 (For XO-1) and
Sure, I would certainly do a similar benchmark test on an XO-1 also . I am
presently waiting for the developers' key of my XO-1 to
flash it into the latest build of dextrose, then I will run the benchmark
test and will post the results asap.
On Tue, Oct 26, 2010 at 6:59 PM, Martin Dengler
On Tue, Oct 26, 2010 at 05:41:58PM +0530, Anurag Chowdhury wrote:
The conclusion of XO-1.5 being nearly 2.5 times faster than the XO-1
could be verified by comparing their hardware specifications. at
http://en.wikipedia.org/wiki/OLPC_XO-1 (For XO-1) and
The present issue has two possible scenarios of solving it
1) Optimise the present pulsing icon animation to reduce the delay : Thats
what I have worked towards till now in my patches.
2)Replace the present pulsing icon animation with a better and faster
animation: Thats what I think everyone
The first frame of the animation is not being skipped but its just not
being filled with colour so as to make the pulsing icon animation start
earlier and I hope we both agree on the fact that the delay is caused due to
the time taken for the rendering of the zoom in and zoom out animation
Congratulations -- and welcome to the world of hacking:)
This email represents the crux of problem solving.
All of the git, python, pep8, variable name, stuff is just syntax and
semantics. Important to follow or you get 'errors and warnings':)
At it's core 'hacking' is identifying and solving
On 24 Oct 2010, at 16:53, Anurag Chowdhury wrote:
The present issue has two possible scenarios of solving it
1) Optimise the present pulsing icon animation to reduce the delay : Thats
what I have worked towards till now in my patches.
2)Replace the present pulsing icon animation with a
On Fri, 2010-10-22 at 04:19 +0530, Manusheel Gupta wrote:
Please us know if the patch meets the requirements. If yes, can we add
the documentation of the approach followed by us at the wiki?
If we're still taking about the v5 patch that was posted to the list, I
don't understand how this
Team,
Any further inputs? Please share.
Anurag did discuss with Aleksey at IRC, and he seems to agree with his
approach. Aleksey, am I right?
Bernie,
Please us know if the patch meets the requirements. If yes, can we add the
documentation of the approach followed by us at the wiki?
Regards,
On Fri, Oct 22, 2010 at 04:19:26AM +0530, Manusheel Gupta wrote:
Team,
Any further inputs? Please share.
Anurag did discuss with Aleksey at IRC, and he seems to agree with his
approach. Aleksey, am I right?
I'm ok w/ having a hack like proposed patch. Though it is not solving
original
On Mon, Oct 18, 2010 at 12:43:49AM +0530, Anurag Chowdhury wrote:
Team
I had submitted the patch for the http://bugs.sugarlabs.org/ticket/2080
You can check the patch at
http://lists.sugarlabs.org/archive/sugar-devel/2010-October/027748.html
Wish if you could review it and provide me
Team
I had submitted the patch for the http://bugs.sugarlabs.org/ticket/2080
You can check the patch at
http://lists.sugarlabs.org/archive/sugar-devel/2010-October/027748.html
Wish if you could review it and provide me feedback on any improvement
required.
Regards
Anurag
On Wed, Oct 13, 2010 at 10:29 AM, Anurag Chowdhury anu...@seeta.in wrote:
Daniel,
Thank you for reviewing the patch. Appreciate it.
Wish to inform you that I did try the profiler, and displayed the time slice
intervals between rendering of consecutive frames. I did find significant
change in
44 matches
Mail list logo
