aaah ok. that's a good selection there. thanks! :) so impact can vary from almost nothing to "pretty big". at least it's an option - aa and smooth on at the same time i think is good enough. if it was not that much more i was going to suggest we adopt it as the default "smooth". :)

I'm not going to have time for a few weeks...

i can't reproduce... now that autotools is working enough again...

autotools was broken for me anyway. so i couldn't build with it. iut literally deleted files committed to git and failed to build part way thru

going to close this as 4758f06e637239f981eedbaaf8c0d613b78e4417 solves it better by moving to tiled rendering

on arm32 the tiled rotate is 2.4x faster vs the neon. the neon interestingly is also about 1.8x faster than the plain C code.

ok i checked on arm32 and yeah - the neon is broken. but... it's half the speed of the tiled rotator... so why fix something that is slow when we can just switch to the faster one. :) i think its best to reject this and instead just remove any rotate code/paths that are not the tiled rotates... :)

forecasts doesn't work for me - only says it supports us zip codes (and i don't live there) and can't enter anything in the entry box there in settings anyway, so can't test it.

justr one thing i noted... why aren't we just doing tiled rotation by default anyway? in terms of pixels/sec its almost 2x the speed vs ye olde C. i'm not sure the neon would even be 2x the speed of C... so... anyway. i need to check more...

argh... just realized this isn't used on aarch64 - only 32bit arm... i need more time to check on that as now my more accessible arms are all aarch64 :)

what's the performance difference on a range of devices/architectures?

do we need this if we have D8104 ?

give me a bit... just saw this and need to look at it more, BUT the if ((w & 1) || (h & 1)) is a simple "if width or height is odd (not a multiple of 2) in size). this is kind of lazy as the neon can still be used EXCEPT for the "edge pixels" where it can fall back to some C. I'll need to read this a bit carefully to figure out what's wrong (and maybe try some things out).

probably not even an error we can fix. this is probably something to bring up with the appropriate driver developers, but even then may never be fixed. also note you may hit a limit at 126/127/128 or so or maybe 254/255 as xorg has a limit on client connections and last time i hit it, it was 128 clients (e will have 1 connection at least itself to start). so you'll hit a wall/limit like that that will probably be far before you hit a ram limit these days. as i said the 20/30 limit smells like a driver/gpu limit in maximum number of contexts or something similar. we impose no limit in efl and even if we did it's be per process, not globally.

i couldn't say anymore - fbsd has since my build shot itself in the face. perhaps i did have some inotify lib installed... but i managed to build efl, e, rage and terminology...

err sorry

are you building with meson there? looks like it.

bbdb2e5c23139d96b6fa57633f9a73e85ea6e7d6 i hope should fix this. i also found a few other loose ends regarding environ related things and fixed those too. my fbsd vm tho is having other issues (meson cant find libintl.h and it isn't respecting CFLAGS when looking for libintl.h ...:() so my fix above is a guess, but a decent one based on the fact that efl_core_proc_env.c was indeed missing the extern char **environ declaration and uour comment above that it works.

likely related to @bu5hm4n 's changes

see inline questions :)

hehehe yeah - tho .. xterm vs terminology should be enough to compare :)

keep the tests simple then - don't go too far in trying to test it as it just can't pass on all platforms. like you say - with large numbers it might not be that useful etc.

actually raise and lower mean to top and bottom commonly. xrwaisewindow and xlowerwindow certainly do. in Qt its raise() and lower() methods.

this makes the c definitely worse exactly as i described and it is not niche usage. the ownership is even mixed up between strings and the array.

fixed by c1c3af7412e1f451bbd7f4df57226f4847d1b446

oh this is very simple it seems... there's a double "next client" when showing the winlist... :) it's not efl - it's an e thing.

pointing me to this leads me to "argh there is broken stuff here". just the way that the bg is placed in the canvas, how it decides to do multiple screen wallpapers etc. - i think i need to redo a lot of this code... but i've fixed this immediate issue

i had to make fixes as you removed some include blocks that are needed still for other inet funcs and missed adding linking/headers to other code.

fixed. tnx.

i don't even know that we get an error or can detect it. we do things like check the return of glxcreatewindow and error out and complain what failed. it seemingly is not failing. if we don't see things failing from the glx/egl api then we can't do anything about it.

;)

what popup?

I have some data for hid devices with batteries. these are real devices with rechargeable batteries and ... I actually see proper reports. Note that my mouse (MX Master) showed "Unknown" until I unplugged it to run wirelessly for a while - then it started showing Full as the charge level. The Craft Keyboard shows Full. Here they were plugged in:

Saying "that's what OO is about - you inherit and modify the behavior of things appropriately for that object type. ", without any form of constraint is just wrong and dangerous.

as cedric said. it should be properties.

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.