oh... just push it :)

yeah. what @jf_simon said - i get them as i have enabled all 3 levels of notification... :) so... works for me. :) this is perhaps something to address in future to make it possible for one module to modify config of another... or roll notification config and functionality into core E and out of a module? yes - small usability issue. I might actually say that the mixer should show its OWN popup when changing volume so u see the slider... and not use system notifications. but this is a polish/prettiness thing.

we're good now. can be better using ecore_con_url and probably have some things be real buttons/links to yahoo.com so u just click the link or a built-in place name search/browser... but... this is a good step so thumbs up. :)

:) :) :)

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.