This reverts commit 72372.
I just don't get this commit, you just disabled the define that's
responsible of turning harfbuzz on. If you have a too old harfbuzz,
update, I don't plan on supporting old versions of an unreleased always
changing piece of sw.
SVN revision: 72393
for example , hb_shape_full function is supported only harfbuzz-20120607 version.
(harfbuzz 0.6 or 0.7 does not support this function)
but OT_SUPPORT define always turned on if harfbuzz installed.
SVN revision: 72372
For no bidi: just don't set the bidi stuff. I.e paragraph props and the
other stuff (including text_props_direction_set). If you disable BiDi you most
likely want to disable shaping as well.
For no shaping: Disable bidi (i.e don't set direction) and pass
EVAS_TEXT_PROPS_MODE_NONE to info create.
This will prove especially useful for textgrid, but not only.
SVN revision: 72032
NOTE: for people using Evas pipe rendering infrastructure. I am interested in reporting
expedite test before and after this patch with the associated type of CPU (number, thread,
cache). Thanks.
SVN revision: 71887
Also, put the slant angle calculations in a macro for easier future changes.
Just have it there so people who want it can turn it on.
SVN revision: 71506
Now evas will in all case do the layout during the prepare stage. It will do that
once and as long as the text didn't change. This does improve by a factor of at
least 2.3 in all expedite test case except the text change that only get a 30%
increase (I expect a drop in performance on non pipe rendering for text change
expedite test only, but this case is not common in real life).
This also fix the issue that show random size glyph when using pipe rendering.
SVN revision: 71220
glyph metrics.
Instead of having to render the glyph to get the width and horizontal
bearing of it, it's possible to get this information from the glyph
metrics (which are available on the glyph slot).
This change now allows Evas to only render the glyph at the rendering
phase, instead of having to render it during layout phase.
SVN revision: 71132
now seriously...
Introducing Cache Serve 2.
This cache server will initially load images for clients connected to
it. It starts slave processes to load these images, and share the loaded
images through shm with the clients. All the connection done between
clients and the server goes through sockets.
The cserve2 build option is turned on by default, while the old cserve
was disabled, but in order to make clients use it, the environment
variable EVAS_CSERVE2 must be set, and a server must be running.
Clients will try to find the socket on a specified location using the
environment variable EVAS_CSERVE2_SOCKET. If it's not defined, then the
XDG_RUNTIME_DIR path should be used, and finally HOME, TMPDIR and /tmp.
SVN revision: 70699
NOTE: This should be part of evas_render itself and not
delegated to the engine. So cleaning things to make it easier
during evas_render rewrite.
SVN revision: 70503
Note: this two were broken. Current plan to bring
that feature back in, is to attach this information
to Evas_Text_Prop during the prepare stage. This
would improve both single and multiple core rendering
without increasing the number of lock and the complexity
of the code.
SVN revision: 70501
NOTE: other things that may join it in the near futur EVAS_FRAME_QUEUE,
EVAS_METRIC_CACHE and maybe EVAS_WORD_CACHE also. This is all part of
cleaning up our rendering path so we can actually improve it more easily.
SVN revision: 70499
On macosx i386, that code fails because even though __VEC__ is defined,
the compiler doesn't understand the 'vector' keyword (that macro is
irrelevent here). So there was no way to make evas compile for ppc if
altivec was not supported by the compiler.
SVN revision: 66966
Carsten Haitzler
Tom Hacohen
Jiyoun Park
Cedric BAIL
ChunEon Park
Rafael Antognolli
Iván Briano
Vincent Torri
Gustavo Sverzut Barbieri
Sebastian Dransfeld
Youness Alaoui