before trying to free it, else we segfault.
Fix compiler warnings wrt const vs non-const of Evas_BiDi_Props.
Fix formatting and remove whitespace also.
NB: The major change here is in evas_font_word_prerender wrt freeing
the 'last' word of the cache.
SVN revision: 53166
it? and... lets not just throw pointer onto pipelines just for the
hell of it.. as like.. hmm the object owning the pointer might be
freed before pipelien finishes.. or hell. it might change pointer
contents? :) need to nwo dup bidi intl_props. probably a better plan..
tasn looking at you... is to fix up evas bidi utils and make the intl
props a new/free thing (and sharable eh?) with reference counts to
avoid dups (just ref up most of the time - and if u change, make a new
intl prop - dont change current one) etc. etc. for now dup - this
gives a perf hit tho. at least async rendering works now.
SVN revision: 51736
1. Fixed evas_common_encoding_utf8 functions to get char * instead of unsigned char * and return Eina_Unicode instead of int.
2. Removed a couple of unused variables.
3. Removed deprecated evas_common_font_utf8* functions.
SVN revision: 51200
Sorry, but full documented code will be committed tomorrow, this commit is needed for the API stabilization.
Major changes in this commit:
1. Changed the textblock node system there is now a linked list for the format nodes and a linked list for the text nodes. Format and text nodes point to one anoter in a matter that will be explained in the source file (will be committed tomorrow). Each text node now represents a paragraph and each format node points to a specific location in a text node.
2. Text/Format nodes are now two distinct data types.
3. The concept of nodes is no longer exposed in the API except for the format nodes which are only slightly exposed just to enable users of the API to cycle all the formats in order to find stuff like anchors.
4. Every node has a PS (paragraph separator) format node pointing to it's end, except for the last one which has nothing. Nodes are only broken by PS's.
5. Changed the BiDi functions to work nicely with offsets in big chunks of text.
More is explained in the email with the subject 'Evas Textblock redesign + edje_entry adjustments' that will be sent tomorrow because of technical issues.
For full documentation about this object wait for the next commit.
SVN revision: 50930
* Remove vim modelines:
find . -name '*.[chx]' -exec sed -i '/\/\*$/ {N;N;/ \* vim:ts/d}' \{\} \;
find . -name '*.[chx]' -exec sed -i '/\/[\*\/] *vim:/d' \{\} \;
* Remove leading blank lines:
find . -name '*.[cxh]' -exec sed -i '/./,$!d'
If you use vim, use this in your .vimrc:
set ts=8 sw=3 sts=8 expandtab cino=>5n-3f0^-2{2(0W1st0
SVN revision: 50816
Changing textblock and text objects to work with Eina_Unicode instead of utf8 (internally, API remains intact).
Started relying on new fribidi 0.19.2 instead of the old fribidi.
A lot of fixes to the font engine.
Renaming of evas_common_font_utf8_* to evas_common_encoding_utf8_*
This relies on new Eina changes and types: Eina_Unicode, Eina_UStrbuf and Eina_UStringshare.
SVN revision: 50595
The new wordcache option is an environment variable called:
EVAS_WORD_CACHE_MAX_WORDS
set this to a number between 1-500 to change the cache size.
Larger values (40+) fix regressions in a few of the expedite tests.
SVN revision: 50047
rendering. to turn on:
1.
configure with --enable-async-render
2.
export EVAS_RENDER_MODE=non-blocking
presto. necessitates some api swizzling (thus the expedite. ecore etc. changes)
the kind of results you get on a desktop:
http://www.rasterman.com/files/evas-async-vs-none.html
SVN revision: 49087
- they dont. in reality.
2. major text rendeering speedups. up to 41% in textblock intl, 33% in
textblock basic, 12-20$ in other text rendering tests. generic eina hash's
are just tooo slow for what we are doing there. specialised "Fash"
blocked-array.
3. still LOTS of optimisations left.
SVN revision: 45829
Hey raster,
Here is the non intrusive patch I talked to you about. Please apply it as it
introduces some fixes, some improvements and mostly and underlying
infrastructure for future RTL improvements.
(note hebrew & yiddish seem fine, but things expedite test seems to show are
wrong (why i don't know as i dont speak the langs- just comparing to pango /
gtk output):
arabic seems lsightl wrong (maybe composition chars not working?)
gujarati - also seems wrong
malayam - also looks wrong
persian - looks wrong
sinhala - looks wrong
tamil - looks wrong
these are what, appear to me, to look wrong. why they look wrong, i don't
know. i'm guessing its compositiong not being handled. but i dont's peak,
read or write any of these languages so i am unsure of what it really should
be like, why and how to fix it.
anyone want to put up a hand? (everything else is displaying fine as best i
can tell - the langauges i read/speak/somewhat understand are working fine).
SVN revision: 42814
2. make gl engine able to use cutouts - in some cases its faster, some
slower. it's a mixed bag. not sure what to make of it. it's #defined to be
disabled atm.
SVN revision: 39114
* evas/src/lib/engines/common/evas_font.h,
* evas/src/lib/engines/common/evas_font_draw.c,
* evas/src/lib/engines/common/evas_font_load.c,
* evas/src/lib/engines/common/evas_font_query.c: Add cache for font kerning.
This patch give something around 2% for all tests around text in expedite,
except for Textblock Intl where it give a 3 times boost.
Regarding text rendering speed, something is strange when used by evas_pipe.
All tests using Styles are around 40% faster without evas_pipe. 30% faster
for Text Change. But Text Basic 7% slower. So it should be possible to have
faster rendering when using evas_pipe for font rendering.
SVN revision: 38993
sometimes slower)
2. --enable-pthreads will enable multi-threaded rendering (current support is
for up to 4 threads so if you have a new fanled quad core or dual cpu dual
core box or whatever you will in theory be able to max moe of its cpu grunt
with the software rendering engine. this can only be done because i added the
pipelines which means almsot entirely lock-free multithreading internally in
evas. the only locks are for fonts but with a little work i might be able to
remove some/most of those too)
for now pthreaded rendering likely will be linux only (it relies on sched.h
for setting scheduler params to force the slave threads to run on separate
cpu's as linux likes to keep them on the same cpu otherwise and thus we get
no speedups at all - only slowdowns).
aso note that it is a bit of a mixed bag. complex ops (like smooth scaling
with alpha blending) get speedups, but simple ops (like blits/fills) slow down.
this all neds examination and tweaking still - but it's a start.
SVN revision: 27098
* When fonts are added from files we will only load the details
* The first font is always loaded
* I know there is a patch for this on the list but this way seems better to me
SVN revision: 21964
debugging/fixing and likely int he end the exact same result of fixing them.
yes - we lose performance - but it actually is correct now :) if we want to
do such radical changes- i sugegst moving to premultiplied alpha and makign a
tonne of externally tested routines in a test harness first to compare
correctness and speed in an isolated environment.
SVN revision: 18947
do NOT depend on order operation precedence. it broke scaling. laos other
completely bizarre mmx things were going wrong with mm7 ending up not 0 so
i've had to force it to be 0.
SVN revision: 18811
FONTSETS!
so u can do
Vera,Kochi,Blah ... etc.
as the font name
it will fall back font by font until it finds a char or finally fails.
this is for internationalisation support...
WHERD!
SVN revision: 13804
i've disabled font face (font source) instance sharing - it will load one per
size again due to performance reasons. i need to tackle this with the ft2
guys and see if theres an acceptible solution.
i COULD shadow all the glyph and font metric data i use myself per size -
thats fine... EXCEPT for kerning - thats the thing i can't sanely (figure
out how to) shadow myself... if someone figures that out for me! be my guest!
:) let me know!
SVN revision: 8634
api to set a font "source" (blank is normal filing system) but the source can
be a device or file etc. in this case it currently supports eet files as the
source and then the font name is used as a key in th eet file as to where to
find the font - edb support would be trivial to add. :) if the font is not
found in the "source" it falls back to the font path etc.
SVN revision: 8625
Tom Hacohen
Mike Blumenkrantz
Carsten Haitzler
Christopher Michael
Lucas De Marchi
Brett Nash
Cedric BAIL
Iván Briano
Vincent Torri
doursse
tilman
sebastid
Stafford Mitchell Horne
rbdpngn