In C we need this to make clear that we really do not accept parameters.
Found by the smatch source code matcher. I had run and fixed this before
but it seems to creep in again over time.
Clang 3.9.0 told me:
warning: passing an object that undergoes default argument
promotion to 'va_start' has undefined behavior [-Wvarargs]
So I told it to shut up and changed Eina_Bool to int.
Note that edje_edit_state_external_param_set has the same issue.
Coverity reports that we are missing breaks in the switch blocks here,
so add missing breaks.
Fixes Coverity CID1347413 and CID1347414
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This reverts commit 546ff7bbba.
It seems that eo_del() is useful and removing it was creating bugs.
The issue is that the way we defined parents in eo, both the parent and
the programmer share a reference to the object. When we eo_unref() that
reference as the programmer, eo has no way to know it's this specific
reference we are freeing, and not a general one, so in some
circumstances, for example:
eo_ref(child);
eo_unref(child); // trying to delete here
eo_unref(container); // container is deleted here
eo_unref(child); // child already has 0 refs before this point.
We would have an issue with references and objects being freed too soon
and in general, issue with the references.
Having eo_del() solves that, because this one explicitly unparents if
there is a parent, meaning the reference ownership is explicitly taken
by the programmer.
eo_del() is essentially a convenience function around "check if has
parent, and if so unparent, otherwise, unref". Which should be used when
you want to delete an object although it has a parent, and is equivalent
to eo_unref() when it doesn't have one.
We used to have eo_del() as the mirrored action to eo_add(). No longer,
now you just always eo_unref() to delete an object. This change makes it
so the reference of the parent is shared with the reference the
programmer has. So eo_parent_set(obj, NULL) can free an object, and so
does eo_unref() (even if there is a parent).
This means Eo no longer complains if you have a parent during deletion.
I just ran my script (email to follow) to migrate all of the EFL
automatically. This commit is *only* the automatic conversion, so it can
be easily reverted and re-run.
This patch fixes an Coverity issue that if 'dst' gets set to NULL (as can
happen above) then this eo_do call may segfault as it is directly
accessing 'dst->buffer'.
@fix
CID1347415
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
out was simply not initialized if the source and destination
were the same. The COW flag is required here to separate input
and output properly. Also, the source & destination pointers
were badly calculated and could overflow.
Instead of using memcpy this filter was supposed to use the
blend functions. This patch also fixes that.
In order to make this filter actually useful (think text reflection
on a flat surface), more information needs to be passed to the Lua
script, such as the text ascent, descent, etc...
This is a minor change, makes 'output' the default target for
the transform filter. This is consistent with all the other
filters. This is not exactly a bug fix but it doesn't break
compatibility with the earlier explicit form and improves the API
for 1.17.
SW async render mode was broken because it was party sync, partly
async (bad hack in a recent commit). This patch fixes that by
using a proper callback for render_post (main loop).
Since the engines and ector now abstract all pixel access functions,
the only difference between GL and SW is the async rendering.
This implements a generic way of scaling buffers, using fake
RGBA_Image wrapping ector buffer maps. The underlying algo is
still the good old linear sw scaler.
Now the filters *should* be back to their previous level of
usability. Performance will probably be even worse than it was
before, for GL, as more glReadPixels may be involved. Optimization
now consists in actually implementing the filters with GL shaders.
Evas filters is now more and more unaware of evas images (RGBA_Image)
and the engine + ector take care of everything.
Still left to do:
- map / unmap an FBO buffer into RO or RW memory
This fixes crashes, adds safety, and notes a couple of things that
are not yet implemented:
- Make an Evas_GL_Image from an RGBA_Image so we can draw it on the
canvas. This means Evas.Ector.GL.RGBA_Image.Buffer
- Readable Evas_GL_Image objects with gl_read_pixels
--> Implement proper map() & unmap() for GL buffers
Since Ector Buffer implicitly converts colorspaces, we
can allow more commands to work even if they are suboptimal.
Now all filters should support any combinaison of input, map/mask
and output colorspaces.
This is a major refactoring of the evas filters submodule.
Use Ector.Buffer and the map/unmap methods instead of directly
accessing image buffers with RGBA_Image. RGBA_Image is still
used under the hood, for two reasons:
- Required for the final output (blend onto Evas itself)
- Required for the scaling routines
FIXME:
- Breaks proxy support (ie. all kind of texturing).
- This breaks filters support for the GL engine.
This operation was faked by running a mul and a blend ops. Now
they are combined into one. A GL shader should also be able
to do this in a single pass.
In a rare situation the filter would access an invalid buffer.
Solution: Stop messing with buffer references by properly
referencing and releasing them when not needed, rather
than stealing references and hoping for the best. (There were
flags tracking stolen references, but that was still madness)
After clip_image_get, the old mask may be replaced by a new one,
and unref'ed, but it is later on set back as the context mask image.
Maybe it's possible that there was 0 reference and the image
got freed in between.
No idea how to test this.
@fix
In order to do that, avoid creating multiple Buffer instances
when pointing to the same proxy source. This fixes buffer.width
and buffer.height in Lua.
This fixes filters on Ubuntu 32 bits.
This was one hell of a weird bug to track down. Everything worked
like a charm on my 64 bit machines, but filters would simply fail
for no good reason: a safety check sees a NULL pointer when clearly
it was properly allocated.
Just after entering a function, the content of an RGBA_Image would
change, even though there was no memory write there. This made the
image data pointer NULL, and filters would fail miserably.
So I printed out the contents of the RGBA_Image, they changed. But
the memory itself had not changed. The size of the struct itself
had changed when jumping from one file to another! But its definition
had not! Non-sense!
Unless of course a system header file was included before config.h
and ino_t or off_t would switch between 32 and 64 bits...
@fix
For compatibility with previous behaviour and with what the doc
says, make sure default alpha is 255 and not 0.
This way color(0) is black and not transparent
The previous API supported stuff like "mask{'image1'}" but image1
is now not a valid buffer name, as it's only the proxy source name.
This patch fixes the buffer lookup.
This flag should be set iif the string passed is to be executed
rather than assigned. This is used to pass complex arguments
as data, like tables (eg. color class).
Makes sure that buffers don't override already existing
globals vars such as 'mask' (a function name). Yeah, it happened
to me.
CC support is a little bit hackish. Need to find a better way.
This should preserve ABI stability with earlier versions of
edje_cc while still providing more advanced control over
proxy bindings for evas filters from EDC.
Also fix proxy binding for filters.
@feature
Reuse previous code for buffer. Keeps API stability.
The new class "color" is here for a more convenient color
representation. This way, colors can be represented in more
natural ways like: {r,g,b[,a]}, 0xaarrggbb, "red", "#rrggbb"
Class color is implemented in pure Lua, and adds a .lua file
to Evas' share folder.
This will improve the debug output of evas and specifically
allow setting "evas_filter" log level to a higher or lower
value depending on what you are debugging :)
Now we're ready to implement runtime changes to the filters'
state (color classes, edje state, etc...), as the Lua function
will be run whenver required.
This is to prepare the changeable states (animation, color, scale...)
- Remove use of Eina_Value (simplifies code)
- Use proper Lua type for buffers (with pretty __tostring)
This adds the buffer methods: width, height, type, name, source
This will allow changing the state of the filter and re-run it
without re-creating the Lua_State object. This is to handle size,
color, animation state and scale changes (amongst other things).
When doing blur from alpha to rgba, there was an extra copy
step added, that was not required.
This should improve the performance a little bit in this situation.
The memory usage graph was going up and to the right!
I was told this is always a good thing!
... maybe not this time :)
Hopefully I didn't forget a case. An intense session of
genlist scrolling with masks all over the place and masks
of masks didn't show any glitch, crash or memory leak.
Idea originated from Cedric the b0rker.
This is a big fat search-and-replace commit.
This commit also introduces space changes... Sorry for the mix.
NOTE: This commit may have one side effect as there was some very
dubious code chaning the dst image's alpha flag in the
Gfx get functions. Logically this didn't make sense (at
draw time the dst alpha should already be well defined),
so it should be safe.
Here's a macro that's used for debugging in some of the ugliest
ways possible: avoid passing an extra argument to a function when the
cost of always passing it is negligible (it's an int).
Fixes T1749.
While it really shouldn't happen, let's just add a quick if()
and make Coverity shut up.
Fixes:
- CID 1191912
- CID 1191911
- CID 1191910
- CID 1191909
Make check would even fail on 32bit machines because of that:
Lua tables are not arrays and lua_next doesn't ensure the order
of the elements as I wrongly assumed.
@fix
Fixes T1615
We couldn't do evas_object_color_set() on a filtered text
object simply because the color was not properly taken into
account.
This should simplify some effects as it'll be much easier to
set a color or alpha value to the text regardless of the filter.
Hmm, is this a fix or feature? O_o
Stefan Schmidt
Jean-Philippe Andre
Tom Hacohen
Chris Michael
Chris Michael
Jean-Philippe ANDRE
Jérémy Zurcher