Summary:
These APIs will be used for adding font paths for the application.
The existing APIs for font path, such as evas_font_path_append,
are used for adding font paths to the given evas.
But, these APIs will affect to every evas in the process.
Reviewers: tasn, woohyun, Hermet, seoz
CC: cedric, herdsman
Differential Revision: https://phab.enlightenment.org/D621
@feature
Clipees can be cleared before the loop is finished because
evas_object_clip_unset calls smart function of clip_unset.
So, if we use EINA_LIST_FOREACH_SAFE, invalid next list pointer
can be kept and read after obj->clip.clipees is freed.
Thanks to Davide Andreoli for reporting.
@fix
This happens with many texts. The issue occurs when the width of the
last char is larger than it's advance. Before this patch, we didn't the
width into account when calculating width, thus causing clipping issues
in some cases.
You can add in the .eo file the eo_prefix:... and data:... in case
you want to override respectively the Eo prefix and the data type.
If "data: null" is used, no data type will be added.
The build system only adds top lib dir to include path, so we have to
specifically put the path there.
This should probably be fixed, so we can drop the canvas dir prefix in
our includes altogether, but until then, this is needed.
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 be needed by the filters for proxy rendering,
for textures and maps (displacement).
Add new engine functions to unleash the (sluggish) power of glReadPixels.
The idea is to be able to bypass glReadPixels later, so 3 new APIs are
added:
- surface_lock
- surface_read_pixels
- surface_unlock
They must be called in that order.
Note (for history):
glReadPixels was always getting the wrong data during first draw,
but the right data during a redraw...
Why? Well simply because for OpenGL itself, the image had never
been drawn in teh first place! Only the Evas GL context knew
about the image drawing, as it was queued somewhere in the pipe.
One line solution: Call evas_gl_common_context_flush before
doing anything else.
in all other convert functions, dst_jump is provided in pixesl and
multiplied by the number of bytes-per-pixel either explicitly or
implicitly by using a different type for dst pointer (DATA16,
DATA32...).
As in 24 bits we use DATA8 we must explicitly multiply dst_jump by 3.
The first object that we generate with Eolian is Evas_Line, as it is a
simple one.
Two files are generated during build:
- the .eo.c contains the APIs definitions invoking Eo, the Eo functions
extracting the parameters and calling the hand written functions and
Eo structures to define the objects. These hand written functions are
located in e.g evas_object_line.c.
- the .eo.h contains the APIs and Eo prototyes.
We will continue with the other objects. If you note something wrong,
please update us asap:
daniel.zaoui@samsung.comyossi.kantor@samsung.com
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.
There are many situations (e.g all the time with Arabic text) in which
characters change their appearance depending on the context they lie
within. Before this patch, we didn't support changing font appearance
mid-context. So for example one couldn't do "a<color=#f00>b" without
messing up 'a' and 'b's change to their contextual forms.
Although Arabic is a very good example, this also applies to Latin text
in many cases, and should fix some wrong spacing that might have
appeared when changing styles.
@feature
EINA_LIST_FREE does eina_list_remove_list, and clip_unset does
the same thing to the same list pointer. So, EINA_LIST_FOREACH_SAFE
is proper for this case.
now that glyphs can exceed the bounds of the original query for the
font, there is no pointusing max ascent/descent bounds. back to plain
ascent and decent then so you may get fewer gaps in some fonts. this
fixes font gaps consiering trying to wrk otherwise now is pointless.
It seems that before 2.10, this was not stable, and was causing issues
to some people. I guess we'll have to bring the dependency back, at
least until we can find a better solution.
This reverts commit ec41f67be4.
This fixes T1006.
Youngbok Shin
WooHyun Jung
Yossi Kantor
Daniel Zaoui
Tom Hacohen
Jean-Philippe Andre
Gustavo Sverzut Barbieri
Jean-Philippe ANDRE
Snacker (Vladimir)
Jérémy Zurcher
Carsten Haitzler