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

Re: [E-devel] Evas fb engine failure

	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'

	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?

	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

	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).