Menu
▾
▴
Re: [Lxde-list] [razor-qt] Suggestion: merge lxqt-runner & lxqt-panel
|
From: Alexis L. Z. <azu...@es...> - 2013-11-20 04:37:55
|
Hello people: Did you ever read my emails? Months ago I tell you about an experiment that i was doing, did you remember https://github.com/azubieta/lxqt-core. Well this "experiment" already has a "shell" or a "core" and has some of the components of the desktop as dinamic libruaries (panel and runner). It is still in a pretty bad shape but with your help I can improve it a lot. Please let your ideas in the project wiki and take a look at it. If you are going to try it check the build instructions at the wiki as well. About the transformation of the aplications I had some troubles with the translations, the themes and the settings because of the razor-application class. It may require some work around to make work well. PCman, I wasn't able to build and include the file manager at that moment, help me with it if you can. Kuzma please take a look a the code and let me know your opinions. I was a bit unmotivated at the begining due to the poor welcome of the idea but I will start working on it again. I had plans to present it as my grade project so i will give it all. Cheers Alexis López Zubieta Nova Light Development Team University of Informatics Sciences (Cuba) ----- Mensaje original ----- De: "Kuzma Shapran" <lea...@gm...> Para: "PCMan" <pcm...@gm...> CC: "lxde-list" <Lxd...@li...>, raz...@go... Enviados: Miércoles, 20 de Noviembre 2013 4:28:20 Asunto: Re: [Lxde-list] [razor-qt] Suggestion: merge lxqt-runner & lxqt-panel I agree - it's worth a try. And you have raised an interesting point about IPC. If the session starts (and monitors) only one instance of lxqt-shell, then it's not a question - all modules are libraries within the same process, but we allow to start several separate processes of lxqt-shell (we might even have a checkbox in session config: "launch components as separate processes"). In this case modules should find out themselves how to interact with other modules - through IPC or using direct calls (or signal/slots or whatever) within the same process. Fortunately there should not be many of IPC calls, so lxqt-shell can do this by redirecting requests to another loaded library or by sending them to session or to another instance of lxqt-shell. Another point to consider - is singletons. Most (if not all) our modules should be singletons. So it has to be tracked somewhere. The only stable point is session, so when a lxqt-shell tries to start a module - it should ask session whether this particular module is allowed to start. Cheers, Kuzma On 20 November 2013 16:05, PCMan < pcm...@gm... > wrote: Kuzma, I have the same idea in my mind for quite a long time, too. This can be done easily with the following approach. 1. Replace every main(int argc, int argv) to <Program_name>_main(int argc, int argv); 2. Modify CMakeLists and replace add_executable() with add_library() so every components are now libs. 3. Add a thin wrapper binary program around the lib. The binary only contains main.cpp and only has one function main(), which calls <Program_name>_main(). 4. Add a new program such as lxqt-shell, which loads the libs and all component are running in the same process. 5. If any of the component crashes, the whole shell process crashes, but the session manager can monitor this, and restart it. Though it's less pleasant for the users, it should be a rare case and we should fix the bugs anyways. This is also what Windows explorer.exe does. 6. For those who hates the monolithic shell process, they can still run seprate components as different processes since we provide binaries in #3 which in turns call the component libraries. Pros: 1. all major components are loaded in the same process. So memory, other system resources, pixmap cache, menu cache, and all other caches in Qt can be shared among all of them, potentially saving much RAM. 2. Loading will be faster, and synchronization between the components becomes so easy and does not require IPC. 3. Interaction among the components can be done without IPC when they're not running as separate processes. 4. Library symbol resolution is only done once by the runtime linker, so loading should be faster. (However relocation might be increased, so the final result is unknown). 5. No modification in the session manager is needed. Instead of loading several components, it only need to load lxqt-shell and monitor it. The only thing needs to be changed is lxqt-shell should be made configurable so we can select what modules to load. A lxqt-config-shell tool is needed. 6. All parts can use the same pixmap cache for QIcon, which saves some X resources and RAM. Cons: 1. All components are compiled as PIC code, which might be larger and less optimized. 2. One component crashes, the whole shell crashes. But if we separate the shell process from the session manager, the user won't loss any data or the processes they are running. Only the panel and the desktop manager disappears, and if they can be auto-restarted, that's not a big issue, just some glitches. 3. Since all programs are now using the same pixmap cache for icons, if the icons used by different components are totally different, the cache will be full sooner. Some old entries must be removed from the cache in this worst case. Than, following calls to QIcon::pixmap() will have more missed cache hit. That's the worst case which I think does not happen most of the time. So basically, I think this idea is really worth for trying. This should speed up the desktop a little bit and save much RAM. What do you think? On Wed, Nov 20, 2013 at 6:48 AM, Kuzma Shapran < lea...@gm... > wrote: <blockquote> On 20 November 2013 11:41, Mark Deneen < mde...@gm... > wrote: <blockquote> If one module crashes, won't the entire process be terminated? Alas, yes. We should just make sure modules never crash! ;-) Seriously, if panel or desktop app crashes - this is also not a very pleasant event. I remember that in Razor session monitors modules (processes) and restarts them if needed. With this new idea we also can have lightweight monitor app. When launcher starts - it register itself in the monitor app, before good exit it unregisters itself, on crash monitor restarts the launcher with needed modules. Actually, maybe the idea is not so bad. Cheers, Kuzma <blockquote> -M On Tue, Nov 19, 2013 at 2:11 PM, Kuzma Shapran < lea...@gm... > wrote: <blockquote> I've just had a weird idea: make every part of DE as libraries and one application which just runs these parts alone or together: lxqt-launcher -panel -runner -desktop -whatever Cheers, Kuzma On 12 November 2013 22:41, Alexis López Zubieta < azu...@es... > wrote: <blockquote> El 12/11/13 09:35, PCMan escribió: <blockquote> On Tue, Nov 12, 2013 at 4:58 PM, chr...@su... < chr...@su... > wrote: <blockquote> 2013/11/12 Jerome Leclanche < ad...@gm... > <blockquote> Yeah you mentioned this before. I'm not a fan of merging the two; the panel is especially a component users may want to change. This needs more thoughts but it's a bit too early to care about it imho. Maybe see what we do in the next 3-6 months and then decide on the two components. J. Leclanche </blockquote> I'd agree with Jerome. If I understand your mail you can save 6MB, which is nice for sure but not _that_ much. And in terms of functionality I don't see the panel and the runner as very closely related. Let's get things working first. And then, maybe, we can try to figure out how two applications can share a cache (of icons and such)... br. Chr. <blockquote> On Tue, Nov 12, 2013 at 8:05 AM, PCMan < pcm...@gm... > wrote: > Hello, > I just did some experiment yesterday. > On debian, lxde-qt now eats 109 MB of RAM after a cold boot. > On the same machine, the old lxde gtk+ version only used 85 MB. > (On archlinux, it uses about 150 - 210 MB depending on the machine.) > The difference is quite obvious. :-( > Though 109 MB is good, I think there's room to make it better. > The most memory hungry programs are pcmanfm-qt, lxqt-panel, and lxqt-runner. > I already tried to optimize pcmanfm-qt earlier but it's not possible to > squeeze much from it since the wallpaper is a huge bitmap and must eat some > RAM. > Other parts are hard to optimize as well. No obvious memory eater was found > during the profiling. > Much RAM was used by the icon pixmap cache, but it's inevitable. Otherwise > we'll get slow painting. > The other parts used most RAM were lxqt-panel, and then lxqt-runner. > I tried to put them together in the same binary, and tested it again. > If we merge lxqt-panel + lxqt-runner into a single process, the used RAM > becomes 103 MB after cold boot on the same machine. > The drawback of this approach is, we cannot have an independent lxqt-runner > program. > A simple way to fix this is making lxqt-runner a module - liblxqt-runner, > and let lxqt-panel load it. > When a standalone lxqt-runner program is wanted, we can have a simple > program lxqt-runner which loads the lib. Both lxqt-panel and lxqt-runner > share the same liblxqt-runner. > The drawback of this approach is also obvious. To make it a library, the > compiled code will be PIC, which is more inefficient and less optimized. > I'm not sure if this will really have impact on perceived performance. > Some more experiment needs to be done for it. > > Any comments? </blockquote> </blockquote> OK, let's make it work first. Thanks! </blockquote> Hello: PCman, as you, I also did some experiments to merge the different parts of the desktop such as lxqt-panel, lxqt-runner and even the pcmanfm-qt. My results tell me that we can save from 2 to 4 mb per application merged so I consider that this approach should not be dropped. If we make a modular design of each application we will be able to build then standalone and as module of a big application. Other problem that I found was that those application mainly the PcmanFm-qt are a bit unstable when you just put then together. I will keep working on this approach. Best wishes Alexis López Zubieta Nova Light Development Team University of Informatics Sciences (Cuba) ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Lxde-list mailing list Lxd...@li... https://lists.sourceforge.net/lists/listinfo/lxde-list </blockquote> ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Lxde-list mailing list Lxd...@li... https://lists.sourceforge.net/lists/listinfo/lxde-list </blockquote> </blockquote> </blockquote> </blockquote> ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Lxde-list mailing list Lxd...@li... https://lists.sourceforge.net/lists/listinfo/lxde-list |