:) :) :)

hmmm... we're in massive conflict land here. :(

i'm not sure i like this change - the UNUSED macro is much nicer/better... :|

Well they were already longs - I just made it explicit with the cast. The test is broken on 32bit already. In fact eina_value is broken on 32bit SPECIFICALLY with longs and you are right - windows on 64bit here will behave like 32bit in these cases. Already broken. :(

oh while i'm at it...

i had some stale forecasts config that didn't have a server to contact in it....

hermet. you need to take a good hard loo at this. i''m seeing coordinates that are negative and i think other out of bounds coordinates as well. you need to have extensive tests with different resolution input, output, many angles and so on... i've already put a quick and dirty fixup for negative uv coords, but even with that i see rendering bugs in some cases. :)

it seems this breaks on osx:

so do you think that there is a problem if we define _POSIX_C_SOURCE just before including time.h in Elementary.h and Efl_UI.h ?

much better! :)

@bu5hm4n thanks for pointing that out :)

move these just above the:

how doe sit break bsd?

expedite is not the right test for this. things like elementary - like genlist and things that create, destroy and move objects in and out of parents and have complex call trees - those are the things u need to look at

what they said. this is going to be costly...

hmm whilst unicode says they are emoji.. they don't come out as ones according to terminal apps so yeah - keep the entire range out.

the problem is 25AA, 25AB, 25B6, 25C0, 25FB->25FE are emoji...

oh i had an idea over lunch... store sd->text in a local var and do the free at the end of the function. then it can't ever be an invalid pointer. the check for it being the same ptr can avoid doing the duplicate and the free to as it does now so store and move the free before the done label and there will be no crash. right?

small change i think ... it's less code and less prone to error.

but those functions then access the globals anyway so it's just pushing the problem away one level into another function, and if someone forgets a RemoveSharedStyle() call just like the list remove above - same thing happens. it's not really any different. these functions are indeed good to avoid copy & paste code if you have lots of places that do the same list remove and to be fair - efl has a lot of things like this that have crept in over many years.this is an area that efl could do with some attention to look for "copy & paste" code even if it looks different on the surface and possibly has minor difference (that could be bugs - careful thought and attention would need to be applied to see if they are really intended or not). if these bits of code can be refactored to share more common functions like you describe above where there is duplication, code size can be reduced and the chances of future problems where a list remove is forgotten in 1 case but not the other reduce. so to some extent you have a point, but in this case there isn't anything really to gain. indirection to a function which is all of 1 or 2 lines of code is generally not that useful. if its a larger blob of complexity then it'd probably worth a look. :) i hope this serves as some encouragement and guidance. in this case you found a bug, but your solution is IMHO with the above functions won't help IMHO, but there are enough other cases where this is really needed and you'll get little argument over :) i know the code exists. i know i've been guilty of doing it myself often enough. :)

@bu5hm4n is right - this has nothing to do with globals. it'd be the same as if obj->styles = eina_list_remove(obj->styles, ts); was missing in the free func for the obj.

;]

;]

yup. no big difference. ok. i'm comfortable with moving to float entirely.

there isn't a single control. evas has various caches, edje has, there are mempools and those are set up by code, and so on etc. etc. - so you'd have to tweak various things to force free and some cant be force freed at all without modifying the code to no longer use a pool etc.

you'd have to stress it and re-use a lot of objects to see if there is a leak. we do have memory pools and trash etc. like @bu5hm4n says - we alloc and keep around that memory then re-use it again. you'd have to do a lot of allocs over and over and then see the mem footprint keep going up and up and never stabilizing. i adapted your code a bit to do this with a timer ever 0.01 sec:

;]

;]

because the canvas didn't go through a render cycle - nothing changed visually thus it didn't render. it has to actually go through a full cycle. try show some of those rects and leave them there for 1 frame.... then delete them.

because evas object deletions are DEFERRED. they require render cycles to drive the deletion. they will be kept around for 2 render cycles so evas can do a prev state vs current state check., imagine u delete a visible object - how can evas know what changes - what area is occupied that now needs re-rendering? was it visible or not, was it set to a color of 0 0 0 0 which EFFECTIVELY made it invisible to rendering even if it was shown... thus objects invisibly have extra references to them that are removed if delete flags are set by the render cycles, so the above case is just "invalid" in that any real process will never do the above and will have a fairly limited upper bound on how many objects will be created then deleted before a render cycle happens. if there really is a very big spate of creating invisible objects (e.g. you're using evas as an image processing engine where you might load an image file into an image object then save it out as another format) then there is evas_norender(evas); which does a render cycle without doing the actual rendering thus driving the object deletion pump. it's an incredibly rare day this is ever needed and if it is used, any updates from objects that really did need a render will be lost. you would need to manually add a damaged region for the whole canvas output to force a full re-render to avoid this if this ever were the case.

:)

actually struct passwd and getpwuid are probably a major problem...

I mean weak performance is "weak point" as you can see the video attached.

But obviously, efl animation show us very weak performance than other decent frameworks.

this has a downside. it doubles the memory needed for coord storage/copying to gpu etc. .... that will mean some performance drop and the only benefits are when using msaa... but even then evas object geometry is done with integers only so it can only help with map and even then map reduces to integers anyway at the engine api....

that is indeed a bug... thanks!

this does have a problem - nothing ever calls eina_freeq_reduce()/eina_freeq_clear()/eina_freeq_reduce(), so anything put on this freeq will never get freed until process exit.

@Hermet - actually gl rendering is still sync mode... :)

:)

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 :)