The image data of dst could be null in a rare case.
@fix
Reviewed-by: Christopher Michael <devilhorns@comcast.net>
Differential Revision: https://phab.enlightenment.org/D12163
so if you use sw and gl enignes in a process and have color font
glyphs.. *BOOM* because the color glyph code used ext dat that was
intended for engines to extend with a gotcha of "only 1 engine can
extend this"... commented already.
so this unfortunately adds an extra ptr per glyph to store color data
explicitly. but now it both renders right and doesn't crash. we still
have a limit of 1 engine alone can extend glyphs with ext_dat though.
@fix
Public symbols were defined internal to Evas/Elementary on macOS, making
the link of external modules unfeasible.
- EAPI was messed up by an invalid inclusion of evas_text_utils.h, making
some symbols private instead of public.
- A similar issue was present in evas_font_draw.c, where the symbols
were directly imported without the proper definition of EAPI.
- Elementary.h did include some eo-generated headers, but for windows
only. It should not been restricted to windows, as it allows to export
symbols to external modules.
Fixes T6448.
Summary:
dev branch : devs/subhransu/font
The Final goal is to move the evas_font module to ector so that both ector and evas can reuse the code.
make the api simple so that sam eapi can be used by evas_textblock and ector text.
This is the 1st stage to achive that gola, first remove the evas internal dependancy as much as possible before moving to ector library.
Reviewers: jpeg, raster, herdsman, cedric, id213sin
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5419
Summary:
When evas selects a strike of embedded bitmap font,
calculate ratio and use it for scaling embedded bitmap.
@feature
Reviewers: jpeg, tasn, woohyun, raster, herdsman
Reviewed By: raster
Subscribers: charlesmilette, Francesco149, cedric
Differential Revision: https://phab.enlightenment.org/D2713
If GL context is free'd before processing font shutdown,
textures for emoji glyph's GL images will be free'd without clean
up its GL images. It causes eina mempool infinite loop issue when
emoji's GL images are free'd in shutdown process.
So, the patch will make a list for emoji's GL images in context and
clean up them when the context is free'd. Just like font textures in
context.
@fix
Differential Revision: https://phab.enlightenment.org/D4695
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Moved rects caching into draw context to avoid the use of __thread
slot. Draw context are defined per thread anyway and should be just
fine. This doesn't really change the picture regarding glibc problem
when to many __thread are needed, but slightly improve the global
picture. Also this patch doesn't affect our performance in expedite
benchmark as far as I can tell.
this works with 7166e6b859 and fixes a
leak added because ... free does not free!
evas_common_draw_context_cutouts_real_free(0 now actually frees the
rects, but evas_common_draw_context_cutouts_free() before did not.
@fix (follow on from 7166e6b859)
this fixes the fix 4d6a8a7fce to be
portable to platfomrs that do not support __thread - seemingly openbsd
does not (argh!) and maybe others. so on these platforms then they
dont get the optimization of keeping a cutout rect pool to avoid
re-allocation.
this also every 4096 draws "resets" the cutout cache so it doesnt
expand and stay expanded forever.
@fix
several draw funcs keep a static Cutout_Rect *rects = NULL; variable
to cache cutout rects to avoid re-allocating them a lot etc. this is
fast and handy but we may use these from multiple threads. thats bad
.... mmmkay. so this fixes it the dirty way - makes them thread local.
:)
this fixes T3348 - the crash mentioned by @zmike
@fix
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.
this changes the internal encoding of font glyphs in evas to use 4bit
uncompressed if small, or 4bit rle (run length encoded) if larger.
this caves at least 50% of memory on fonts - and more if bigger. with
large fonts (40-80pixel size) we can save in the region of 80% of
memory used for glyphs. this also happesn to allow speedups in
rendering too.
Try to reconnect to cserve2 if the socket connection was lost.
Resend some messages if necessary.
Images reload seems to be working.
Actually, the images don't change over time, so the clients just
keep the previous references to their images.
FONT RELOAD IS NOT WORKING:
- Crashes
- Invalid glyph data
- Infinite loop in _glyph_map_remap_check()
Root cause:
When new glyphs are requested from the server, they are added to
the mempool. So it is necessary to remap the font.
Unfortunately, in case of server reboot, we did not keep the mempool
so the old glyphs that were not requested again will not be valid.
evas_common_font_int_cache_glyph_get), then we should free that
allocation when we have an error.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Evas_Common.h should be used for the public header, and rather rename
evas_common.h internal header to another name.
Sa:
Evas_Common_Header.h -> Evas_Common.h
evas_common.h -> evas_common_private.h
Shouldn't have both Evas_Common.h and evas_common.h because of case
insensitive filesystems.
This new engine function will only be used in software generic for
now - since it's the only engine used with the async render.
This function has been introduced in order to avoid growing thread
command queue too much to draw a text_props at a time on render calls
from textgrid objects.
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 82832
This patch should make us get a reference on images, maps and glyphs
which are sent in a command to the render thread. Before we were doing
some useless ref and unref operations.
SVN revision: 82666
This is intended to preserve old behavior now that we have
evas_common_font_draw_cb() to handle both sync and async callbacks.
However, we need to check where why we end up with no glyphs in a
text_props even after calling evas_common_font_draw_prepare().
SVN revision: 82664
This sould bring back a little bit of text rendering performance, while at
the same time decreasing memory usage and fragmentation.
Patch by: Leandro Pereira <leandro@profusion.mobi>
SVN revision: 82660
This is in preparation for threaded render landing: the render thread will
hold a reference to a text object's glyphs while it hasn't been rendered
yet (and will drop that reference after drawing). This changes the internal
API a little bit (evas_common_font_rgba_draw() now takes an Evas_Glyph_Array
instead of an Evas_Text_Props).
SVN revision: 81183
This patch refactors common code for font draws - so that it can be used
by other engines and *threaded* X11.
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 79853
I've tested make -j 3 install and it works nicely
I've tested expedite with software and opengl xlib,
and it works. Not tested other engines, so please
report any problems (engines or other) on the ML.
TODO: examples and tests, I'll add them later
ISSUE: Eina_Unicode size check. It indirectly depends on
eina_config.h, which is created at the end of the
configure script. So its size is always 0. I don't
know how that size is used, so I can't do a lot,
for now.
SVN revision: 78895
Youngbok Shin
Ali Alzyod
Hermet Park
Carsten Haitzler
Chris Michael
Jean Guyomarc'h
subhransu mohanty
Cedric BAIL
Jean-Philippe Andre
Sebastian Dransfeld
Cedric BAIL
Paulo Alcantara
Ulisses Furquim
Leandro Pereira
Vincent Torri