[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Premultiply or not
> > Let's agree on one thing: The gfx operations, unless
> > otherwise explicitly stated, will be done in premul argb color
> > space, or a linear equivalent of it..
> agreed - with possible FUTURE ability to use more esoteric
> colorspaces like YUV (though frankly yuv is handled most sanley
> by a convert to yuv first - BUT you can actually get speedups
> combining the scale and convert at the same time)
Ok good, at least we're getting somewhere :)
> > Ok, fine.. and actually premul ayuv would be ok too since
> > when decoded yuv is linearly related to rgb (hsv eg. is not).
> > There's already such an interface to set imported data from yuv,
> > and moving the 'conversion' to rgb down to the engines is fine
> > as they may simply be able to deal with it directly, etc..
> > That's all good, and an interface for importing yuv to image data
> > is already there, you can extend it to cover any premul ayuv format
> > type with no problem.
> sure - and i would suggest we expand it to also import non-premul
> ARGB - thats basically all i was really suggesting. :)
That would be the best way to do it, yeah :)
> > Let's assume that edje has been modified to pass premul
> > colors/data to evas, and eet saves premul data, and that evas
> > provides premul/non-premul conversion api functions for colors
> > data..
> > Just where exactly in e17 would there be even minor pain
> > caused by evas being premul only?
> every edje design (.edc's) that specifies a color for text or
> solids, clips etc. any app that sets an object color itself.
> there are 74 calls to evas_object_color_set in e17. e17's creation
> of netwm icons would need to do a premul step. 54 in edje. more in
> ewl, etk etc. etc. now with edje - do we force the .edc's to
> specify colors in premul? if so there are (evil) 666 instances of
> colors in e17's default theme - or do we have edje_cc convert to
> premul on encode - or do we have edje turn into premul runtime?...
> how far do you go? :)
Ok I looked at the e17 ones. Nearly all of them are of two
kinds: either setting a color that's already premul (usually opaque
white or transp black), or for defining some smart-class' color-set
Neither case needs anything done (color-set smart callbacks
would expect premul inputs). That leaves about 6 left I think.
Anyway... I think it might be best to let the edc format
stay as it is (non-premul colors), and have edje do the conversion,
not edje_cc. If desired, a later edje can have other types and/or
versions of 'design-formats', like edc, and one can do whatever..
There are possibilities for things that are very interesting with
premul colors, and having evas handle premul colors, as given, would
allow for that.