do you have multiple bindings for lid close in acpi bindings? what have you done to have it suspend on lid close even with ac on? in blanking enabled "suspend even on c" (i know bad place for this checkbox... as above - whole thing needs a redo). it's almost as if you have 2 acpi lid close bindings? i did exactly what you describe above without issues - i could get it to suspend when on ac by checking the checkbox above. check your acpi bindings as you definitely get the acpi events i''d expect.

also can you run acpi_listen somewhere in a terminal to get logs - this should log ac power plug/unplug... i am curious to see if acpi is reporting events properly...

can you just try the default theme? the suspend and other things rely on a back and forth talk between e and the theme. perhaps your theme never responds with a "i am done" signal and you end up down some never-tested error path? i'm guessing.

ummm did you see the comments in _store_mount_verify()?

oh so this is just the "lazy load" and not any of the scaling stuff right? that will be separate?

ok - i just spent about 10 mins with my laptop, an external display on my desk doing various combinations of plug and unplug of the external display, closing of the lid and plug/unplug of power. in every case i ended up after a few seconds and some fade out and in etc. with either my external monitor showing my previous laptop display (lid closed) or both screens showing 2 different screen configs (mouse can move from one to the other). my monitor is a different res (2560x1440 vs 1920x1080 on laptop screen) so it adjusted accordingly each and every time. i also tried plugging and unplugging of ac during this process as well ... never did it suspend except in the case of external screen unplugged and ac unplugged and i close the lid then. ... so i can't reproduce your issues. i don't know what causes them... i was guessing above at a race. i did try the above from slowly and methodically plug/unplug one thing at a time to being a bit rushed about it. sooo... :(.

Realistically... the only SoC that did armv7 that didn't do neon were the early tegras - they fixed that later. So ... just disable these optimizations if you have this corner case. 99.9% of armv7 socs do neon. it is a build option and it can be swizzled... should we hurt the performance of 99.9% of situations for the 0.1 that that don't? and there is an option it off for this 0.1% ... :) aarch64 fixed this by making neon required of course (well in practice)... :)

fixed it... use current sched when SCHED_BATCH and IDLE not available.

i already fixed D11872 then found this fixes it... so obsolete

eh wait.. first lines. you had a script run... why? you know this is a recipe for disaster as e is messing with randr config at the same time as your script... it's a race condition waiting to happen. so i wouldn't do this if i were you...

just some history - there was no ref counter before because we never referenced glyphs, strings were stored as strings (utf8) then decoded and mapped to glyph id's as they were rendered. so we refcounted whole fonts but not glyphs as we had no persistent reference. doing actual refcounting is kined of possible now with the way structs changed over time.. but it means freeing an evas text string (which has unicode glyph id's and font ptrs and positions) might get costly having to ref+++ and -- each glyph.

:)

i think we can un-beta them... :)

this also causes issues. asan finds them too

this starts causing all sorts of segv's

Aha coming to this. This definitely needs some ifdefs regarding wayland so it's not enabled when in wayland mode (also runtime checks too as well).

@simotek ping?

oh. ha! thats a silly one! :)

ha. oh i found this separately already - before i saw this patch. :) so obsolete really :| sorry.

ummm i can change bg. without this patch. this patch removes the ability to set a specific bg for a specific screen/desktop... so its all or nothing. this at least changes what this option does so any scripts depending on it break... :( and it doesn't fix anything i see. if you wanted a new option to set on all screens/desktops... then it should add a new option.

I suspect you have very little room to improve on video-mem side. you could try use integer frag shaders to pack alpha masks down to 4 bits per pixel forcibly. the other options are much more exotic (like RLE compression implemented by shaders as tiles so you only store a max of N integer values in a texture per row so e.g. a 16x16 uncompressed alpha tile can maybe be stored at 4x16 or 8x16 depending on the longest row and the shader walks the pixels in that row in the tile to figure out the alpha value at that x point. i have mulled doing this for years but never gotten to it. it'll be a trade-off of memory vs compute. spend more compute effort "decompressing" as you render vs using more memory. this will heavily depend on the nature of the data being compressed and the gpu you have and the choice of magic numbers like tile size...

That's what I'm saying - it completely ignores what we tell it to show. It doesn't even make a guess of "xxx.desktop == icon named xxx.svg". It just does it's own crazy thing. It's pretty ridiculous.

that's just stupid. the desktop file has an explicit full path to an icon. it refuses to use that. ok it refuses to use the same name as the desktop file (enlightenment.desktop, enlightenment.svg). it's just totally inventing stuff to use with no basis in what it is being told to use from e/s data. lightdm seems to just be specifically broken here.

oh. nice catch!

my point was that you flag this in being in the scene graph if it ever was processed. perhaps it's better to flag it if it ever was rendered.... then this seems like an ok work-around to calling evas_norender(). evs_norender is still needed if the canvas doesn't render again etc. to clean up objects that have since been freed.

you made this diff invisible to the world - even admins and phab users. i had to dig into the mysql db to fix it. please don't do this :( i'ts a time sink to fix. :)

should be fixed by 811e4240b693b761462802b8811ba6088985b745

Ummm... the object could be in the scene graph for a render cycle, never be shown or rendered and it'll then hang around in the scene graph just like before until some render cycles flush it out, because it will then be flagged as being in the graph and behave just like before.

This is not a leak. It is by design. Evas calculates update regions by state of "previous state compared to current state" when rendering. In the normal case of almost every app they will almost always go through a render cycle at some point which then does this cleanup. if you use the canvas in this inactive way (eg create and destroy objects - maybe use them to do things like load image from disk for thumbnails etc.) there is evas_norender() that handles this cleanup without rendering. It throws away old objects (and in the process will lose any updates they would have caused). In 99.999% of cases this is never needed. In the very very very rare case where it is - like using a canvas as a workhorse above, evas_norender() does the cleanup. Also remember to then add an update rect for the whole canvas too to force an update if you may have missed updates because some canvas content changed without your direct control (edje animating for example). If you fully control the canvas and know it hasn't done this, then no need to also add the update. This is only needed in the case where you create objects, never show them, then delete them, which is unusual behavior and covered by the above.

odd. now it passes. ok... well... then

did you run this through ninja test? because... i get a nice big fail here...

that looks better ... let m test

well we already have ctrl+alt+n. i'd rather not make duplicate bindings for the same thing as they use up precious binding space. there are a limited number of modifier+key combinations we can use without conflicting with some app or something else, so being conservative is important. i'd prefer to add the ability to maximize to-/bottom half and use win+up/down for that as that makes a lot of sense to me - it mirrors the left/right in the vertical dimension. i'd also like to have more like top-left/top-right/bottom-left/bottom-right ... and as you can guess... we'll run out of modifiers+keys quickly :)

oh yes. that looks like silly code before :)

confirmed. it fixes it/works :) nicely done!

i did notice children was 0 ... but if it has already filled it in... then children would be > 0 ... (well the examples i was looking at was a dir with files inside - the filesel test). so... hrrm. that was one of the things i noted. children was 0. i was wondering what on earth could or would force a populate then perhaps to get children to appear. i got the idea that the child module already existed because the parent populate created it...

cool

it's not overly complex. no more than saying "you need to unzip the zip file to get to the readme" :) so it's there and it complies legally - it's shipped as intended and actually available for anyone wanting to look at it. i would argue 99% of people will never edje_decc or even know it exists ... so as an order of magnitude... they are both in the under 1% will even look :)

try now... i made some more space...

i'd call it trivial as the data is there and is trivially extractable.

the license is there.

it would seem your font is a bit bigger by default and so doesn't fit into the space given to allow for 2 lines.

I don't know what you're on about: