optimizations for special cases (rectangles that onyl change size or
location have only their detlas redrawn - not the whole rect, and the same
with images who share common global tile start and size parapeters for the
image...) this is getting quite fast now :) rememeber you only really see
the speedups in software.. hardware is so dispicably fast you never notice :(
SVN revision: 4252
improvements - MUCH better
* fixed imlib and x11 engines - much faster x11 engine. much better imlib
engine
* added clipping ability to evas (you can clip one object by another for now
only rectangles are supported)
* you will need to use cvs imlib2 - i fixed the clipping in it to apply to
images, text and gradients too.
* almost done with x11 engine - just fonts to go (mostly done)
* clipping rects rgba color modifies what they clip
* gl, imlib and x11 engines modified to do clipping
* still need to add border scaling supporty to gl engine
* maybe some other stuff i don't remember - i've been sick over christmas
SVN revision: 4039
solid color - if you move or resize a rect and it doesnt change color, or
stakcing or visability - it only changes size and/or location, i do an XOR on
the update rectangles (this is a logical geometric XOR) and only update those
rectangles... why do this? see efm with the selection rectangle? it re-renders
the entire rectangle area - even only the edges change while you drag it around
so this special casing in evas would handle that and optimize.
SVN revision: 3690
whihc retcangles of the evas are completely obsucred by covering windows
so evas doesn't render things it doesn't need to (ie they can't be seen).
SVN revision: 3619
so you cant look into them. all defines now become enums too - cleaner. no
more bypassing the api is possible :)
also added better checks and --with- stuff for imlib2, gl and ttf
SVN revision: 3548
change the font or string to resize text, and chnage line coords.
add ability for color settings to apply to image objects too (image colors get
multiplid by color set on image - 255, 255, 255, 255 is "normal" so it's fast
path rendering - all other colors go thru color modifiers in the imlib engines
and gl handles it int he gl engine. if alpha is 0 the object draw is aborted
immediately for fast path.
SVN revision: 3468
it will render to a virtual image buffer just like it would to a window.
the logic works the exact same way as a window - it wil lonly render the rects
that changed. if a rect chnaged it expects that rect to have been cleared and
will blend the canvas ontop of the image - so you can use it to augment the
current image contents (though they will be permenantly modified). This is
specifically designed for doing things like rendering a canvas to be saved
to an image file.
WHEEEEEEEE :)
SVN revision: 3460
core bits of evas api actually do stuff now.. evas test it beginning to use them
if you want to have ann ide how easy it is to use evas as a rendeirng engine
just look at evas_test.. notice the evas setup is just a few calls (create,
set the output drawable, the output size of the window and the viewport into
the evas's virtual world - the its a mater of creating a few objects
and notice the main loo ONLy does 2 things - move the objects then call
render - evas will optimize to only render the bits that changed all for you.
there's a lot fo thank;less nasty state chekcing code just for this.
i'm going to have to write a lot fo it - image obejcts only done sofar.
you cant do anytign except move and resize them and add them and show and hide
them. freeing them wont work. layers dont work. no api to set performance cache
or to access it. fill modes for images dont work either nor is there an api
to set an images border scaling)
SVN revision: 3090
Carsten Haitzler
Mandrake