Compositing and “lightweight” desktops

In the general discussion about “lightweight” desktop environments I have read a few times that one should disable Compositing in KWin. That’s done in Kubuntu’s low-fat settings package and also something Jos talked about in the context of Klyde.

I have never seen an explanation on why Compositing should matter at all. It mostly boils down to “OpenGL is evil” and “I don’t want 3D”. So let’s leave the “educated guesses” behind us and have a proper look to the question whether Compositing matters for “lightweight”. (Remember: lightweight is a buzz-word without any meaning.)

Let’s start from one of the “lightweight” aspects: Memory. For this it’s important to know that KWin is a Window Manager and Compositor. You cannot just have the Window Manager – even if compositing is disabled. It’s not like xcompmgr which runs in another process. For the binary that gets loaded into memory it doesn’t matter whether compositing is enabled or not. The pure binary containing both window manager and compositor has a size of 1.3 M (on Debian testing, that should be KDE SC 4.8). But when you enable compositing an additional library gets loaded containing the Effects. They are all in one library to not have to open 40 different files. (Again on Debian testing) This library has a size of 783 K. The effects do not link any library which is not already linked by KWin core, so that’s what we are talking about from additional memory costs when using any desktop effect from binary size: 783 K!

Obviously the binary mapped into memory is just one aspect. There are also additional data structures which need to be created on the heap. I have no idea how much is really needed and cannot properly look at my system because I have a KWin with debugging symbols loaded. What’s important to know is that only Effects one uses will get loaded and use memory for their data structures. Also the Effects do not load everything they need but wait till they get activated. E.g. the cube effect will only load a background texture if the cube gets activated. But of course effects do not have anything to do with just using compositing. If you don’t want an effect, just disable it.

The biggest cost from compositing in the memory perspective is probably using the XComposite extension which redirects the rendering into an X pixmap. That’s something which will go away once we are on Wayland as application and compositor share the buffer the application is rendering to.

But even so the usage of the additional memory is not just something which is thrown out. It’s just another case of the time-memory tradeoff. Unrelated windows do not need to repaint if a window get’s unmapped, moved or resized. Just look at this comment from the non-composited switching of virtual desktops:

During virt. desktop switching, desktop areas covered by windows that are going to be hidden are first obscured by new windows with no background ( i.e. transparent ) placed right below the windows. These invisible windows are removed after the switch is complete. Reduces desktop ( wallpaper ) repaints during desktop switching

Without compositing we move the time-memory tradeoff towards using more CPU (create those windows) to prevent even more CPU usage. With compositing we don’t have to do anything of it. So disabling compositing is obviously not the silver bullet for being “lightweight”. It just means moving the time-memory tradeoff slider towards CPU.

What remains is the OpenGL question. I know that many people think it’s about having a “3D desktop”. But the desktop I’m using is quite 2D-ish. There are people saying that 2D is just a special case of 3D. Looking at OpenGL that is certainly the case. As long as you don’t use any effect which needs the “3D aspect” of OpenGL, KWin just does 2D with OpenGL. Using OpenGL means to make use of hardware which is designed to do these operations instead of doing it on the CPU which is not designed for it. But what if one doesn’t have the hardware for it? A valid question, but just not in the context of KWin. If your system only provides software rendering KWin automatically falls back to XRender based compositing.

The last aspect to mention in the context of OpenGL is texture from pixmap. I don’t know how it’s implemented in the drivers so I don’t know whether that needs additional memory or not. But if you are concerned about it: XRender does not need a texture from pixmap.

So as you can see compositing comes with a little bit more memory usage but reduces CPU usage. It’s nothing I could say which one is generally better, but less CPU usage means a sleeping CPU. Granted some effects do animations – that also requires CPU usage. If you are concerned about that it’s better to disable the effects or set the global animation speed to instant than to just disable compositing completely.

And if you try to be “lightweight” and play with the compositing settings: one unrelated change can ruin all your benefit. Just imagine you would disable compositing because you want to be “lightweight” and then you enable a window decoration which uses QML (that is interpreted code) and does animations?

67 thoughts on “Compositing and “lightweight” desktops

  1. > I have never seen an explanation on why Compositing should matter at all.
    because games

    1. which is wrong, if you want to optimize for games do so and say so by e.g. setting the hint to disable compositing from the game.

      1. Unfortunately, I know of no game doing this, and configuring this manually for each game is hard. Even more so since the tool to choose the window affected by a window rule cannot be used with most Linux games, which are full-screen and grab the keyboard.
        I wrote a patch for primus [1] to set the correct X atom on windows doing GL. As I LD_PRELOAD primus for all graphically non-trivial games, this works fine here. Maybe a dedicated LD_PRELOAD library doing just the window configuration would be interesting?

        To make things worse, due to the bug in Plasma/kdelibs concerning detection of the composite state [2], if everything is set up to toggle compositing, one often ends up with a broken Plasma theme after quitting the game. And even if this was fixed, there is an ugly disruptive UI change when starting and quitting the game.

        OTOH, when disabling compositing, one can claerly tell that the designers did not spend much time tweaking the non-composited Plasma theme. Even disabling blur (a very expensive effect, in my experience) causes some visual issues where backgrounds are too transparent – it’s just for this reason that blur is enabled on my system.

        [1] https://github.com/ralfjung-e/primus
        [2] https://bugs.kde.org/show_bug.cgi?id=179042

      2. I could, but I am too lazy to figure out the right combination of settings which would work for all my open-source, native closed-source and wine-run games (both fullscreen and windowed, which I mostly play in).

        Frankly, I think a window-manager should just work™

        1. Well it does just work… if you are too lazy to use hints, you can just disable compositing, even with a shortcut. Chose your poison, there is no free lunch. But this has nothing to do with “light weight” desktops, which this blog post is all about.

    2. Kwin lets you add rules to totally suspend compositing for any applications you specify, and there’s also the “unredirect fullscreen windows” option. Kwin compositing really doesn’t make any difference for games if your settings are correct :p

  2. Always learn a lot from your blog!
    That indeed true! lightweight for the sake of lightweight! That’s a lot of people’s problem!

  3. The only gripe I have with composting is the performance issues when running windowed video and opengl games.

    When people say lightweight the mostly mean responsive. Pressing ALT+TAB should be instantaneous. For some reason, with composite window managers, this seems to take a bit more time and the animation when switching windows after you haven’t done that in a while is a bit choppy. You talk about this in your memory vs CPU optimization and I think that there should be more caching and preloading when it comes to effects so that they are always responsive and are never swapped.

    Just to be clear, I agree with your claim that “lightweight” is a notion completely devoid of meaning. For window managers responsiveness and frame-rate should be the most important traits not memory consmption.

    1. For Alt+Tab there is no code difference between non-composited and composited. The only difference is that the window is faded in which might result in a perceived further delay of 150 msec. If you don’t like it: turn the fade effect off.

      Concerning games and video: use the window hint to disable compositing.

      1. Actually I can confirm that Alt-Tab often takes a considerable amount of time to show the menu, if and only if compositing is enabled. It can take almost a second for the switcher to show up, with around 8-10 windows being open. This is caused by the Lanczos filter, I can mitigate the issue by changing the scale method or using a switcher without window preview.

        1. Interesting, I don’t have that problem on any of my systems. It’s pretty much instant, but that kind of makes sense. I wanted to improve Lanczos anyway to handle such situations better.

            1. no, I think it’s just that too many textures being tried to be created at the same time.

  4. I was going to say the issue with compositing or other effects was not memory but that they did not work for me, but when I read “OpenGL”, I looked at the settings and found XRender to work. My hardware is very old: almost ten years.

    1. that’s something I discussed in my other blog post – lightweight and old are not the same thing. If one would want to have settings for old computers, they should be called that and not “lightweight”

  5. Scrolling in Chrome is less smooth here when compositing is enabled. I don’t really understand why it has any impact.

    It’s not a very fast GPU (ThinkPad with i7-620M), but I would think that the performance should suffice for such relatively simple rendering operations.

  6. ” If you are concerned about that it’s better to disable the effects or set the global animation speed to instant than to just disable compositing completely.”

    So for example… if i can have configured alot of effects for normal usage, but if i somewhat want a more “lightweight” :) usage, i can just put the speed to instant ?
    Will that save cpu and 3d usage , or i just wont see the effect ? Will the code walk the “effect path” ?

    1. The animation speed influences the duration an animation takes. This has direct impact on the maximum number of frames being rendered during an animation. Instant sets the duration to 0 msec if I read the code correctly ;-) That means the animation will never start or better said: it ended before it started. It schedules one frame (has to anyway) and then realizes the animation ended. It will most likely walk the “effect path” for one frame.

  7. “The biggest cost from compositing in the memory perspective is probably using the XComposite extension which redirects the rendering into an X pixmap. That’s something which will go away once we are on Wayland as application and compositor share the buffer the application is rendering to.”

    Lets do it now!

    About composting and effect and useful features this area is similar to those arguing PulseAudio is not OK few years after PA works OK for majority of users.

    About lightweight aspect this is lightweight to me:

    -It doesn’t burn too much CPU/GPU cycles all the time and it works OK on entery level hardware that is up to 8 years old.
    -I don’t care for the memory aspect too much on desktop PC.
    -Responsive GUI that doesn’t lags this is something i am missing in Unity for example and will wait to see what Unity Next does.

  8. What i would really like to see but i think we are past the point this could be made reality is something like Weston becoming the standard Wayland Compositor for Linux world.

    It would have to be low on GPU/CPU cycles but extendible like Compiz. But did didn’t happen and i am looking forward to see how KWin on Wayland will work.

  9. KWIN with compositing doesn’t reduce CPU usage significantly, if it does. But increase GPU usage significantly, and with that comes more memory and power (joules per second lost with heat) usage too.

    If you turn off the effects by setting the animation time to zero, you are turning off the GPU usage, but not the CPU usage and those effects are going to be loaded into the (gpu and ram) memory anyways without being used at all… nice

    Of course, if everybody wants to use the GPU now, like web browsers, toolkits, window managers, etc. i wouldn’t expect the GPU to be so efficient and stable, the fps is going to suffer.

    If someday wayland or mir come to an useful release, my hope is that kwin and the other WM are going to become much more irrelevant anyways.

  10. Just opening a GL context uses several tens of MB of RAM. On top of mapping the big GL libs, also several tens of MB.

    The “GL is evil” also manifests on older cards (< GL 1.5), where the GL path generally lags a huge amount compared to non-GL paths. This may be due to some fallback or not.

    1. as I wrote in the post. KWin links these big GL libs anyway, whether you use compositing or not, it get’s linked and loaded. But it hardly matters because these big GL libs are shared between processes.

      Concerning the GL context uses several tens of MB, well, that’s nothing I could confirm on my system here…

      1. “KWin links these big GL libs anyway”

        Non-GL compositors do not.

        “But it hardly matters because these big GL libs are shared between processes.”

        Sure it matters, if the compositor is the _only_ GL thing you would run.

        “Concerning the GL context uses several tens of MB, well, that’s nothing I could confirm on my system here…”

        Only a small part is attributed to the process itself. The kernel steals some, some is attributed to X.

        1. this is about KWin and whether saying “one should disable compositing for lightweight”, I don’t care about whether other compositors don’t link GL, KWin does. And obviously if KWin is the only GL application the libs aren’t shared, which obviously will no longer be the case with Qt Quick 2.

  11. Let them see a KWin in qt5, nearly no kde libs and razor-qt. I am pretty sure, than they are happy. And nobody will call KWin heavy. And KWin is for many Users the half KDE.

    1. Well, the last point may simply be caused by the fact that kwin is indeed the most awesome WM out there thanks to its great developers ;-)

  12. > But what if one doesn’t have the hardware for it? A valid question, but just not in the context of KWin. If your system only provides software rendering KWin automatically falls back to XRender based compositing.

    This ignores the possibility of having hardware that provides hardware rendering, but is too slow to do it well. There’s a lot of hardware that falls into this range and it makes KWin perform poorly.

    And falling back to XRender-based compositing is slower than disabling compositing altogether. It takes both more memory and more CPU cycles. I don’t see why it’s in question whether disabling compositing in this situation would make KWin perform better.

    1. any valid points for that or are you just assuming because you think that it has to be like that with old hardware?

  13. I think you forgot a few issue that compositing does create :

    - You are creating a full screen (in GL double buffered) window. That use a lot of memory by itself. It is possible to reduce that cost if the background window is merged and rendered by the compositor itself (One less full screen window).

    - Xrender is so damn slow that a software raster backend can be 10 times faster.

    - OpenGL driver tend to allocate a lot of memory in the process itself. Nvidia driver in particular love to allocate 10MB or so in the process… So the memory foot print for an OpenGL backed compositor is quite high (same goes for any application that use OpenGL in fact) and that doesn’t count any texture or what so ever, just the cost of setting up the OpenGL stack…

    - OpenGL (except with a few latest driver) require a full screen redraw every time something change on the screen. That is not needed without a compositor and it does create an additional cost that is not negligible. Partial update is the way to go and hopefully Wayland will bring that to the mainstream.

    1. KWin has never done full-screen repaints all the time. It has always done only partial updates.

      1. I beg to differ, only the latest NVidia driver (I think it is still in experimental) provide the API for partial update with OpenGL. Intel does also have an implementation for that, but I have yet to find it in a distribution somewhere. So as long as you do use OpenGL, you don’t have partial update for 99% of the people using compositing.

        If you think you do partial update, please let me know the OpenGL extension you are using for that.

        1. we are not using any opengl extension to do the partial updates. We have a code path for the mesa extension and one for the non-mesa extension.

          1. Yes and that’s worth. I have just looked at KWin code, so not an expert of what you do, but here is my understanding. You copy the pixels of the previous frame into the new one (minus the part that did change) and then you render the change. I was wondering how you could implement partial update in OpenGL without extension efficiently. What you are doing here is actually slower than a full screen rendering. You should never read back the pixel of the last frame.

            What the extension for partial rendering does provide is a way to push partial update and know how many buffer you have (could be triple or double buffer, or the buffer could have been dropped due to inactivity). So you need to remember those delta on more than one frame and replay them as needed.

            1. This is only done in git master and only conditionally (you can select it if your hardware performs good at it – nvidia blob) and kwin so far does partial updates by copying parts of the back into the frontbuffer. Ideally via glCopySubbuffer, otherwise by copying pixels (back to front!)

              1. Thanks to acknowledge that you are copying pixels ! I am going to argue that using a simple scene graph that would properly do occlusion with a full frame rendering will give you better performance than what you are doing actually.

                Also if you do partial update do it with a logic for double and triple buffer to avoid doing any pixels copy, then you could use Intel or Nvidia extension and have much better performance.

                1. > I am going to argue that using a simple scene graph that would properly do occlusion
                  I thought you had checked the code? Of course there’s occlusion culling.

                  Partial updates instead of full scene repaints mostly exists because some IGPs simply get into trouble with permanent WUXGA updates.
                  Actually the optional (and not yet released!) front-to-back copying does equal or better than full scene repaints on the nvidia blob – only on MESA it’s a complete desaster.
                  The (present) back-to-front copying will mostly happen on nvidia the nvidia blob, MESA has subbuffer copying.

                  And of course there’ll at a point be support for (brand new) EXT_buffer_age next to the other strategies (because it’s not necessarily available and hardly field tested) – simply because front-to-back is not an option on mesa.

                2. Could you elaborate on why full-screen repaints should give us better performance? I did a lot of experimenting with this, and always found some situation where the framerate would drop visibly below 60fps (either video playback, or large blurred regions, or…) Re-using some old pixels (using subbuffer copies) maintains stable 60fps with my Intel IGP at Full HD, almost all the time.
                  However, this could just as well be some issue in the renderer.

                  I also prefer the solution which re-blits textures instead of copying pixels, not only because GL_FRONT access in mesa is slow but also because it seems the much saner solution. As far as I know, no other compositor will ever access GL_FRONT directly.

                  1. As always it depends on your driver. We did only find that this function is quite often badly implemented. Sometime they do the copypixels on the CPU. You can imagine how awesome it is. Alternatively they also stall the GPU pipeline for the previous frame to finish before scheduling the copy with a CPU spinning during that time. A variation of awesomeness also.

                    This is obviously GL driver issue, but sadly they are quite common and it is a tricky task to avoid all the nasty corner.

  14. Thank you for this very informative post again !

    However as much as I can agree with you, in practice things are really different and I experience it everyday on my desktop. Even on my 6-core desktop computer (so no worries about battery/powersave) with a decent recent nvidia GPU, enabling compositing makes things way less responsive : games framerate drop, window resizing becomes a sluggish nightmare, scrolling gets jerky (especially since I can’t live without smooth scrolling in my web browser and dolphin), etc…

    Now, I’m fairly certain these issues are more related to the old X11 cruft that has never been designed for Compositing in the first place rather than KWin itself, that thanks to your amazing work, makes Compositing an almost pleasing experience especially since KDE 4.9+…

    …Almost. Because there’s still situations where it needs to be disabled due to the aforementioned issues whereas on Windows 7+ Aero or OS X, Compositing doesn’t impact the performance of 3D apps nor the rest of the desktop and can be left permanently enabled (I even think there’s no way to disable it on OS X), but I hope Wayland will make this happen on Linux aswell.

    1. That sounds like a configuration issue on your side. On my system for example window resizing is super smooth. For games: use the option to disable compositing all together.

      1. maybe it’s too early to ask… but just for curiosity, on wayland should we disable compositing for games? or this is only a problem of X? many thanks.

          1. but it won’t have any negative effect on games?
            And if no, why is it ok with wayland but not with X?

            1. because wayland is a completely different design.
              no idea whether it also allows to render directly into the overlay buffer (while i assume it) but it has no way _near_ the overhead redirection on X11 causes.

      2. Well I’m aware of this hint and I’m using it for games, however this is more of a workaround solution to be honest and it’s not very “elegant” as the plasma theme would loose translucency, effects would be disabled while playing the game (I have a dualscreen setup, so I always play in windowed mode).

        My point is that if compositing was usable on Linux, these hints and hacks like fullscreen unredirection wouldn’t be needed as it would never have to be disabled. But it’s not the case, because of poor drivers, or X11′s architecture, whatsoever… Again my hopes are on Wayland for a real fully composited desktop without drawbacks.

        About resizing, well, I have to admit it’s far smoother than what it used to be some times ago, but again compared to the two other OSes there’s a long way to go. But I think it’s more of a driver issue, I heard opensource drivers generally perform much better when it comes to 2D and resizing…

  15. Hi Martin,
    Is it possible to detect if a window is fullscreen for more than a given time ( ex ~5 seconds ) to toggle the compositing (and vice-versa) ?

      1. to avoid as you said:
        > Concerning games and video: use the window hint to disable compositing.

        1. and then you deactivate compositing when some browser enters fullscreen mode…

  16. About compositing. I have the same issues (framerate drop, sluggishness) with games as described by others, and I’d like to add that I don’t see these issues under Win7, GNOME (for that one week I tried to use it), or Xfce. So, there’s that. The thing is, I’m not fond of these other environments, and I like KDE, so I just suspend desktop effects before I launch a game. Other than that, I don’t see any difference (e.g. memory wise).

    About lightweight. It’s just a practical term that means a list of things e.g. responsiveness, cpu usage, memory consumption, dependance on libraries, processes runnning etc. So instead of listing these things over and over again and bore someone to death, we say “lightweight”. Most of the time lightweight also comes with less features/integration/bling (it’s a trade-off) but that doesn’t mean that lightweight is “just a buzz word”.

    I really appreciate the fact that with free software it is possible a) for me to run KDE on my new machine b) for my parents to run Xfce and Abiword on my “old” desktops, and c) for my niece to run LXDE and leafpad/midori on the raspberrypi I bought her to learn python. And I get updates and bug fixes for all this software. Lightweight has a practical meaning for me and the majority of people, so it’s not just a buzz word.

    1. read my other blog post about lightweight. You have your own definition and other people have their own definition. Read the comments: the definitions are even conflicting. It’s a buzz word, and nothing else.

      1. I’ve read it (and the comments). If you’re looking for the ultimate, indisputable definition you won’t find it, not just for “lightweight” but for most words found in a dictionary. You might find these definitions adequate or even accurate and complete, someone else might not. We could always talk and talk theoratically. Anyway, I disagree with many things written in your original “lightweight” article, and I don’t want to further pollute here, since this article is about compositing ;-)

  17. A lot of the bad rep of compositing comes from years of bad implementation.
    My experience with compiz and metacity (not necessarily the current state):
    -Metacity can go for weeks without any issues, compiz crashes every one or two days(add unity to the mix and you get a couple per day)
    -Cpu usage with compiz is much higher in many cases: flash, videos, web browser scrooling
    -Some cheat simply doesn’t work, Kbreakout didn’t work with compiz/unity (a lot of flickering and tearing)
    -Not to mention a ton of bugs not present in metacity

    Kwin is the only compositing WM I’ve found stable enough to use and the ability to turn on/off compositing seamlessly is awesome.

    ps: bring back vertical left aligned text window listing (alt+tab), horizontal box sacrifices usability for looks.

  18. I can’t say I notice much difference in response times with compositing enabled or disabled. I can’t say I have studied it a lot either, and I don’t have very many effects enabled, but the only case where I find it necessary to turn off compositing is when I work remotely connected to a Citrix environment and have applications (running under MS Windows) seamlessly integrated. The applications I use there are SAP Logon Pad and SAP GUI – usually between 5 and 10 SAP GUI windows.
    With compositing enabled the application windows will often not repaint properly when I switch between them (I may have to switch windows a couple of times), and this problem disappears with compositing disabled. This problem does not seem to exist for a single MS Windows (remote computer) session.

  19. Hey Martin, just to warn you that your link “http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-settings/kubuntu-settings/view/head:/low-fat/share/config/kwinrc” is broken.
    :)

  20. Lightweight composting = Enlightenment DE

    Have seen composting working really well with very low specification hardware. Can choose whether it uses software rendering or OpenGL on initial config.

    No problems gaming either…

  21. Hi,

    I know it is not related to the topic, but are there any plans to support GLX_EXT_buffer_age in kwin anytime in the future?
    I am testing kde 4.11 on opensuse 12.3 (using nvidia proprietary drivers) and right now i am still experiencing tearing, does not matter if it is watching videos or horizontally scrolling in the widget browser.
    Compiz has an experimental version supporting the extension, which i tested: There is absolutely no tearing and really good performance.
    I know, patches are welcome ;-) , but I am just curious if you or some of the devs have this on their plans.
    BTW: There is actually a bug in kwin proposed to be solved in kde 4.11:
    https://bugs.kde.org/show_bug.cgi?id=307965
    Has this been merged already? If so, this would mean it did not fix tearing for me.
    I am using sync to v-blank on both, nvidia drivers side and kwin side, and i am not redirecting full-screen windows.

    Thank you very much!

    1. Yes that change is in current master (but not in KDE 4.10). Per default (unless you are using the NVidia blob) it will do full-screen repaints for frames with large damages, i.e. when >50% (or something) of the screen changed. Smaller repaints can still tear. You can configure this in the system settings.

      And yes, support for buffer_age is planned. However I doubt I will be able to implement it for 4.11.

      1. Nice to hear!
        Do you have written code already? Could you link the branch?
        I would like to know where to look to see the progress and help with testing!

        Thank you

  22. I give you a reason to deactivate the compositor: Power.

    On a laptop the difference between having the OpenGL effects On an having them off is at least 40-50 min of battery on my laptop

    1. And why don’t you deactivate the effects which drain battery instead of turning off compositing?

      1. Because it’s not as simple as that. Since I usually do 3 things with my pc: Movies, Browsing, IMs, Music(I work with music too but for that I have to use windows cause of some programs ) I either don’t move windows around or stay for long periods of time on the browser only.
        No matter what I did the best I could squeeze out of my laptop was with Ubuntu 13.04, tlp installed with custom config, pcie_aspm=force and a bunch of command line to force the hd4000 (ivy bridge) to reduce power consumption and MATE. The simple act of having opengl activated seems to stop the gpu to go to a lower idle level while I’m reading, and that does not happen for example on KDE with xrender of xfce or anything that does not use a compositor. and just so you know it, I still get better battery life out it with windows 8. Why? because it has better power management. The difference between Linux and xp was abyssal(xp power management was ridiculous ) but now windows is a lot over Linux. It has a lot of more fine-grained controls(something I’d like to see in on kde,the infrastructure is there), like changing the whole pcie-aspm status (use less power, use all the power you can), processor speed, video card power behaviour, differentiated between battery and plug in, with different profiles, and it adjust the behaviour of the system as a whole( ie10 and metro/wmp/codecs behave differently if you set in the power profile to prioritize battery life instead of performance, and only in case you run on battery. Also I’ve noticed how the hd scheduler and cpu scaler changes behaviour. All out of the box and a few clicks away, no passwords/uac asked. And last thing, there is no powering down the aero interface/hardware acceleration in windows 8, there is some kind of directx software fallback, but still getting better battery life than Linux without compositor.

        And no, I’m not a windows advocate, and my first distro was Red Hat Linux 6.0 and I was born in the 86(I was something about 11 years old) so I grew up with Linux and I love it.. but it still needs a lot of progress to not be left behind.

Comments are closed.