set as the basename of the file (ie "/tmp/blah/foo.png has the name of
"foo"). you can override the name if u want... or just not use it. should
really use hash table - patch for this from rusty russel :) i need to wokr
on this stuff before 1.0
SVN revision: 5652
object inthe evas are in layers above the new one.. fix fix oops.. that was
a silly bug... :)
and well.. while i was at it.. some actual code in the render extension
support in the render engine in evas.. it onyl does image objects right
now.. and it doesnt do it very optimally.. consider that engine a work in
progres.. i'm finding what does and doesnt work well in the render extension
and noticing some holes in it... this one wont be ready any time soon
though... and the gl engine is still about 10 times faster on the same
hardware... and in theory both are hardware accelerated...
anyway only time will tell. the render extension doesnt do image
transforms.. so this wont help speed it up at all that much :(
SVN revision: 5267
kept resident as long as the obejct has been rendered at leats once AND it
is still within the viewport of the output of the evas and it is still
visible. if it does not meet these conditiosn it gets put into "Cache" and
only then does cache become an issue. the chancges were nice and small to do
this :)
SVN revision: 4634
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