though one question - when does this happen? like during shutdown or something like that?

thumbs up

ACK - go land it.

WFM. :)

to be more specific...

what @bu5hm4n said - i looked at the history of the file - the commit went in - changes there then at a later point it was changed again by other commits. so in GIT it seemed all fine to me.

it's just the cgit gui web - git has all the right state/content. that's what matters at the end of the day.

this never should have even passed review. it's obviously wrong - the code path is used. a simple look at the for loop being removed would have shown that

this smells here like a video driver issue - like there are a limited number of "contexts" (video ports) for output rendering and once you hit the limit things fail. that's what it smells like at any rate... so either a hardware or driver design limit. the numbers above hint that the limit might be 64 which smells like the kind of number that might be such a limit well some ports are used implicitly e.g. the screen/compositor uses 1 then it gets 63 mroe of them (port 0, 1, 2, ... 62) then the 65'th fails.

i think we aren't - the implication is code should use the higher level api wrappers. we had to expose these structs because we used to have efl broken up and had to expose an api from one lib to another... :)

Just tried here and forced terminology to use X11 (unset WAYLAND_DISPLAY and ELM_DISPLAY terminology comes up fine in x11 mode as the only display info it has int he env is for x11). i checked with xwininfo -tree -root to see the x11 window as there in xwayland...

oh = i didnt even know about this ticket. i was fixing error logs i found from running enlightenment so i could have some more peace and quiet... :) i'll flag this.

well then elm needs some invisible event object then because how else can you just listen to dnd events on areas of a ui irrespective of the content that happens to be there? well ok- you can use buttons and set their color to 0 0 0 0 but that's a hack.

ummm errrr? i don't know. cgit might have caches like @cedric says and these somehow got stale or unwritable or... ?

This has to be done by the app PROCESS on wayland, but it doesn't need to be done by the APP. This could be done in EFL.

I am wondering right now why this thing went into the place where noone finds it ?

The biggest part of this code is copied from efl_app & efl_task, so i am not too sure where it is really more complexity

@kimcinoo - good question because getting size of the class doesn't get the size of every object as i mentioned above - you could store sub-structs, lists (and the list nodes and what they point to) strings etc. so every obj could be a different size. this just gets base absolute minimum size. i'm not so sure it's really a great and useful thing as any old malloc debugger can probably tell you this kind of info (with track trace to the allocation etc.). a proper "get the mem used now of THIS object to the best of its knowledge" is more useful IMHO. it would mean every class has to implement this (track its own allocations and add them up then ask parent class etc.) it'd be a lot of extra work though.

so basically a convention of namespacing the string so people only mess with "their data" right? for example the efl loop promise might use "_efl/loop.promise" or something right? this does fix the need for eina_promise_data_set_cb_set()

I don't have much idea on how to write a useful test at all here.

eina hash just can't work well. please see my comments on D7514 - you end up with the same "it works differently in different places", a less efficient implementation as you have to scan the hash and the environment every time you set it (after modifications) to sync it etc. etc. but eina_hash is worse because now you don't have any ownership of the strings. do you have to stringshare_add them when adding to hash? or just cosnt char *'s? if the latter then we have all the nasty problems putenv() does (see manual pages - but specifically that the string ptr is used AS-IS int he env so you cannot release the string you pass in - it's not duplicated and so tracking this string's lifetime and ensuring it's duplicated and kept alive as long as in use etc. etc. also nukes the idea of an eina hash).

Note that the usage in efl_thread.c should and could be removed. the problem with its usage is that when the ARGUMENTS event is fired, noone ever had the chance to subscribe to the loop of the thread yet. So all in all this is unneccessary, since noone could ever touch that.

aaah ok. i don't have one of those set up... i'll see. shelf seems fine though

The old API is not really definite, the API specifies that the API sometimes mirrors to environment variables, sometimes not. Considering the situation of this within a thread is quite a problem, since i don't know if i am altering the environment variables of the process or not, same argument for the efl_exe class.

shelf or bryce/gadget bar?

how is this better? it makes creation of a process with a modified env more work. multiple objects for no apparent reason (surely not given here in this patch). having env be part of a task is realistically what an environment is. it's part of a process (executable) and threads (they share the same env and it's implemented this way to modify the same shared env as that is the definition of an env within a process) and on an exe it's setting up an env in preparation for the actual execution (after which it can't be modified just like an environment actually works). why an object vs part of an existing class/interface? why is this better?

ok. that's something more concrete. 512 is a huge size... like insanely huge. but ok - some info as to the kind of sizes you are looking at. thanks!

I updated my benchmarks for the intl Atom - the system wasn't completely idle. fixed that now. was idle. still tells the same story relatively speaking of blist vs list.

@ProhtMeyhet you seem to have slightly older hardware than me, but that indeed shows the same trend as my benchmarks.The trade-off of cache friendliness vs some extra work in shuffling small arrays around seems to pay off. Well in all cases except @ManMower :) Thanks for the extra numbers.

@ManMower - it seems your machine is an outlier so far, but i guess the principle still counts. I should modify the brenchmark to pollute cache at times, but then the benchmark needs to do its own timings as it has to ignore the pollution bits, so it's going to become a fair bit more complex than it is.

I did some benchmarking across many machines, generations and architectures. I scripted it as part of a build script. All binaries were compiled with -O3 -march=native (except on aarch64 where -march=native is not valid). The results are consistent: That BList always wins, and the wins get much bigger the longer the list and the less the list fits into cache. These are run times so the shorter the run time, the better. On the 32bit ARM systems and on the Baytrail Atom system they did 1/10th the number of loops so they complete in a reasonable time.

Admittedly my numbers were on aarch64. But don't misunderstand list length being the real factor. It's cache hits that is. BList is intended to reduce the downside of cache misses very specifically. It's reliant on that. So lists that don't stay in cache very much are going to be far worse on Eina List vs BList. The length in this test is more a measure for "how much of the list will be in l1/l2/l3 cache". The bigger the number of items, the less will be in caches (or less in L1 vs L2, less in L2 vs L3, less in L3 vs RAM). I maybe could have putt in some code to pollute caches regularly between ops as well as well as a "how often to pollute caches and by how much" as part of the benchmark. I could adapt the test to do this explicitly. I was relying on a very simple factor of list size determining cache hits vs. misses.

yeah - but what are these benchmarks? where does this ACTUALLY happen enough?

I'm curious... in what kind of benchmark/situation did this actually make a measurable difference? :) I never saw this function in any profiles (well not near the top of anything) so it never was looked into.

still there?

neon is enabled on aarch64... has been for a long time... :/ aarch64 technically doesn't even need the neon checks. neon is default on aarch64... everywhere. :) sve is new... but not available in silicon yet. i was about to do some sve work but realized i had no silicon to test it on (and i didn't have the patience to do it in a sw virtual cpu system...), but i had done the detect work so thought i'd push it anyway.

neon use was never hard-coded. it used the same detection infra we had for x86 and altivec - runtime detection and then enabling of the calls to the neon (or mmx/sse3 etc.) asm functions instead of the plain C ones

fixed by 01ed58d52d878ea51e7d5dd66f812b8e17f33cb8 i hope.

why disable neon even on 32bit? it's runtime detected and enabled if the cpu supports it at runtime... :)

hmm i think you have a specific ifdef path different to all my machines.NEED_FEATURE_TEST is not defined for you i am guessing. did you disable neon explicitly?

hmm no - autofoo build works.... for me on aarch64.

oh wait.. autotools build. not meson.... let me check.

eh? i am building on aarch64 all the time... my main office desktop is aarch64...

btw - with code generation it'd need to understand the idea of not just read 1 pixel, write 1, but possibly read 2, 4, 8 etc. and write 2, 4, 8 (that's not including scaling/map transforms that need to read many samples, merge somehow then write)

this seems odd. the signal is sent when finishing walking the launch app list.... and e doesn't wait for these apps to exit to do this. so i'm not sure other than the theme not handling the signal but seemingly you say it does... :/ the theme change smelled of this being the issue... so i really am not sure what else then... :/

just checked on debian testing - it includes a libpng.pc... so not sure about ubuntu but this seems now an ubuntu specific issue... check your pkgconfig dires and libpng*.pc files.

indeed ordering may be an issue - some properties may be affected by the state of other properties at the time they are set... :)

this is specifically a ubuntu or debian issue - arch ships as upstream does with a libpng.pc so checking for just libpng via pkgconfig as efl does works and links to libpng 1.6. (and minor version upgrades until a libpng2.x will just work too).

we're not policing the calls at the C level? eolian_gn can auto-generate the checks so it's possible... :)

I think you think EFL is in better shape than it is... :) If EOID is turned off then a lot of current "it's safe" paths become dangerous INTERNALLY in efl. if there is something i learned is that 3rd parties will. use efl is all sorts of bizarre ways we never would and they find all the untested paths and then hit much bigger errors as a result. i think it's very unwise in return for a fair small performance gain.

well it does open the door but this is something we would police at the c level anyway (or should) and at least print errors for calling unapproved calls before finalize on an obj.

i really liked the lambda callback as this then also translates across many languages (js, lua, c++) too... with C being able to skip he lambda fluff and just inline the code directly without it. it's consistent for efl. this is NOT a feature you MUST use. it is optional, so i'm not sure that it is that confusing as you aren't forced into it. it's a (possible) optimization if you want to make use of it though.

the theme doesn't emit a signal back to say the init splash is done fading away/ending? so e tells the init splash to exit with:

It's dangerous to remove for the following reasons:

@ManMower - good you looked.there could have been low hanging fruit and iv'e found a very low hanging fruit in eet recently in the design of the dictionary. it totally does not scale across threads. it actually becomes insanely slower the more threads you have... so using edje_cc's threaded mode is a lot slower than without because of this. it's a low hanging fruit to speed up edje_cc's threaded mode and any multi-threaded use of eet when writing, but i haven't had time to look at it more beyond identifying it.

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