On Thu, 10 Feb 2011 15:50:25 +0900 ChunEon Park <[email protected]> said:
i would agree. as it is meant to handle a "background" it can assume that it doesnt change size very often - so if a resize would mean that it should re-compute a pre-scaled image - using evas and load options would be just the right thing - even an on-disk cache - ethumb, can be used. but as such this is all something that should be done internally inside elm_bg - app doesn't need to know or care. it's an "internal optimization". it can ALSO crop the image - so for example. if the window is 480x800 - then a 1920x1080 image would be sized to 1422x800 so it filled the window height - but it would be much wider, so at this point elm_bg could ALSO crop it to be 480 wide to save memory. but yes - this could (And probably should be done internally and transparently to the app - that was/is the whole idea behind a specific widget like this. it can make assumptions where a regular image object can't. > Dear EFL developers. > > > > I have one question about elm_bg. > > > > Please listen and reply me your opinion if you are interested in. > > > > Currently, elm_bg loads the image data as original size and keeps it's > original buffer data. (even it is resized) > > > > I don't know the concept of elm_bg exactly this time, > > But if it is for the thing like desktop background, (It tends to keep the > size fixed or changed it's size rarely) > > then it seems that it needs to use the evas_object_image_load_size_set to > save the image buffer memory. > > In many cases, the background image can be big size even the output isn't > > > > Maybe it should be modified like els_icon and load image files again when > its size is changed. > > > > How about your idea? > > > > >From Hermet. > > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > 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] ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
