sounds right...

indeed startup time is a whole kettle of fish on its own - good you looked. what was the profile before you changes though?

i don't see the same log but tbh it's not worth really worrying about much.

hmm this isn't quite right. -msse3 should onlt be applied to the op_blend_master_sse3.c file build so the rest of efl doesn't build with sse3 optimizations in it and sse3 is only applied to this file which is runtime enabled by the sse3 detection. otherwise all of efl is built with sse3 asm optimizations and thus can't run on any cpu not supporting sse3 at all. :)

any click to dismiss the alt-tab (winlist) thing will be lost - it's a click that dismisses it too like escape key. that is by design and intent, and it works that way from the frist time i use winlist (if activated by a mouse e.g. button or wheel event). if activated by a key then the mouse is not grabbed/blocked this way and can be used to click on things like alt+left mouse to move a window around. e.g use alt+tab or a key bound to nest/prev window...

are you sure you're using git master? i am using it here - i bound both my 2nd wheel and an extra 2 mouse buttons to "window : list" -> next window / previous window. it works like a charm... i also bound some extra unused key on my keyboard to "next window" and that works the same way. the window list comes up and stays up. arrow keys allow me to move focus spatially (up goes to the next window vertically, down, next down vertically, left/right the same). escape exits the window switcher. i can keep using wheel/bound mouse buttons to iterate over windows in the list too... and it works again and again and again...

@Peter2121 - try git master now. it's working reliably for me with mouse wheel and mouse buttons bound appropriately to contexts... :)

@ProhtMeyhet - you have a different issue but yes - xserver is not responding. it's hung. that is a "driver issue" really. not much we can do about that. we're asking for the surface attributes to figure out what to render (we need to know how old the buffer is). we never get an answer... nothing we can do there. :(

noted...

what was the actual error with that trace?

and higher res, even broken up into shell vs screen image for layering:

i've tested this across various machines and i see no ill effects. i've pushed it for you with a more decent log :)

oh it's being added multiple times to pending objects? well./... that's bad. it shouldn't but... this does fix it. i'd say merge it. :)

The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

it is when the window resizes right that you are talking about?

oh that is weird... and bad.... this doesnt seem like animation and more like swallows are not following the parent correctly... at least when i resize....

the license is BSD so technically you need to include a BSD license indicator somewhere (the COPYING file). but when used on a web page like you do (well a gilab repo but it's really a web document...) i think would class as fair use. the about page doesn't reproduce the license as it is directly about the software so that i would say is reasonable. what you do seems reasonable too thus - go for it. keep doing what you do :)

i know. i have been looking into solutions for having everything work. i think i have something that works now. i am testing it.

only thing that could be fixed is _efl_ui_dnd_shutdown() be removed with using:L

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?