On Wed, 29 Apr 2015 22:03:43 -0700 Marc MERLIN <[email protected]> said:
> On Thu, Apr 30, 2015 at 10:03:59AM +0900, Carsten Haitzler wrote: > > mplayer is updating something - eg it's window. if its window update e HAs > > to composite the window - mplayer may talk directly to gpu to render window > > content, but once rendered, you will never SEE the content unless the > > compositor then renders it.. again - as part of your display. that is the > > nature of compositing (at its core/simplest). so every time anything on your > > screen updates ... anything visually... e must be involved and wake up and > > do a render cycle itself. a blinking cursor, a clock ticking its second > > hand. a video playing. they all require the compositor be involved as the > > next stage after the app has provided a render/update to the xserver. > > Thanks for explaining. Clearly I wasn't aware of how this worked. > > > e doesn't snapshot. it literally is just drawing the window in a tiny > > miniature. e already has the entire window content "as a texture". it > > already has a pointer to it. that is how compositing works basically. it > > simply tells the canvas object "your source updated" (the source being the > > window pixmap that we bind to a texture). a result of that is that if this > > was not a vsync wakeup, efl (not even e) queues a wakeup via an animator > > for the next vsync. when that wakeup happens, then at the end of that > > wakeup, the canvas that *IS* your entire desktop goes through a render > > cycle. evas then looks for changed/updated flags on objects - if any, and > > calulates what regions updated and then will draw based on engine details, > > things like gl extensions available etc. etc. > > I see. > > > the e16 pager literally was doing screengrabs continually - every i think > > from memory 10th of a second all day, every day. it would grab just a > > scanline - > > It did, but it didn't warm up my CPU or spun up my fan on a CPU that's many > times less powerful than my current one :) > > > then scale with the cpu, but it grabbed. e19+ is literally pointing the > > pager to the same data as the window and just drawing it a 2nd time. that's > > all. > > I get your point. My problem happens earlier, it's not the pager but the fact > that a redraw has to happen. > > > turning off the pager may drop the cpu by some amount - but it'll still burn > > cpu on any updates. evas is generating 1000's of vertexes every frame in > > the gl engine if ti has to render the whole screen. every letter in a > > titlebar is 6 vertexes. that is EXCLUDING effects like inset, soft shadow > > etc. inset will > (...) > > i'm throwing these numbers out there so you can begin to count all these > > little elements on your screen and get an appreciation for how many > > vertexes the cpu is generating on the fly (and trust me - it's more than > > this when we start to > > Omg, this is huge. No wonder it's so much more work on my poor little > graphics CPU. once you realize just how much it's doing... you begin to go "wow - it manages to cope with all that that well? WOW!" :) on the long-term is to make a lot of this vertex generation threaded so we'd still soak up cpu - but async. > Would you then say that for lesser GPUs, one would be better off sticking > with e18? tbh - e18 does the same thing. e17 was different and instead used more memory and caused more copies of pixel data as a result. e18,19,(and 20) are better on the zero-copy path. especially if your clients also use gl because it doesnt force a copy on a glswapbuffers for the client. this would have happened in e17 and most x compositors because client is swapping their gl buffer into PARt of a bigger pixmap buffer. if we had auto-buffering of evas objects we'd turn this on again - but we don't, so instead we throw vertexes at the problem. reality is that we're kind of waiting on cedric to do this (he promised to :)). for text and textblock i guess i could reel in the vertexes. i could probably also even do it for images. if cedcric then came to the party and did the smart objects we could probably cut the vertex data down to 1/10th. this is all deep down inside evas's rendering code, not in e - and so right now.. i'm not touching it as we're in release mode. > > with partial rendering we can limit what vertexes we have to generate to > > just the update area (eg the window being updated plus bounding box of any > > other updates that frame - so window + pager bounded). without that we have > > to re-render the whole screen. you can see the effect this has on cpu by > > FORCING evas to assume a specific buffering mode. go to: > > > > settings -> look -> composite -> advanced -> rendering > > > > and switch to "triple buffered swaps". this forces evas to assume the gl > > driver is triple buffering and it'll reduce its update regions. catch - > > driver may at times NOT triple buffer in strict sequence and thus you will > > get update artifacts. that is why the buffer age extension exists - every > > frame we ask the driver how old our new backbuffer is and thus can know how > > much to update. > > Thanks for the suggestion. I tried triple buffering and it does create bad > artifacts. quite possible. but did you look at the difference in cpu usage? switching to pager plain instead of pager as a module will reduce the render area IF you had partial rendering... > So for now, I have: > Composite/Effects/enable fast composite effects for X: all checked > Rendering: > smooth scaling > don't composite fullscreen windows that's all fine > Engine: OpenGL (I may try software rendering again, it somehow looked faster > on my quadcore CPU) > Tear-free: disabled > Texture from pixmap: enabled > Swapping method: autho you really want tear-free. really. disabling this is just doing yourself a disservice. :) > X-messages: send flush and send dump enabled > > Hopefully these are decent options for reduced CPU/GPU load. > It would be awesome if you had a preset like the old E where you could say > "low power system" and it would dial down anything known expensive, but in > the meantime, I very much appreciate your direct help :) you have a quad core system... not a low power thing. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
