[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Evas fb engine failure

On Sat, 14 Oct 2006 07:56:35 GMT "jose_ogp@juno.com" <jose_ogp@juno.com>

> 	Carsten writes:
> > On Fri, 6 Oct 2006 13:31:19 +0200 "Jorge Luis Zapata Muga"
> > <jorgeluis.zapata@gmail.com> babbled:
> > ...
> > ...
> > 
> > > btw a little offtopic, but now that the premul stuff is in,
> > > isnt a good time to continue thinking/start coding the next evas?
> > 
> > the next? or simply fixing at least anything in evas's api and
> > behavior so - if we in the FUTURE go and remove all the internals
> > and replace them, applications won't break? if we can make sure we
> > are so close to an "unbreakable api" (or at least will not break
> > with the changes we want to make) then we can quietly do such
> > changes in the background at any time.
> > 
> > i think our focus should be on laying the groundwork for any
> > such breaks now - break the api now - add the start of apis for
> > things like getting/setting image colorspace (yuv, rgb, etc.)
> > 
> 	Yes, developing the api and making any needed changes/breaks
> now would be good.
> 	But it's difficult to do without having worked out all the
> aspects that one might want (often, prior choices cause problems
> and/or conflicts with further extensions or semantics, so one would
> like to implement as much as possible before comitting to any 'final'
> form).
> 	Ok, let's start with images..
> 	You mention "getting/setting image colorspace". What exactly
> is it that this would mean? Do you want to allow for specifying the
> 'color-space type' of the data that you can 'set' on an image object?
> ie. the nature of the "void *data" pointer one now sets on image objs?

well here currently allimages are ARGB32. the void * pointer to its pixels
points to an array of 32bit ARGB pixels. if we have something to change
colorspace the format of these pixels will change. let me now take another
common example. we now want A8 format - that means the image is only an array
of 8bit alpha pixels. the color is the color of the evas object itself. the
data pointer simple points to an array of these. if you set the colorspace evas
will implicitly convert existing pixel data to the new format - maybe losing
information along the way if needed. anodhter format might be YUV - but insead
of linear its planar. that means your first N/2 bytes is Y pixels (row by row)
then the next N/4 is U then the next N/4 is V (where N is the total # of pixels
which is width * height of the image size). the pixel pointer simply points to
the beginning of this memory setup. we can add more colorspaces over time and
at the start simply only support 1 or 2. but having the concept where the image
may be in a format other than ARGB32 is important to introduce.

> 	What would you suggest as a complete api, say just for image
> objs, that you feel would do all/most of what you might want in the
> future?

well here i was only thinking 2 api calls - a colorspace set/get (and then the
understanding that colorspace may NOT be ARGB32).

> 	For gradients, I just sent you the last real api addition
> that I have in mind for these.. the ability to set a (file,key) on
> a grad obj, so one can load spectra from anything the image loaders
> can load (along the new gimp "ggr" loader I included).

this went in - right? (i think i put it in... right?) i am trying to catch up
now :)

>    jose.
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
Tokyo, Japan (東京 日本)