they were first returning if (events_frozen > 0), then later only calling
the callbacks if (!events_frozen). if for some reason events had been thawed
an extra time, events_frozen would be negative, causing the callback to not
be called. the second check was redundant, so they were removed.
SVN revision: 8685
1. evas line draws of 2 pixelin size work now. oops!
2. font faces are shared between multiple sizes without a performance hit! yay!
SVN revision: 8660
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
malloc! not calloc
why?
large chunks of memory are used for image pixels
why set them all to 0 THEN set them to their pixel values? it's harmless
having them uninitialized. the idea is to avoid zeroing out potentially
megabytes of data.
SVN revision: 8440
allows me to be able to virtualize he canvas co-ordinate system. right now
it's doubles. i can now move to floats, int's etc. with a recompile (and well
recompile all depending apps too). it's still ACTUALLY doubles, just all
typedef'ed now. i've also changed booleans to actual boolean types (not an
int), all code will keep working - but i'd highly suggest moving your code to
use these types if interacting with evas.
SVN revision: 7644
with texture upload. it does NOt check error returns anywhere from gl... this
may mean issues with LOTs of images, LARGE images etc. need to fix that later
SVN revision: 7432
speed of texture uploads. anyone want to help? i've tried many things... and
nothing semms to work. this is a major bottlneck for evas gl engine
performance (apart from text - which is simply a matter of finishing off
properly)
SVN revision: 7428