enlightenment/efl
enlightenment
/
efl
8
7
Fork 14
Code Issues 13 Pull Requests 1 Projects Releases Wiki Activity

brett's patch for resize and doc typos :) 

SVN revision: 11681
This commit is contained in:
Carsten Haitzler 2004-09-21 03:15:42 +00:00
parent 1d38d17bf4
commit 5845acceab
4 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
legacy/evas/AUTHORS
View File

@ -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>

12
legacy/evas/README
View File

@ -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

2
legacy/evas/src/lib/canvas/evas_object_image.c
View File

@ -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,

1
legacy/evas/src/lib/canvas/evas_object_main.c
View File

@ -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);
}
/**