On Saturday 07 April 2007 11:21:22 Carsten Haitzler wrote:
> On Wed, 21 Mar 2007 16:58:15 +0100 Cedric BAIL <[EMAIL PROTECTED]>
> babbled:
> ok- started reviewing... and i'll basically cover as much as i had time to
> review here.
> 1. shared evas image cache - good idea, BUT... has problems. it's no
> different to what engines do, but in reverse. engines just wrap images up
> in their own objects and use the common code's stuff.l you only inverted
> the logic - it doesn't buy anything really. what your cache doesn't handle
> is if you have 2 or 3 or 4 different engines when 2 of them are NOT
> software engines and both want DIFFERENT "private" engine data (a pixmap,
> render picture, texture etc.). they share the RGBA_Image but they are not
> able to share the private engine data for the image - you need to keep both
> bits of private enigne data - that is what each engine's wrapping basically
> does. secondly for some engines there may need to be MULTIPLE private
> copies - different visuals, colormaps etc. for example. different screens
> etc. this here is actually a current bug in the RGBA_Font stuff - the way i
> did the engine specific glyph painting callbacks means only 1 engine can
> place private data there. i need to fix this - but it would be bad to let
> the same issue creep in for something bigger like images :)
> this is why there is a specific engine copy wrapping the image - the
> RGBA_Image just acts as a source of RGBA pixel data. the wrapping engine
> image colds a pointer to that plus engine specific data. the image is also
> looked up not just by filename + key, but ALSO by engine specific
> properties too.
When I did take a look at others engines, I missed such idea. So I didn't take
them into account for the cache. I will need to think how I could solve that,
but I would like to try to solve this on a real case. Do you have an engine
that need more than one private data ? (One that could be a good start to see,
understand and fix this problem)
> also you were changing evas_common_load_image_from_file() to use extension
> to choose module - several big problems.
> 1. it's case sensitive. file.JPG will not pick the right loader first off
Hum, that must be a bug, I used strcasecmp to handle this case.
> 2. also file.jpeg will also go the "slow route".
I don't see why. It must put "jpeg" in loader and then act exactly like the
previous code.
> 3. even worse for .edj files! it will never pick the fast-path.
Well, that sound really strange to me. As the "edj" extention is in the loaders
array, I don't understand why it will never pick the fast-path.
I mixed two changes in this patch. Splitting the function doing the
loading from the one taking care of the cache and replacing the list of "if"
with an easy to read array of string. I don't see what could have go wrong
here. I will take another look at this function.
Thanks for feedback,
Cedric
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
