forked from enlightenment/efl
brett's patch for resize and doc typos :)
SVN revision: 11681
This commit is contained in:
parent
1d38d17bf4
commit
5845acceab
|
@ -1,7 +1,7 @@
|
|||
Carsten Haitzler <raster@rasterman.com>
|
||||
Till Adam <till@adam-lilienthal.de>
|
||||
Steve Ireland <sireland@pobox.com>
|
||||
Brett Nash <nash@nash.id.au>
|
||||
Brett Nash <nash@fluffyspider.com.au>
|
||||
Tilman Sauerbeck <tilman@code-monkey.de>
|
||||
Corey Donohoe <atmos@atmos.org>
|
||||
Yuri Hudobin <glassy_ape@users.sourceforge.net>
|
||||
|
|
|
@ -182,7 +182,7 @@ the most common converter you'll want for 16bpp. this means 5 bits for red,
|
|||
|
||||
--enable-convert-16-rgb-555
|
||||
|
||||
this is a converter for what many peoel knwo as "15 bit" color. you might
|
||||
this is a converter for what many people know as "15 bit" color. you might
|
||||
want to enable this for X output as it used to be common to find many cards
|
||||
that do this.
|
||||
|
||||
|
@ -194,18 +194,18 @@ this converter outputs to 12bit packed (int 16 bit WORDS).
|
|||
|
||||
this converter was written specifically for the ipaq (and may apply to
|
||||
similarly configured devices) because it lies about its screen depth. it
|
||||
days its 16bit 565 (that means 5 upper bits of the WORD are red, the next 6
|
||||
says it is 16bit 565 (that means 5 upper bits of the WORD are red, the next 6
|
||||
bits are for green abd the next 5 for blue) but in fact only the upper 4
|
||||
bits of each color component (red green and blue) are significant and work,
|
||||
so effectively the display is 12 bits of color, not 16, but padded out to
|
||||
fill 16bits, with unused bits in the color masks. X on the ipaq advertises
|
||||
it as a full 16bpp 565 display (i can't remember what the linxu framebuffer
|
||||
advertised it as) and so many lumsp fo code can be fooled into rendering
|
||||
data badly because they think the output will look as the expect. thsi
|
||||
it as a full 16bpp 565 display (i can't remember what the linux framebuffer
|
||||
advertised it as) and so many lumps of code can be fooled into rendering
|
||||
data badly because they think the output will look as the expect. This
|
||||
renderer assuems the upper 4 bits fo each color primitie only are
|
||||
significant and renders accordingly. this produces nice quality images on
|
||||
the ipaq and even still works in 16bpp 565 on your pc. it is highly
|
||||
recommended to use thsi renderer if your target is an ipaq or your device
|
||||
recommended to use this renderer if your target is an ipaq or your device
|
||||
dislpays similar qualities of the ipaq for display purposes.
|
||||
|
||||
--enable-convert-16-rgb-rot-0
|
||||
|
|
|
@ -1196,7 +1196,7 @@ evas_object_image_render(Evas_Object *obj, void *output, void *context, void *su
|
|||
{
|
||||
Evas_Object_Image *o;
|
||||
|
||||
/* render object to surface with context, and offxet by x,y */
|
||||
/* render object to surface with context, and offset by x,y */
|
||||
o = (Evas_Object_Image *)(obj->object_data);
|
||||
obj->layer->evas->engine.func->context_color_set(output,
|
||||
context,
|
||||
|
|
|
@ -544,6 +544,7 @@ evas_object_resize(Evas_Object *obj, Evas_Coord w, Evas_Coord h)
|
|||
obj->layer->evas->pointer.y);
|
||||
}
|
||||
}
|
||||
evas_object_inform_call_resize(obj);
|
||||
}
|
||||
|
||||
/**
|
||||
|
|
Loading…
Reference in New Issue