bug fix. i see how making test that triggers this would be hard as it's a race/internal structure condition where you just get unlucky sometimes. but i think mike means like memfile set an image to one memfile, then get the pixeldata, maybe chekcsum it simply, then memfile set the sameimage to another memfile data blob and get the image data and checksum that. if the sums differ. good. it worked. if they are the same... bad. it's not a great test and not of much value really... but that's kind of what he's asking.

oh. no read or write permissions... :) that would be why... rm can't delete it. you need -f to force it... :) so that explains why. still owned by you though.

and ... what is the problem dir/file and what are its permissions?

this is a bit of a problem as you can vote only for 1 item...

see a above. i think it's simpler just done where i originally mentioned - i the time get's and select mechanism of ecore. someone also has one this "let's run time at a different speed" as an LD_PRELOAD:

at the edje level it is (set colorclass on that edje object). elm hides the edje objects though and there may be more than one in a widget too (or none) so realistically there would have to be an elm specific api that passes through to the right edje object(s).

this is asking for trouble. creating another loop and expecting to be able to iterate it and run it as normal is bound to end in tears at some point. it is not intended or designed to work like this. the loop class is intended for one thing - to be created as a bi product of ecore's init (as a parent class) and driven from there. something in future is going to break this and do so validly.

let's forget preloading. Acutally, !tex shouldn't be happened

what preloading? you mean you re using the async preload? when this is used what should happen is the image is not shown until the preload callback comes in, then it is shown and all is fine. in fact it shouldn't draw if still preloading. it should stall and wait for the load to finish. that's how it used to work.

eh? this looks wrong. if there is no texture assigned to the image, there is nothing to draw, so empty/blank is correct (don't draw anything). this could lead to glitches now where there is something drawn (often white rectangles) where before there was nothing.

This fix actually submitted by @raster

You're definitely correct that timers do get called out of order now; this is a direct result of (more) regressions created in rEFL5dd52fd09b7d79c70b3134423a87aa6400a2d994

eio usage of getpwnam implies that this will not work on Windows, @vtorri can you look?

i've never found a compiler that doesn't handle them that would be used to compile my code (e.g. for linux and other posix systems) - so never ran into that... and i have never noted undefined behavior if i just use the bitfield as a boolean like if (x->field) a(); else b();. it's rare i use more than 1 but (but have done so to pack stuff more to save space).

well now it's a matter of finding it and fixing it... the bt details are a bit sparse with ???'s :)

@jayji - you don't think bool x:1; is good? it definitely saves space especially if you have a lot of flags and want to pack them at the end of a struct etc. ... and the value then can only be true or false, no other values possible. :)

hmmm. this seems to be it:

hmm. the only bit that might look interesting is:

continuing to use MY_CLASS without knowing what it means

eh? why do this. you just made buggy code by registering a callback after the event has happened. this can happen anywhere and the idea is to set up callbacks early on before the events happen like

enums are worse. i've worked with x's #defined XK_... long enough to have chosen to use strings instead. it's more flexible (lets us add new keys for new hardware/platforms without adding new enums in header files) and it actually more convenient as no one really knows all the key names. i've read the #define key list in x headers often enough to not bother and just use xev to find the key name ... and that is a plain string without any fuss. for keys i don't have i can look them up - but strings are far better and that is based on having experienced/used the alternative you propose.

what hardcoded strings? you mean location identifiers? like ~/ ? like (:app.dir:) etc. ? Then pray tell how do you plan to indicate a path to a place on the filesystem that can change at a time (on the fly, at runtime, per use, per execution etc.) as part of a file path with is a STRING by definition.

A quick grep shows at least a handful of exceptions

ummm i am not so sure it's a good idea. licenses are an often asked question. often enough and important enough to put in the README imho... :)

@ManMower - yes i did. i kept clicking the button until i got bored then counted them. :)

This isn't accurate. There are plenty of places in the codebase where the filename and the class name are not related.

I would disagree. The context is known because the filename generally determines the class being used... so you know what you are dealing with already by that context.

@ManMower - you should read what I wrote. There will be no making it 10x faster. I went into depth as to why that is not going to happen. There is nothing left to optimize there. I've tried caches with more slots. I've read every single line of code in the hot path. I've done ache hit analysis on single vs multiple slots thus knowing how often the hot path gets triggered etc. ... think it over. there is nothing to optimize at least for getting obj ptr from id in terms of the code/design as it stands in the cached path, and cache hit rayte is not bad, and more slots doesn't improve the profile though it improves the hit rate a bit. i mentioned dropping a level of tables (and extra ptr follow) to avoid more memory accesses but that then comes with other downsides. i've done all this with the conclusion that the only way to improve it is to drop the number of lookups so NUMBER of eo calls is what is important and that is a slow painful path of finding all the redundancy where 2 or 3 calls are made where 1 could do.

hmm the valgrind log doesn't seem to be running valgrind - no output from valgrind there...

the backtrace is deep inside data structure handling (lists). this requires valgrind to tell us more. you will need full debug symbols in efl too.

i know that the registration eats a lot of time, I KNOW IT. and i said that i will fix it. However not right now, not right here, due to the lag of time.

btw... it was your commit that broke functionality to begin with by setting the env so saying "should be reverted" is a pretty arrogant thing to say as if your commit that broke existing functionality to begin with is more important than this one that restores it... just letting you know that you come off as a dick with that above. so it's not a regression, it's a fix to a regression you created.

??? i'm trying to point out that callback_call is a far lower user of cpu time than resolving eoid's to pointers - at least in this benchmark and the benchmark does matter because genlist does matter. a lot. so far your comments have been basically "well it's genlist's fault for creating and destroying things and that's not realistic".

btw - check on arm. chars are unsigned by default there for example - different architectures may be different... but for existing efl - no. shouldn't change. efl 2.0 - anything goes. :)

is this not just a button with the label below the icon and maybe a different style/look? i'd say just provide a button style for this.

yes. with a different style on toolbar and the features of first/last item having different styles/looks (or if there is only 1 item).

it was a tizen/slp ux/ui design idea that even tizen never used... we should remove a bunch of old widgets...

indeed elm's menu is far behind e.g. what enlightenment's does. i always mulled porting e's menu into elm or rewriting something of similar design and capabilities, but the current state is pretty bad.

same as T7188 - bad idea.

this is probably a bad idea unless you want to somehow syncronize state between parent and child widgets. how do you have the button label go a different color when the button is clicked? also have the animation sync with the parent button animation? it would be a bad idea to do this unless you solve all of these issues first.

the setting of the env broke actual functionality in elm as described in the log, so reverting is not an option. this fixes a regression your patch created.

I dont think so, since its quite a difference if you walk a array with 2 elements or 20, this is not going to fit into a cache in a whole, and thus will still result in cache misses. So in the end.

So from this POV the event submission should scale way better then before. Since before the execution is O(log n) in EVERY case.

8% of eo calls are efl_ui_focus_object_prepare_logical_none_recursive() called from efl_ui_focus_object_prepare_logical() ... that's 8% of all eoid lookups... just by itself. :( focus manager is certainly something to look at. that's more than 2x as many calls as efl_event_callback_call ... :(

you know... it really depends on your hardware. for me _efl_object_call_resolve and _eo_obj_pointer_get are reversed on my desktop.

*shrug*. the evas object isn't deleted, the e comp one is. tasks has just set focus on an evas object.. the intercept it just responding by discovering the matching e comp object is deleted (but evas obj is fine), so you could go add a "get the e comp object behind the evas obj and check deleted state" everywhere you do anything to the evas objects (focus etc.) or just return in the intercept and do nothing... but aborting has been chosen as the right thing to do as opposed to the sensible thing which is - do nothing and return.

this is not in efl's focus handling in elm - it's in enlightenment's handling - something is saying "set focus" but the client is dead ( but object still around for some reason -p not cleaned up yet). to me it's a simple case of make that a NOP as it's pretty harmless... but not what mike wants, so ... enjoy the crashing. :)

oh! this is @zmike 's policy to have e crash any time it does something odd instead of deal with it and recover...

until efl 2.0 ... can't happen. abi problems like @herdsman says. for then - sure. until then - can't.

this has been lurking for a while and me, jpeg and cedric all said basically "it's invalid". pixel get cb is not called every render if the obj is visible. it's called evas thinks the obj needs rendering. it may not actually be rendered or be visible to the user/output of the canvas, but evas thinks it needs it.. then it'll call it, but it was never a "call always at every render if this obj is visible logically at all". as jpeg said a render pre/post could do this and iterate over all the obj's that need this but it's not what the pixel get cb is for. so finally doing what jpeg said.. closing as invalid. :)

also see a475b189618f99388e4b37e0f8be823d87102f62

I can't reproduce it. opened 44 elementary_tests.... everything rendering ok for me... :/ amd radeon vega64 with mesa open drivers here and opengl (not gles) compiled for efl... :(

it's handy to not need an if there from the outside...

This bit here is "digging into the internals of the layout". To a limited extent this is allowed/OK - like to emit signals and listen to them on the internal edje object of the layout, but not for anything elm layout already provides an API for and definitely not for doing things like deleting the edje object. The worst bits are then digging into the internals of the edje object by using smart member APIs from outside. These APIs exist for the purposes of the object itself (e.g. the edje object) to manage the evas state. I.E. when swallowing an object, add it to smart members so it's inside the sub tree of the edje object. Doing this behind edje's back is going to lead to trouble. Doing it behind the back of any object will. Don't do it.

indeed simple. good stuff there. tick one off the list :)

lucky for you we wrote a whole page on it:

your backtrace is in libc's inside the malloc code. this means the heap is already corrupted at this point and the bactrace isn't any use. it will nee valgrind to find it.

oh ... that's not e's lock feature - thats just another dialog preventing the logout (e closes all windows cleanly and will refuse to log out if there are still windows around - with a timeout and that dialog).

D6579 does seem like it...

how does the app prevent poweroff/logout? do you mean e's locks on windows to prevent logout if this window is still around?

feel free to land it yourself. :)

but why is it that removing the dnd handling for the entry does this - that should release the selection manager from handling anything on that window as no entries will exist to handle it... ? e's own xdnd code should be doing it...

netstar did mention on irc that maybe the selection manager needs... attention. :)

so you want to be able to snapshot an eo obj tree and rebuild it automatically with properties, callbacks etc. in place?

can you give me a more concrete example?

why control the internals? isn't it that we should be testing those internals they they work as expected with their logic from the outside? sure. the bug could be in the widget, in evas, ecore or somewhere else, but driving it from the outside is what it's about, is it not?

alos make V=1 will give full commands issued so you can copy & paste that once uyou cd into the right parent dir (data dir in the efl dir) then just run that. though beware that may be a wrapper script so you may have to run the binary from .libs/ i.e.:

:)

there. merged in master.

never mind - i didnt pull master before merge :)

odd. i even merged and it's still broken...

yeah - i played with fontconfig a bit to. rather a pain that this needs fixing though.

A fair bit of work to make it efficient but possible i guess. A little like react actually. Maybe that is another path?

Exactness? Just with a simple one widget test?

This was proposed years ago, multiple times. Ukrainian guys proposed it too. A kind of template definition of required part names and types, required segnals listened to and emitted, etc. ... just no one has gone and done it.

in theory it might be possible - yes. though interestingly it happens AT the point screenshotting occurs. there is no "hook" for that for modules so.... it's some other corruption that trickles on over to the screenshot code path... or it's something else as screenshotting really is getting evas to do the work...

the README is for a release... and a release has a generated configure script in the tarball. that is the whole point of autoconf. to generate everything and then the user of the release needs no autotools installed. asking users to use autogen.sh goes against exactly what autotools was designed to do. :(m of course grabbing from git master is different - it assumes you are capable of knowing how to build things from development and thus know what autogen.sh would do etc.

very very odd.i mean without valgrind it may have to do with how memory is laid out by a variation in glibc or other dependencies, but in the end it'd be access to "out of bounds" (non-allocated memory) and valgrind would catch it.

i agree with you there. the "parent multiples child scale" was totally a logical thing - you set scale on a parent frame for example and you just EXPECT the child to go along with it... it's logical at least to me. set scale on a window and everything in that window should have the same scale factor... unless they also set a scale to be bigger etc. :) it's easy to implement as elm already knows how to figure out the resulting scale ... just put that code into that get func :)

ok - the above issue with bitmap fonts - was partly an issue with an svg color emoji font i had installed ... removed it and partly dejavu that seems to take preference to color emoji thus using bnw emoji from it. remove dejavu and rely on bitsream vera and its perfect with efl. elm entry and terminology.

consolidating how? example?

i can't reproduce. efl from git. it took me a while to get noto color emoji to be used i had to add the following to my fonts.conf:

well rage doesn't issue any gl commands - it's pure "efl" and totally portable. you can force sw rendering and it still works. so ... it is something efl can solve within its stack. just a note.evas gl is kind of a problem indeed unless we literally track state AND all data (shaders, textures, etc. etc.) and store locally so we can re-create them and create a mapping table of the texture id's and other id's exposed by evas gl to the real ones in gl. it's a nasty amount of work though and i don't think that can happen any time soon. BUT... basic regular evas stuff like what rage uses should be able to be usable.

I tired to reproduce on current e git master and efl git master ... I couldn't. xephyr, software rendering. so either the bug has been fixed in efl ... or in e... are you using a specific e revision to reproduce this? i've tried with default theme and flat. valgrind says nothing for me (beyond sometimes that glob thing which is an optimization in fnmatch so ignoreable). i've taking shots of windows, of the whole screen (in xephyr)... saved them... not a peep from valgrind. admittedly i compiled with -O0 because with proper optimizations i get a libvex valgrind internal error.

this is fixed by D6275

aaah found it. pretty simple... it's because it's setuid - the setuid check doesn't init cpu/bt and timer ... why those inits were put at the end beats me but just throwing them before the setuid check solves it - setuid is meant to disable connecting to the debug daemon only... fixed!

tested for a few days... wayland on 2 devices and x on another... everything is working fine.

hmmm i did test rage, terminology and elementary_Test ... but it seems other sizing is not right. so right now the top mentioned commit is a choice between 2 bugs. bug a or b. let me try D6275 for a bit and see.