Re: 9.1 Proposal: Top five performance problems
On 26/10/08 14:21 -0400, Erik Garrison wrote: On Fri, Oct 24, 2008 at 6:36 PM, Jordan Crouse [EMAIL PROTECTED] wrote: On 25/10/08 00:00 +0200, NoiseEHC wrote: The Geode X drive copyes every bit of data to the command ring buffer by using the CPU so that is sure that those almost no CPU cycles thing is at least a bit stretch... :) According to Jordan Crouse it will not be better but he was not too concrete so in the end I am not sure what he was really talking about, see: http://lists.laptop.org/pipermail/devel/2008-May/014797.html Indeed - many CPU cycles are used during compositing. There is a lot of math that happens to generate the masks and other collateral to render the alpha icon on the screen. The performance savings in the composite code comes from not having to read video memory to get the src pixel for the alpha operation(s). That performance savings is already available in the X driver today. Ah! So what work needs to be done to realize these performance savings? Or are you saying that we can already getting them by using composite? Or by another method? You mostly have them now. In fact, you have had them in the driver for the better part of a year and a half. We don't support all composite operations and I'm not even going to begin to pretend that there aren't bugs all over the place, but for the most part you should be already experencing whatever gains the GPU can give you. Also, here: The performance savings in the composite code comes from not having to read video memory to get the src pixel for the alpha operation(s). Do you mean not having to generate the video memory to get the src pixel? By not asking applications to redraw themselves aren't we saving CPU cycles? No, I mean what I said. An alpha blend operation requires three inputs - the source color, the destination color and the alpha value. In order to do the alpha operation in system memory, you may need to read the destination color from video memory, since it could have been calculated as part of another operation. Due to the way that the video memory is cached, it is painfully slow for the system to read from video memory. The GPU helps by doing the alpha blending operation in hardware. It only needs the alpha value and the source color, which we can readily provide from the X server. It then performs the operation directly on video memory. This saves CPU cycles from not having to do the alpha blending math but mainly because the processor doesn't need to stall while reading the video memory. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On Fri, Oct 24, 2008 at 9:13 PM, Mitch Bradley [EMAIL PROTECTED] wrote: Michael Stone wrote: I did some basic profiling of my new rainbow code last night and discovered that, in the best case with the current codebase on XO, it costs about 0.5s/1 exec(python). Approximately 80% of the 0.5s was spent importing modules. I hope to dig deeper in the near future, but I am concerned at my lack of inspiration about how to deal with this problem. (Other than by rewriting into a different language.) I still do not consider the mod_python approach used in the 767-era rainbow to be a viable long-term solution. Well, there is a tedious solution that would probably be effective. Go through the list of modules with a fine-toothed comb and find out what is actually used from each module. I'll bet that there are quite a few modules from which only a few simple functions are used. Collecting those functions into one lightweight (no unnecessary stuff) module might collapse the dependency graph. As I said, this can be tedious, but it's the sort of think I've done many times during my career, and it has usually paid off. If nothing else, you end up learning a lot about how things work, which tends to make you eventually become fearless. Hah! I know how that works, and it's not nearly as complicated as you think! A lot of complexity ends up being solutions to low-value problems that don't apply in your case. As a case in point, a long time ago I needed to incorporate a stripped-down stdio package in some app that needed to be tiny. The basic character I/O ended up pulling in a train load of networking libraries. It turned out that isatty() was the culprit - it had to check whether the file descriptor matched every conceivable kind of I/O object. I just made a stub version of isatty() and all the spurious dependencies disappeared. The problem that I see with this approach are the initializations that are done when importing a module python from the base libraries. You may know that only one or two functions are used from one module and decide to take them into our collector module, but the problem here is that we don't know which part of the code in the original module initialization is expected by those functions to be have been executed. Or even worst, which module initialization code from another imported module is expected by those functions. I intend to look at activity startup in greater detail and see which are the worst offenders at what can be done about it. Other people before us have been bitten by this problem and they have gotten their patches integrated into python, we should be able to do the same. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
Tomeu Vizoso wrote: On Fri, Oct 24, 2008 at 9:13 PM, Mitch Bradley [EMAIL PROTECTED] wrote: Michael Stone wrote: I did some basic profiling of my new rainbow code last night and discovered that, in the best case with the current codebase on XO, it costs about 0.5s/1 exec(python). Approximately 80% of the 0.5s was spent importing modules. I hope to dig deeper in the near future, but I am concerned at my lack of inspiration about how to deal with this problem. (Other than by rewriting into a different language.) I still do not consider the mod_python approach used in the 767-era rainbow to be a viable long-term solution. Well, there is a tedious solution that would probably be effective. Go through the list of modules with a fine-toothed comb and find out what is actually used from each module. I'll bet that there are quite a few modules from which only a few simple functions are used. Collecting those functions into one lightweight (no unnecessary stuff) module might collapse the dependency graph. As I said, this can be tedious, but it's the sort of think I've done many times during my career, and it has usually paid off. If nothing else, you end up learning a lot about how things work, which tends to make you eventually become fearless. Hah! I know how that works, and it's not nearly as complicated as you think! A lot of complexity ends up being solutions to low-value problems that don't apply in your case. As a case in point, a long time ago I needed to incorporate a stripped-down stdio package in some app that needed to be tiny. The basic character I/O ended up pulling in a train load of networking libraries. It turned out that isatty() was the culprit - it had to check whether the file descriptor matched every conceivable kind of I/O object. I just made a stub version of isatty() and all the spurious dependencies disappeared. The problem that I see with this approach are the initializations that are done when importing a module python from the base libraries. You may know that only one or two functions are used from one module and decide to take them into our collector module, but the problem here is that we don't know which part of the code in the original module initialization is expected by those functions to be have been executed. Or even worst, which module initialization code from another imported module is expected by those functions. That is part of the tedious factor. You have to figure out all that stuff. It's deep analysis, rather than cut and paste. You often discover that the existing implementation is much more general than you really need. In that case, it often makes sense to replace the function with a very simple version, in which case a lot of the initialization just goes away too. Other cases in point - the initscripts speedup experiments detailed in http://dev.laptop.org/ticket/4349 . A lot of time is spent by re-including the functions shell script, and a lot of that was due to a fancy framework for both internationalizing and colorizing status reports from service startup. A big wad of stuff could be eliminated by implementing a few display routines as echo. Similarly, udev was taking a long time, but the net result was just to populate /dev with a nearly-static list of device special files. The static part of that could be done with one invocation of tar, saving several seconds. I intend to look at activity startup in greater detail and see which are the worst offenders at what can be done about it. Go for it. We're looking forward to your results. Other people before us have been bitten by this problem and they have gotten their patches integrated into python, we should be able to do the same. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On Fri, Oct 24, 2008 at 6:36 PM, Jordan Crouse [EMAIL PROTECTED] wrote: On 25/10/08 00:00 +0200, NoiseEHC wrote: The Geode X drive copyes every bit of data to the command ring buffer by using the CPU so that is sure that those almost no CPU cycles thing is at least a bit stretch... :) According to Jordan Crouse it will not be better but he was not too concrete so in the end I am not sure what he was really talking about, see: http://lists.laptop.org/pipermail/devel/2008-May/014797.html Indeed - many CPU cycles are used during compositing. There is a lot of math that happens to generate the masks and other collateral to render the alpha icon on the screen. The performance savings in the composite code comes from not having to read video memory to get the src pixel for the alpha operation(s). That performance savings is already available in the X driver today. Ah! So what work needs to be done to realize these performance savings? Or are you saying that we can already getting them by using composite? Or by another method? Also, here: The performance savings in the composite code comes from not having to read video memory to get the src pixel for the alpha operation(s). Do you mean not having to generate the video memory to get the src pixel? By not asking applications to redraw themselves aren't we saving CPU cycles? Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
For want it is worth, the team at the ministry of education in Peru said that 8.2 feels faster to them. The aggregate user perception vector is pointing in the right direction. -walter On Fri, Oct 24, 2008 at 1:58 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Fri, Oct 24, 2008 at 7:04 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: On Fri, Oct 24, 2008 at 10:10 PM, Michael Stone [EMAIL PROTECTED] wrote: Marco, I did some basic profiling of my new rainbow code last night and discovered that, in the best case with the current codebase on XO, it costs about 0.5s/1 exec(python). Approximately 80% of the 0.5s was spent importing modules. I hope to dig deeper in the near future, but I am concerned at my lack of inspiration about how to deal with this problem. (Other than by rewriting into a different language.) I still do not consider the mod_python approach used in the 767-era rainbow to be a viable long-term solution. FWIW, I had done some experiments with Federico's profiling scripts in the early stages of the 8.2 cycle, and had got similar results: http://dev.laptop.org/~sayamindu/not_so_prettygraph.png It's not much meaningful, but if it helps in any way.. :-) -sdg- Hmm, just did some measurements on a recent joyride image running a recent snapshot of sugar's HEAD and got this numbers: 1224870285 Roughly when ck-xinit-session would be called 1224870288.762430 DEBUG root: STARTUP: Starting the shell 1224870297.765248 DEBUG root: STARTUP: Loading the desktop window 1224870297.777485 DEBUG root: STARTUP: Loading the home view 1224870297.780084 DEBUG root: STARTUP: Loading the favorites view 1224870297.793263 DEBUG root: STARTUP: Loading the activities list 1224870298.559094 DEBUG root: STARTUP: Loading the group view 1224870298.631829 DEBUG root: STARTUP: Loading the mesh view 1224870299.444656 DEBUG root: STARTUP: Loading the bundle registry 1224870301.935619 DEBUG root: STARTUP: --- uisetup_completed_cb --- 1224870301.979451 DEBUG root: STARTUP: --- uisetup_delayed_cb --- 1224870303.197090 DEBUG root: STARTUP: Loading the frame 1224870305.001450 DEBUG root: STARTUP: Loading the journal So that's 20 seconds that can (quite roughly) be compared to the 72 seconds you got. I don't think we really got a 52 seconds improvement, but I'm pretty sure that Sugar already got quite leaner (measured 15MB of mem less after booting) and faster and there's still plenty of room for improvement. Cannot wait to have F10 joyride images to compare 8.2 to something closer to what will ship in 9.1 ;) Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On Fri, Oct 24, 2008 at 2:05 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Fri, Oct 24, 2008 at 1:56 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: * Activity startup is ridiculously slow. Design an API incompatible Activity class. Start from a very basic window and add functionalities on the top of it, trying to not regress startup time. Make sure that launcher feedback does not slow down startup. A discussion about preloading and lazy loading approaches to the slow module imports problems would also be interesting. pylauncher VS gobject-introspection? both? Well, gobject-introspection will reduce the amount of work done in pygobject-derived bindings, but those aren't the biggest issue. Also, preloading in pylauncher helps us share memory between processes that otherwise would be duplicated in each python activity. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
Marco, I did some basic profiling of my new rainbow code last night and discovered that, in the best case with the current codebase on XO, it costs about 0.5s/1 exec(python). Approximately 80% of the 0.5s was spent importing modules. I hope to dig deeper in the near future, but I am concerned at my lack of inspiration about how to deal with this problem. (Other than by rewriting into a different language.) I still do not consider the mod_python approach used in the 767-era rainbow to be a viable long-term solution. Michael P.S. - Your talk outline looks great! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On Fri, Oct 24, 2008 at 10:10 PM, Michael Stone [EMAIL PROTECTED] wrote: Marco, I did some basic profiling of my new rainbow code last night and discovered that, in the best case with the current codebase on XO, it costs about 0.5s/1 exec(python). Approximately 80% of the 0.5s was spent importing modules. I hope to dig deeper in the near future, but I am concerned at my lack of inspiration about how to deal with this problem. (Other than by rewriting into a different language.) I still do not consider the mod_python approach used in the 767-era rainbow to be a viable long-term solution. FWIW, I had done some experiments with Federico's profiling scripts in the early stages of the 8.2 cycle, and had got similar results: http://dev.laptop.org/~sayamindu/not_so_prettygraph.png It's not much meaningful, but if it helps in any way.. :-) -sdg- -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On Fri, 24 Oct 2008, Michael Stone wrote: Marco, I did some basic profiling of my new rainbow code last night and discovered that, in the best case with the current codebase on XO, it costs about 0.5s/1 exec(python). Approximately 80% of the 0.5s was spent importing modules. a silly thought, on C++ systems I've seen programs have high overhead in starting when they used too many shared libraries, and greatly reducing the penalty by combining many libraries into one. does python have the same situation? would it make any sense at all to combine the common, required libraries togeather into one? David Lang I hope to dig deeper in the near future, but I am concerned at my lack of inspiration about how to deal with this problem. (Other than by rewriting into a different language.) I still do not consider the mod_python approach used in the 767-era rainbow to be a viable long-term solution. Michael P.S. - Your talk outline looks great! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On Fri, Oct 24, 2008 at 7:04 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: On Fri, Oct 24, 2008 at 10:10 PM, Michael Stone [EMAIL PROTECTED] wrote: Marco, I did some basic profiling of my new rainbow code last night and discovered that, in the best case with the current codebase on XO, it costs about 0.5s/1 exec(python). Approximately 80% of the 0.5s was spent importing modules. I hope to dig deeper in the near future, but I am concerned at my lack of inspiration about how to deal with this problem. (Other than by rewriting into a different language.) I still do not consider the mod_python approach used in the 767-era rainbow to be a viable long-term solution. FWIW, I had done some experiments with Federico's profiling scripts in the early stages of the 8.2 cycle, and had got similar results: http://dev.laptop.org/~sayamindu/not_so_prettygraph.png It's not much meaningful, but if it helps in any way.. :-) -sdg- Hmm, just did some measurements on a recent joyride image running a recent snapshot of sugar's HEAD and got this numbers: 1224870285 Roughly when ck-xinit-session would be called 1224870288.762430 DEBUG root: STARTUP: Starting the shell 1224870297.765248 DEBUG root: STARTUP: Loading the desktop window 1224870297.777485 DEBUG root: STARTUP: Loading the home view 1224870297.780084 DEBUG root: STARTUP: Loading the favorites view 1224870297.793263 DEBUG root: STARTUP: Loading the activities list 1224870298.559094 DEBUG root: STARTUP: Loading the group view 1224870298.631829 DEBUG root: STARTUP: Loading the mesh view 1224870299.444656 DEBUG root: STARTUP: Loading the bundle registry 1224870301.935619 DEBUG root: STARTUP: --- uisetup_completed_cb --- 1224870301.979451 DEBUG root: STARTUP: --- uisetup_delayed_cb --- 1224870303.197090 DEBUG root: STARTUP: Loading the frame 1224870305.001450 DEBUG root: STARTUP: Loading the journal So that's 20 seconds that can (quite roughly) be compared to the 72 seconds you got. I don't think we really got a 52 seconds improvement, but I'm pretty sure that Sugar already got quite leaner (measured 15MB of mem less after booting) and faster and there's still plenty of room for improvement. Cannot wait to have F10 joyride images to compare 8.2 to something closer to what will ship in 9.1 ;) Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
Michael Stone wrote: I did some basic profiling of my new rainbow code last night and discovered that, in the best case with the current codebase on XO, it costs about 0.5s/1 exec(python). Approximately 80% of the 0.5s was spent importing modules. I hope to dig deeper in the near future, but I am concerned at my lack of inspiration about how to deal with this problem. (Other than by rewriting into a different language.) I still do not consider the mod_python approach used in the 767-era rainbow to be a viable long-term solution. Well, there is a tedious solution that would probably be effective. Go through the list of modules with a fine-toothed comb and find out what is actually used from each module. I'll bet that there are quite a few modules from which only a few simple functions are used. Collecting those functions into one lightweight (no unnecessary stuff) module might collapse the dependency graph. As I said, this can be tedious, but it's the sort of think I've done many times during my career, and it has usually paid off. If nothing else, you end up learning a lot about how things work, which tends to make you eventually become fearless. Hah! I know how that works, and it's not nearly as complicated as you think! A lot of complexity ends up being solutions to low-value problems that don't apply in your case. As a case in point, a long time ago I needed to incorporate a stripped-down stdio package in some app that needed to be tiny. The basic character I/O ended up pulling in a train load of networking libraries. It turned out that isatty() was the culprit - it had to check whether the file descriptor matched every conceivable kind of I/O object. I just made a stub version of isatty() and all the spurious dependencies disappeared. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Garrison wrote: What about changing the kind of visual feedback we give. Instead of pulsing icons what about icons with a string of dots beneath, a progress bar, flashing, or another kind of overlay feedback which requires fewer visual changes (frames) and/or could be overlaid on top of existing icons without calculating a new animation for every icon? We have GPU-accelerated alpha compositing on the XO, so we could do the current animation using almost no CPU cycles. It's just a question of figuring out how to access that compositing. As far as I'm aware, no effort in this direction has been made. I don't know if composite here requires the use of Composite in the window manager or not; my knowledge of X is minimal. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkCPQAACgkQUJT6e6HFtqSlSwCfVrZfVFFUqbwgBuLJCckGmHDc S40An2vtXMot6/rz9YmceB38geDaQhH4 =aOse -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
The Geode X drive copyes every bit of data to the command ring buffer by using the CPU so that is sure that those almost no CPU cycles thing is at least a bit stretch... :) According to Jordan Crouse it will not be better but he was not too concrete so in the end I am not sure what he was really talking about, see: http://lists.laptop.org/pipermail/devel/2008-May/014797.html Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Garrison wrote: What about changing the kind of visual feedback we give. Instead of pulsing icons what about icons with a string of dots beneath, a progress bar, flashing, or another kind of overlay feedback which requires fewer visual changes (frames) and/or could be overlaid on top of existing icons without calculating a new animation for every icon? We have GPU-accelerated alpha compositing on the XO, so we could do the current animation using almost no CPU cycles. It's just a question of figuring out how to access that compositing. As far as I'm aware, no effort in this direction has been made. I don't know if composite here requires the use of Composite in the window manager or not; my knowledge of X is minimal. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkCPQAACgkQUJT6e6HFtqSlSwCfVrZfVFFUqbwgBuLJCckGmHDc S40An2vtXMot6/rz9YmceB38geDaQhH4 =aOse -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On 25/10/08 00:00 +0200, NoiseEHC wrote: The Geode X drive copyes every bit of data to the command ring buffer by using the CPU so that is sure that those almost no CPU cycles thing is at least a bit stretch... :) According to Jordan Crouse it will not be better but he was not too concrete so in the end I am not sure what he was really talking about, see: http://lists.laptop.org/pipermail/devel/2008-May/014797.html Indeed - many CPU cycles are used during compositing. There is a lot of math that happens to generate the masks and other collateral to render the alpha icon on the screen. The performance savings in the composite code comes from not having to read video memory to get the src pixel for the alpha operation(s). That performance savings is already available in the X driver today. Jordan Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Garrison wrote: What about changing the kind of visual feedback we give. Instead of pulsing icons what about icons with a string of dots beneath, a progress bar, flashing, or another kind of overlay feedback which requires fewer visual changes (frames) and/or could be overlaid on top of existing icons without calculating a new animation for every icon? We have GPU-accelerated alpha compositing on the XO, so we could do the current animation using almost no CPU cycles. It's just a question of figuring out how to access that compositing. As far as I'm aware, no effort in this direction has been made. I don't know if composite here requires the use of Composite in the window manager or not; my knowledge of X is minimal. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkCPQAACgkQUJT6e6HFtqSlSwCfVrZfVFFUqbwgBuLJCckGmHDc S40An2vtXMot6/rz9YmceB38geDaQhH4 =aOse -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
Could you be a bit more specific, please? What did you mean when you talked about that moving a little bit more of the driver to kernel level would not help? (This was the mentioned thread I had with Bernie.) Also could somebody enlighten me why we does not use DirectFB? Is it because of there are not enough developers or because it is not technically sound? Jordan Crouse wrote: On 25/10/08 00:00 +0200, NoiseEHC wrote: The Geode X drive copyes every bit of data to the command ring buffer by using the CPU so that is sure that those almost no CPU cycles thing is at least a bit stretch... :) According to Jordan Crouse it will not be better but he was not too concrete so in the end I am not sure what he was really talking about, see: http://lists.laptop.org/pipermail/devel/2008-May/014797.html Indeed - many CPU cycles are used during compositing. There is a lot of math that happens to generate the masks and other collateral to render the alpha icon on the screen. The performance savings in the composite code comes from not having to read video memory to get the src pixel for the alpha operation(s). That performance savings is already available in the X driver today. Jordan Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Garrison wrote: What about changing the kind of visual feedback we give. Instead of pulsing icons what about icons with a string of dots beneath, a progress bar, flashing, or another kind of overlay feedback which requires fewer visual changes (frames) and/or could be overlaid on top of existing icons without calculating a new animation for every icon? We have GPU-accelerated alpha compositing on the XO, so we could do the current animation using almost no CPU cycles. It's just a question of figuring out how to access that compositing. As far as I'm aware, no effort in this direction has been made. I don't know if composite here requires the use of Composite in the window manager or not; my knowledge of X is minimal. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkCPQAACgkQUJT6e6HFtqSlSwCfVrZfVFFUqbwgBuLJCckGmHDc S40An2vtXMot6/rz9YmceB38geDaQhH4 =aOse -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On 25/10/08 00:48 +0200, NoiseEHC wrote: Could you be a bit more specific, please? What did you mean when you talked about that moving a little bit more of the driver to kernel level would not help? (This was the mentioned thread I had with Bernie.) I'm not exactly which part you want more specifics for. The code is available - it would be easier if you perused it and asked more direct questions. Jordan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
On Fri, Oct 24, 2008 at 1:56 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: * Activity startup is ridiculously slow. Design an API incompatible Activity class. Start from a very basic window and add functionalities on the top of it, trying to not regress startup time. Make sure that launcher feedback does not slow down startup. A discussion about preloading and lazy loading approaches to the slow module imports problems would also be interesting. pylauncher VS gobject-introspection? both? Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
