According to cedric's horrified comment :)
And add a comment in the code. Yes, this IS a temporary solution,
but the GL engineS being what they are (tons of duplicated code),
I think it's still better for now to just make things work.
Directly use the scale functions from scalecache when
running the GL engine.
With this, and glReadPixels support, the GL engine support is now
100% complete. It will be DAMN SLOW, but ALL filters should work
in both OpenGL and Software rendering.
Make use of glReadPixel to access the source's pixel data.
Use all classic CPU functions to blend and use that data.
Save pointer to the GL image and update it with the latest data
during target render.
Use ENFN's surface_lock, read_pixels, unlock.
Also, add some more error checks to make sure the images are valid,
or return an error at runtime.
This will inform the client whether an asynchronous filter properly
rendered or not.
I actually don't know any case where rendering can fail at runtime.
The structure should not be changed, despite the union modification.
I am renaming for consistency with older branches that had a mask
field in RGBA_Image. Also, the mask.data or data8 is really just
a way to avoid casting between DATA8 and DATA32 (and it shows
clearly what kind of data you are dealing with).
It was possible to keep negative values for dx,dy which would
then draw pixels out of bounds (= crash).
Make check crashed after the previous commit.
@fix
If the filters fail to render at runtime (that is, parsing went fine
but a command failed to run properly), fallback to normal rendering.
This should prevent text from disappearing when using proxies and
the OpenGL engine (for now).
In some situations, text with filters would be rendered in an invalid
position (somewhere too high).
I am not entirely sure of the reason why the original code with BLEND
doesn't work, but this new version is simpler as GL and SW have more
similar behaviours:
- render text to our 'output' buffer
- draw this buffer as an image onto the set target
Thanks zmike for reporting the issue.
And thanks A LOT for using the filters :D
@fix
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
If a text object changes regularily, there might be cases where
the object will be rendered as a simple black rectangle for just
one frame.
It seems that the previous output buffer is deleted before being
actually rendered on screen. This patch will delay the deletion
of the previous buffer until the current one has been rendered
to the target surface.
And again, thanks zmike for reporting.
@fix
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
A CRItical message was always displayed when setting a filter
on a text object, saying that proxy rendering is not supported on GL.
Reduce CRI to ERR and skip proxy rendering altogether if there are
no proxy sources.
This @fix needs to be backported.
Thanks zmike for reporting this.
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Allow repeat fillmode in blend() for:
alpha --> alpha
alpha --> rgba
rgba --> alpha
Alpha scaling is not implemented yet, but it is not actually
required. Indeed, only proxies can have a different size and
proxies are RGBA images, not alpha.
Alpha scaling may or may not become a requirement in the future,
or for other purposes, but not yet.
When using stretch, all buffers were actually drawn 4 times
on top of each other. This was not visible because in most cases
these buffers were all opaque (alpha = 255 everywhere).
The documentation said color was used as a multiplier, but in
reality the image drawing functions don't use the context's
color when drawing. So the color is only defined for Alpha -> RGBA
operations.
The Windows build (mingw) does not know about strtok_r.
So, let's use the non-safe variant strtok instead.
Currently, this function is called from the main thread only,
so this should be fine :)
In the future it would be nice to not use strtok anymore,
but strtok_r everywhere, and add it to evil. Considering the
release coming soon, I'm not going to change something like that
now.
Test case was:
buffer : a (alpha);
blur (20, dst = a);
blend (src = a, ox = 30);
In that case, padding was 20, 30, 20, 20.
So the blurred buffer was clipped on screen.
If the displacement map has some alpha values (not 0xFF),
then the blending should take this alpha into account. This
part is fine.
BUT, since Evas relies on premultiplied colors... we have a
problem: R (dx) and G (dy) have already been scaled down.
Actually we would need to load the map in non premultiplied RGBA,
otherwise we'll lose precision on dx,dy as soon as A != 0xFF.
Well... I guess this will be a limitation of this filter, for now
at least. Most displacement maps shouldn't even have any alpha
anyways.
In Doxygen format, write the reference documentation for the filters.
It will contain a few examples only, should serve more as a reference
just like edcref.
This is for the script language itself, not for the Eo APIs or the
internal APIs (those are already documented).
Since the transform operation is (for now) a very simple tool,
it only works when src and dst have the same colorspace.
This commit forces users to specify dst, since "input" and "output"
have different colorspaces.
Also, remove globals A, R, G, B from parser.c... these are
temp variables used in a macro.
My CFLAGS didn't include -Wshadow so I missed those.
Thanks Tom for spotting :)
Some features are not supported (mainly because alpha scaling
has not been implemented yet) in the blend API. So, instead of
rendering the wrong effect, fail with an error message.
Also rename col into color for code clarity (we have cols for columns).
Well, proxy sources are rendered to a... GL texture! But we
actually want the image pixels. So we'll need to call glReadPixels
to get them.
Yes, it will be horribly slow. But there isn't really a way around.
This will require a new internal API. For now, just disable the
feature. Hopefully I can make it work soon enough for the release?
If source_set was called after program_set, then parsing would fail.
It used to work because the program was re-parsed at source_set.
Now, save the code, mark the filter as changed, and reparse again
if the source changed (keep track of invalid programs to avoid
excessive parsing).
In async mode, the filter runs in the render thread, so can't
allocate buffers on the fly.
This case should not happen, unless maybe a source has a null
size (eg. it's invisible and not properly rendered).
Proxy sources & objects were not properly unset.
This results either in crashes (especially in the Edje tests)
or dangling objects with tons of references.
Remove the refcount increase/decrease, as it is redundant.
Store pairs proxy+source instead of just the source in all hashes,
so we can unset the is_proxy flag on the proxy when there are no
sources anymore.
Remove compilation warnings: we don't really need cubic
interpolation at this point, we can still add it back
later if wanted.
Also, make it clear that buffer #2 is the output buffer.
Remove meaningless FIXME.
Use the mapped rendering to implement repeat and stretch
with rgba to alpha buffers blending.
If stretch is required, it will add one more (expensive)
scaling step.
This patch implements the final draw from RGBA_Image to the
OpenGL surface. We can even steal the output buffer and
redraw it quickly, without having to re-render everything
(same as in SW).
Since the filters will have to decide on which engine (SW, GL) to
choose from to render the font and the effects, move the font
draw call inside the filters module.
Quick and dirty solution to support the OpenGL engine:
[1] Allocate CPU buffers
[2] Render text and process all effects to these buffers
[3] Push final image as an OpenGL texture.
This patch implements [1].
It is not possible to logically handle padding and offset at the same
time for a proper mirror effect, unless this is handled directly at the
transformation level.
Also, add support for blend() operation padding computation.
This is the simplest solution I can come up with for "mirror" effects.
Displacement maps are HARD to generate and use properly, since the buffer
size is unknown until runtime.
Even if we align the map to the text itself (using the padding information),
it's still hard to describe properly how to apply the displacement map, and
to generate it... So let's just add a simple flip operation.
The displacement effect is way too complicated. Let's keep it
simple and have only one displacement map format (RG + Alpha).
Here's what's missing now:
- Alpha support, to blend in the input with a variable intensity
- Extra padding (see below)
Also, the intensity VS. map values are not perfectly defined yet.
Problems: How to create a complete mirror effect (map needs to go
over boundaries... add extra padding to the buffers).
This is the first possible optimization: save the rendered
text (since we already have the output buffer anyways), and
reuse it if the text + filter didn't change.
Add parameters l, r, t, b to clip the fill area.
While l=x and t=y, the width and height of the clip are determined
at filter run-time, since we don't know the buffer size before.
Brutal method for now: allocate YET ANOTHER buffer,
render scaled image to it (smooth scaling, oh yeah),
use this as a new mask.
For now, supports:
Alpha Input, RGBA mask, RGBA output, X,Y,XY stretching
Syntax was: buffer(name=bla,alpha=bool);
Changed to: buffer:bla(alpha);
There's a semicolon between buffer and its name because ALL whitespaces
are discarded. This might prove useful sometime in the future, so let's
keep it this way for now :)
Jean-Philippe Andre
Jean-Philippe ANDRE
Carsten Haitzler