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
This adds filter support to Image objects as well.
The exact same filters can run on Text and on Images
(provided some colorspace limitations are respected).
This basically adds:
- Support for RGBA input buffer
- Eo entry points for Image filter support
- Implement basic filter support in Evas_Image
It was a pretty stupid idea to write a parser for a custom language
when we already have Lua as a dependency and it's so beautiful and
easy.
There is a fallback function to allow for compatibility with legacy
filters. But that broken syntax is not recommended. I'll probably
remove it soon.
All the test cases I have in my example app work fine with this
compatibily layer.
The new files (i386, sse3 and neon) are basically empty and fallback
to the C version. This is just to pave the way for full low-level
optimization... if someone has the time and skills to do it :)
Add both Alpha and RGBA template files.
During padding calculation, ox and oy should be ignored unless the
blend operation is neither repeating nor stretching. Otherwise,
the buffer will grow without necessity.
This will allow forcing a specific value for the filter padding,
instead of relying on auto calculation.
Two advantages:
- Auto calculation can't be perfect, since it will add as much
padding as required for the full blur effect
- This prepares the path for animations with effects, where the
object size does not change over time
If the buffer size is smaller than the blurring kernel, then
special precautions must be taken to properly read the source
pixels. Also, fix the corner cases near the left & right edges
(or top & bottom).
When blurring an RGBA buffer to the output buffer,
we don't need to convert the colorspace... but then we'll just
override what was already there.
Introduce a 'dirty' flag set to true whenever a command writes
to an output buffer.
Use two optimizable functions for BOX blur: vertical and horizontal.
These functions will run as many times as requested (from 1 to 6 max).
The horizontal case is pretty straightforward as the source is already
contiguous (nice in terms of cache hits). The only catch is to swap
src and dst without ever writing to the input buffer.
In case of vertical blur, we apply the same method as above, after
rotating the column into a horizontal (contiguous) span, and rotating
it back afterwards.
Now, the same needs to be done for RGBA :)
BOX blur is a lot faster (and easier to optimize, too)
than GAUSSIAN blur. Repeating 2x or 3x BOX blur will also
give similar results to GAUSSIAN blur (very smooth), but
in much less time.
Add a count parameter to the BOX blur instruction.
Actually, there is a very nice trick with BOX blur.
Pass BOX blur 3 times and you can approximate a GAUSSIAN
blur with up to 3% accuracy. This is way more than enough
for just a simple graphical effect.
So, despite the crappy quality of BOX blur, we should
optimize it a lot so we can replace large GAUSSIAN blurs
with series of BOX blurs instead.
Source: Wikipedia's page on box blur :)
This commit also moves around some duplicated definitions.
When a blur operation requires a copy-back to the source
buffer, then the render_op must be set to COPY instead of
BLEND. Otherwise the non blurred content will be visible.
@fix
Prepare optimization paths for blur operations, as they are VERY
costly. This simple change, when using gcc -O3 flag, boosts
horizontal blur performance by > 50%, because STEP is 1 (and
so, memory accesses, increments, etc... are all very simple)
The objective is to have support for NEON, MMX, SSE, too, with
runtime detection.
Remove true Gaussian kernel code, as it is not usable over 12px and
was disabled because it gives different visual results than the
fake Gaussian curve using sin().
Jean-Philippe Andre
Jean-Philippe ANDRE
Tom Hacohen
Jérémy Zurcher
Cedric Bail