On Tue, 10 Apr 2007 10:23:06 +0200 Cedric BAIL <[EMAIL PROTECTED]> babbled:
> 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. i swear i saw strcmp - maybe i didn't read carefully enough - but the other things still do apply. > > 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. sorry this was the other way around. .jpg files will always be loaded by the slow route. it uses the extension as the loader name. not a bad "guess" but it fails for several common formats - it then has to try EVERY module to see if it will work. the problem is multiple extensions can map to the same loader. if we drop case sensitivity: .tif, .tiff -> tiff .jpg, .jpeg, .jfif -> jpeg .eet, .edj, .eap -> eet .svg, .svgz -> svg point is that you need a better mapping. right now there is a code that literally takes an educated guess based on extension as to which loader might be the best to try first. then it goes the long way if this fails. the only way to remove this code is have a way for a loader to advertise what extensions it handles - then you need to load the loader module and look at an array of strings or a config file or something - but removing this code isn't that good an idea. > > 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. wait - i may have missed that. damnit. maybe i was on crack that day. grrr. ok - went back to patch - ignore the above. yes. you have an array. it makes sense. sorry - i misread it. this is fine. but the rest of the generic cache mechanism still is not really up to what i think is a "good idea". right now all it does it simply invert caching from within an engine object to outside of it. it doesn't allow to cache an engine object based on parameters like visual, colormap, display, scree, root window, and other device-dependant parameters. in that way it is really no more useful than the already "done transparently for you" cache in the common core. > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
