On Fri, 06 Jun 2008 15:08:44 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
> Cedric wrote: > > > I did some test around this and I think it came from the fact that > > o->dirty_pixels is not set to 1 after the second call to > > evas_object_image_size_set. A quick fix for your example is to call > > evas_object_image_pixels_dirty_set just after > > evas_object_image_size_set. I currently don't know enough to properly > > fix evas, but this could help others find the right solution. > > > > Well, the semantics of the image-size-set function has always > been that if there is no data or file for the image, it will create > data of the requested size, and if there is data (possibly from a > file), it will create new data of the requested size and copy as much > as possible of the current data to the new one and then set that new > one as the current data. actually that depends - eys. this is the case... *IF* the data is malloced/controlled by evas. if it's set from an external pointer - evas doesn't touch it.. it's up to the application that set the pixel data to reset it to the new data - if needed. > So, for the test program there, after the inital rendering > (of a blue area), when the resize is called the image would have > new data (not the provided pixels) one pixel less in width, so the > subsequent ecore induced rendering would still show the same result > (even though there's no further call to 'set data' as the callback > won't get triggered since 'dirty pixels' isn't called again, and > it's been unset after the first rendering). > > This would seem to show some new problem with the 'image-resize' > function when external data has been set before on the image.. and > indeed if I get rid of the pixels callback and simply set the data > (after the initial image size setting), then the problem is still > there even without the first call to evas render.. ie. the second > call to image-size-set seems to be the culprit. i need to make some more extensive tests for this in expedite - but expedite does that test code for setting data - but it it only makes uses of external data in yuv - and then the external data is only the yuv planes. the plane pointerlist that is internal to evas is managed by evas, so i don't actually test this case... which i should. > ____________________________________________________________ > Click here to choose from a huge selection of shipping supplies! > http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3n4Viav5LsS9677sjCU7lfWs22zXRdg638OZwylwP7y0XmIv/ > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
