Re: [e-users] e19 almost constantly using 20-30% CPU, burns less CPU with software rendering

[Marc M. <mar...@me...>]

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.
Would you then say that for lesser GPUs, one would be better off sticking
with e18?

> 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.

So for now, I have:
Composite/Effects/enable fast composite effects for X: all checked
Rendering:
  smooth scaling
  don't composite fullscreen windows

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

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 :)

Cheers,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/