Viktor Kojouharov wrote:

> On Tue, 2009-04-28 at 09:11 -0300, Gustavo Sverzut Barbieri wrote:
>   
>> On Tue, Apr 28, 2009 at 5:30 AM, Enlightenment SVN
>> <no-re...@enlightenment.org> wrote:
>>     
>>> Log:
>>>  fix the xpixmap window resizing
>>>            evas_object_color_set (o, 255, 255, 255, 50);
>>>       
>> hummmmmmmmmm.. even this line not being changed in the commit, i just
>> spotted it and it is wrong!
>>
>> in Evas you need colors pre-multiplied, so every R, G and B should be
>> <= A, so it is impossible to have 255 red with 50 alpha. In this case,
>> use 50 50 50 50. You can google a bit more for pre-multiplied color
>> system.
>>
>>     
> thanks. I was wondering why the rect was not transparent. I really need
> to understand what values make for correct colors. e.g.: I have no idea
> why the rgb have to be 50 with a 50 alpha value. Can I for instance have
> 99 132 172 (light blue) with a 200 alpha?
>
>   

   When you "set" the color of an evas gfx primitive (like an image,
rect, grad, text, poly,...) what it does is to effectivley "multiply"
whatever intrinsic color data the primitive may have with the input
color and composite that to the dst.
   Some time ago, evas changed its internal compositing code to work
with "premul" color data ("premul" means a >= r,g,b). This was done
mostly for performance, but also consistency, accuracy, continuity,
and other reasons. It affects quite a few things indirectly, eg.
scaling/transforming of images.

   In turn, the evas api semantics assumes that both the general object
'color-set' function, and the image object 'data-set' one, are passed
premul color data.
   There are utility functions there in the evas api to convert from
non-premul colors or data to premul versions. But if you want a simple
way to start with *non-premul* r,g,b,a color data and pass a premul
"equivalent" to the evas_object_color_set function, just do:

evas_object_color_set(obj, (a*r)/255, (a*g)/255, (a*b)/255, a);
or
evas_object_color_set(obj, ((a*r) + 255) / 256, ((a*g) + 255) / 256,
                           ((a*b) + 255) / 256, a);
or
float f = a / 255.0;
evas_object_color_set(obj, f*r, f*g, f*b, a);
or similar.

   The decision to go with this semantics, for both color and image data,
was not an easy one. But since I was the one who did the conversion
work at the time, and since I felt it would be less destructive, more
flexible, and simpler to have evas adopt this semantics and let others
built on top of it (like edje) decide what semantics they want to adopt
for their api, that's the way it went.



>> Raster: why don't we have check + warning in that function? being at
>> the api i see no problem with it slowing things down, but maybe it
>> does? We can add the check after it checked for same color as before,
>> so we just do it when it changes (ie: edje keeps calling evas with the
>> same values, so it will not impact edje).
>>
>>     

____________________________________________________________
Click here to become a professional counselor in less time than you think.
http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTOk5yEY2xkWpzhLyc4BvD6yzTxcN70Bd63TTRHcIVrzgoOkWRItiA/

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to