i dont see this and my screensaver kicks in a lot.... same as your git efl/e - i haven't seen this. default theme too...

i seriously think you have a driver bug. that vsync option just sets eglswapinterval to 1 instead of 0. that means egl (the xserver end of it) will wait for a vsync to swap buffers. you could try build efl with full opengl instead of egl but full opengl will use the glx swap interval api instead... so it may just end up the same. animators are still timed to vblank/sync events if possible on that platform etc. even without vsync enabled.

Well I'm a bit stumped - without poking round to see more detailed info ... :|

@rafspiny ?

:) \o/ :) cool!

good point - but shouldn't this be fixed in eet_eina_stream_data_descriptor_class_set() ?

i assume this is for a partly downloaded file or something?

this was fixed by avoiding heap allocations as per thread here.

At ome point i need to come back to lock screen and expanding what it can do, but i'm busy with color classes and related stuff right now.

it's not fake. it is real. pulse says so. pavucontol happens to choose to filter these out and hide them, but they are real pulse entities. emixer now does also filter them out

c7264e9ed5eb1725d926cbc76324bfbb9bfc6da9

fixed by D12276 ?

cool

do you want to add a test in this commit and update it or submit another one after this?

well by itself this turns into compiler death... as some of the previous ones break builds or add warnings - i didnt test this together with the others ... just some of the errors:

seems to work fine :)

This leads to warnings redefining things:

works :)

umm... this leads to things compiling against efl breaking:

:)

and fixed sizing beyond the scree in P341

FYI - your patch "fixed" would be something like: P340

nicely done. some pointers to where to look and .. presto. it wasn't hard...

:)

well then - not sure what is going on but... it does work for me. it is the client's job to respond to config changes. in your case terminology. the widgets will be handled by elementary and will adjust scaling and other config. the terminal view/grid is not managed by elementary. it's terminology's custom objects. here, terminology adjusts scaling and sizing of the font in that and the cursor too...

it'll be something in reloading the config on the terminology side. but for me it works just fine - i set scale to 2.0 the terminal cells scale up, cursor is where it should be, a control menu i pooped up scales up. it COULD be e and elementary_config fighting over the config and each one writing one right after the other, so a race. remember than e also wants to save elm config to set its idea of what scaling should be too.

all that does is modify the config files... and quit... there is no refresh. all elm apps monitor the config files and if they change on disk re-load them... :)

well they don't REALLY solve it .. they hide it by being even more aggressive at not doing anything when blanked... :) but the massive cpu % being used is still the problem... it should not be using that much.

that's common. it may mean e double-renders or misses a frame every few hundred/thousand frames or so when they diverge enough. i've had mis-aligned refreshes often enough without issues though...

hmm so ONLY when screen is off... please just try intel to see if it goes away. also try software rendering (no re-plugging/cables needed). i'm trying to figure out if this has to do with the nvidia driver blob. right now it SHOULDN'T be rendering anything and that should mean the nvidia blob is not involved while the screen is off. to be sure i'd throw some printf's in src/modules/evas/engines/gl_x11/evas_x_main.c in eng_outbuf_flush() to printf every time a frame is rendered... it should not be rendering, but maybe it is and disabling of rendering is not working? this then might make sense. e tries to render, swap a buffer, and nvida tries to show the buffer but because no vsync signal is happening on displays it sits in some spinlock trying to swap to a screen that is off or to query the buffer state of a new backbuffer before rendering to know how to partial-render. that would still be an nvidia blob bug - it should know screen is off and just insta-swap without vsync.

that is totally bizarre. when scren is on it does the same even when idle? like 60-100% cpu? can you run perf top again and specificall speed up its sampling rates and look at what it says when e's cpu spikes?

these above now freeze the clock entirely so it'll be totally idle (other bits of e may wake up to do things but not the clock now - not to tick over seconds/minutes etc.)

but just waking up once a second to flip the digit should be cheap and not need that much cpu. i actually was wrong - the new flat theme still have a transition - a fade digit out over 0.1 sec ... so 6 frames every 60... with screen blanks and seconds enabled i see:

well well... but how is it using so much cpu? well ok - I can think of something - when a digit flips the clock in the old dark theme uses an animation that makes it flicker in like broken fluorescent tube.

the vsync handling filters out duplicates. what i have seen is they have the same frame count so it only cares about vsync events with a new frame count. so e.g. if you have 2 screens we see vsync from one with frame 123 and then another from the other screen with frame 123... then the next one is frame 124 for each etc. ... if we didn't filter we'd over-render, not "stop rendering" but perhaps there is a logic hole somewhere?

unload all modules, then load 1 at a time? at least that will tell us if it's related to a module or not and if so, which one. another you can do is update your build to current git master... :)

That's odd. I did see a problem with intel drivers. the vsync events provide a timestamp. I did notice that sometimes my intel laptop would freeze - stop animating. I finally figured it out... the timestamp between 2 vsync events went BACKWARDS. so frame 101 had a timestamp BEFORE frame 100 (these timestamps are clock monotonic so should never go backwards - ever). This basically broken the vsync timing logic etc. - i added a check for this in efl git and a fprintf to stderr too when it happens. It's absolutely a driver bug (I talked to the dri devs and they all agree it should never happen but we can't easily figure out why it happens).

well embryo does turn up so something is going through script... i really am not sure what is doing this... something is really odd on your system there.

hmm well something is seemingly animating and using embryo script along the way... what is animating will maybe indicate what is going on... ?

well nothing special there - something from theme is running. try this: remove the cpufreq gadget from your shelf?

Worth looking into, but "I don't see the problem". Apps running CAN cause E to use CPU - if something interacts with the XServer and that then causes E to have to do something in response - this definitely can happen. It then depends on what is happening if E is using too much CPU or not. An idle X session with no apps doing anything. Tjhis is an idle e sesson with screen set to lock after blanking (blanking set to 30 sec, dimming to 10 sec), current git master e and efl:

perf top might be useful. perf top -p PIDOFENLIGHTENMNENT ...

that's why i suggested trying modesetting... as intel driver now may have some bugs on some hardware setups and the answer is "use modestting" if you have issues as no one is going to fix the intel-video driver... :) invalid bug for e as the bug is off in xorg :)

try remove xf86-video-intel and use modesetting

also intel or modesetting driver?

wait - mouse and keyboard don't work. mouse cursor doesn't move around? vt switch (ctrl+atl+f1/2/3/4/5/6/7) doesn't switch vt's?

the issue i know of was with ffox, not chromium. i have, in got, re-enabled setting wm_state to iconic because of this. a bug was filed with ffox but nothing happened. assuming if you sent a request to the wm to iconify that you do get iconified is an assumption you can't make - ffox froze it's ui until it got the wm state change to iconic thus freezing everything. it assumed it would become iconic whenever it requested, rather than knowing a wm can choose not to honor that request if it does not want to.

IF you set it to iconic - they do things like stop rendering, thus why e stopped setting it to keep windows updating when minimized. the problem is that at least one app (firefox) totally broke assuming it will always be made iconic when you press the minimize button when it uses CSD... until then it worked fine as apps just never went iconic.

because apps will stop rendering when iconic ... thus the miniature thumbnails don't update... :)

well i accepted this now :)

its in git

Well ok - it's not that then. In feb I switched back to the threaded vsync by default - there's an env var to switch to/from thread vs inline. threaded is best if you don\t want to miss frames.

that vsync option simply sets the egl swap interval to 1 (ie vsync). ... the animator - i changed it to have an offset of 0.5 frames:

This has now made it to git master... but the work goes on