This still fails in some places...
Showstopper Issues (15)
until efl 2.0 ... can't happen. abi problems like @herdsman says. for then - sure. until then - can't.
Okay, I feel less concerned now. I assumed the treatment is the same as it was to a signed char.
However, upon further testing, the bitfield bool value was converted from the stored 1 to 1 (or: true), as opposed to -1, (which I expected it to be).
Looks like C99 adds an implicit conversion for bool types.
Fwiw, please consider that for bitfields of one bit (e.g. bool changed: 1;) the values will be 0 and -1 due to bool being an signed char. If we ensure consistency on usage it shouldn't be an issue.
completely agree on this one.
efl_ui_tags has been created.
@segfaultxavi Thank you for ur commit.
Unsure whether this is driver bug (on Intel, so probably not), but when opening a lot of glview windows there's definitely something broken. Only tested with gles build, so could be local to that codepath.
I think until we get Windows builds running on CI (a priority during the 1.22 cycle) then ultimately any work we do will have to ignore untested platforms. It may be good to start a tracking ticket for things like this so that the items can start to be resolved once we are regularly building the tree?
Okay great, thanks for doing the extra checking!
I guess D6585 is more proper to apply.
this has been lurking for a while and me, jpeg and cedric all said basically "it's invalid". pixel get cb is not called every render if the obj is visible. it's called evas thinks the obj needs rendering. it may not actually be rendered or be visible to the user/output of the canvas, but evas thinks it needs it.. then it'll call it, but it was never a "call always at every render if this obj is visible logically at all". as jpeg said a render pre/post could do this and iterate over all the obj's that need this but it's not what the pixel get cb is for. so finally doing what jpeg said.. closing as invalid. :)
I can't reproduce it. opened 44 elementary_tests.... everything rendering ok for me... :/ amd radeon vega64 with mesa open drivers here and opengl (not gles) compiled for efl... :(
Never said it was okay.
Anyway, if you believe this need to be fixed at some point, please open a ticket.
We can decide on the priority for win32 builds.
Got raster here to shoot down the bad bugs :)
That doesn't make it okay.
I too was concerned about it. However, efl_add and efl_add_ref are both implemented in the same manner.
This will obviously cause issues when e.g. using an efl dll on Windows with visual studio toolchain
keep in mind that this is not portable, it's a GNU extension, so not sure if it's a good idea to use it in a public header
I thought about it, but ended up preferring the explicit solution. I briefly scanned and didn't see EINA_MAGIC_CHECK used as a null-check replacement.
Looks like we found where the value changes:
I wonder if the magic-disable code should be a null check? I imagine there's a lot of code which might do this, but maybe I'm wrong.
Bug is still there with efl-git 1.21.0alpha1.59380.g655c5ee6e0-1 (Linux Arch Aur).
It disappears if I restart enlightenment then it reappears after half or one hour.