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". :)
Fri, Mar 15
I'm not going to have time for a few weeks...
Tue, Mar 12
Sun, Mar 10
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
Sat, Mar 9
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... :)
Fri, Mar 8
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 :)
Thu, Mar 7
what's the performance difference on a range of devices/architectures?
Wed, Mar 6
do we need this if we have D8104 ?
Tue, Mar 5
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).
Mon, Mar 4
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.
Fri, Mar 1
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...
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.
Wed, Feb 27
likely related to @bu5hm4n 's changes
Tue, Feb 26
see inline questions :)
Sun, Feb 24
hehehe yeah - tho .. xterm vs terminology should be enough to compare :)
Feb 15 2019
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.
Feb 13 2019
Feb 12 2019
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.
Feb 10 2019
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.
Feb 8 2019
Feb 7 2019
Feb 2 2019
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
Feb 1 2019
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.
Jan 30 2019
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.
Jan 29 2019
Jan 25 2019
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:
Jan 24 2019
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.
Jan 23 2019
Jan 21 2019
though one question - when does this happen? like during shutdown or something like that?
Jan 16 2019
ACK - go land it.
git log src/lib/ecore/efl_io_closer_fd.c
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.
Jan 15 2019
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...
Jan 13 2019
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.
Jan 12 2019
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... ?
Jan 8 2019
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.
Jan 4 2019
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
Dec 31 2018
@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.
Dec 29 2018
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()
Dec 28 2018
I don't have much idea on how to write a useful test at all here.
Dec 27 2018
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?
Dec 26 2018
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?
Dec 20 2018
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.
Dec 19 2018
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.
Dec 17 2018
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.