Re: [E-devel] Epsilon problems
On Sat, 19 Jan 2008 06:40:27 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Man, we all say some silly things in time, but this has to be one of the good ones from you. :) It's a 'load option' so it's fine for this to be 'optionally' implemented in a loader? Wow! correct. load options include things like DPI settings. do you expect every loader to now scale images based on DPI - the loader doesnt even know what the DPI of most image formats is - will it fake one (eg 75dpi) just to make this work ? these options are Yes, because that's exactly what we did (for the one and only loader that respects that, the svg one), except I believe it was 90 dpi not 75 that we used. correct - though this was more a bi-product of svg being a vector, not pixel-based format. that's about the only reason dpi exists there in load options. I can understand some 'option' so particular to a format that it had absolutely no relevance to other formats.. eg. a format might support various kinds of de-compressions, speed vs quality kinds of things or whatnot.. but that's just not what's being adressed here. We're talking about, essentially, about image sizes - likely the most common attribute you can think of for images. there if the loader can do something easily/for free while loading. for some formats like SVG rendering at a DPI is part of loading - or at a size, so it comes for free. for jpeg scaling down by 2, 4 or 8 in each dimension is for free. if every loader implements this i also need to add controls over the scalign quality (smooth or samples for example). None of this has any real bearing on the issue at hand - ie. wether evas itself should do the re-sizing on load, or let everyone who needs it have to copypaste your e17 solution. But it's your call so we'll leave at that. :) what you want is an: evas_object_image_rescale(Evas_Object *obj, int w, int h); which forcibly rescales ANY image to a particular size - be it loaded from a file or generated as ARGB data. this gives you the choice after load - if the load options didn't get you a size you are happy with for free to do extra work to fix it. with enignes like the opengl engine scaling is free so you might not want to pay the price of a software-scale on load when a please pre-scale this to this size - if you can do it for no extra cost is by far better - for jpeg in this case u can load a large jpeg image at a reduced size much faster and then scale with GL afterwards for free. putting that into the load and load options takes that choice away. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
Is there any internal call to do these scaled blits or just those of evas_common? If so, those more used to it: there is any way to use these evas_common functions to do this convertion? Only the 'common' functions for scaling are really needed. Just do an imitation of what the e17 thumbnailing code does, for those loaders that don't currently support scaling fully to the load-option's requested wxh size (I'm assuming that's all you really want to fully implement). Use a temp image whose data is the loaded file's data (loaded according to what's currently approximated there to the size load options), and scale that to the real image you're working with (then get rid of your temp image and/or its data). There are a few details here and there you'd want to make sure are covered, but it's all fairly straightforward if you look things over a bit. Or wait a few days and I can send you a version when I get a chance. But you'd still have to navigate the more complex, murkier waters of getting such heresy into cvs. :) _ Stuck in a dead end job?? Click to start living your dreams by earning an online degree. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nNfaT3FnM82IViYSct5wnA1xKHJkhmlXElIkaWNbEOsTxpe/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
On Tue, 15 Jan 2008 09:36:13 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: see my other mail. load-size is an option. a loader implements it ONLY if it can do a scale-down on load for free. it is a hint, not a requirement. you need to load, then check image size and see if you need to adjust/scale later yourself. so only the svg loader will scale to the size u want - as it can. the others wont' do anything. the jpeg loader will chose the nearest scale size it can manage (which is 1/2, 1/4 or 1/8th the width/height of the original jpeg file - that's all it can do. this it gets for free tho on load. in fact load is faster the more u scale down). Man, we all say some silly things in time, but this has to be one of the good ones from you. :) It's a 'load option' so it's fine for this to be 'optionally' implemented in a loader? Wow! correct. load options include things like DPI settings. do you expect every loader to now scale images based on DPI - the loader doesnt even know what the DPI of most image formats is - will it fake one (eg 75dpi) just to make this work ? these options are there if the loader can do something easily/for free while loading. for some formats like SVG rendering at a DPI is part of loading - or at a size, so it comes for free. for jpeg scaling down by 2, 4 or 8 in each dimension is for free. if every loader implements this i also need to add controls over the scalign quality (smooth or samples for example). Tell me, given that this is really trivial to add in evas, and you end up going thru inefficient loopshoops to get the 'option' to actually work in a 'non-optional' way, then why not just have this actually work? i'd be a lot of changes to a lot of loaders and it would not be universal as above - dpi is entirely optional as most formats don't have a dpi of the image. so some things would/could work, some could not. i chose to go the whole only do it if you can do it directly with the format option. I think evas needs to add an image saving 'size' option, maybe best done via the current flags for saving, so that you can save an image that alreday exists at some size (for whatever reason), to a file at whatever other size one wants. not sure we should do that - as above - its possible to do this with buffer canvases and objects. it's much more flexible as i can ALSO put MULTIPLE objects into the thumb then. i can add watermarks and more to them. Sure, you can do all sorts of things.. but it doesn't mean that it's always the best way to get something simple done. Other than new work required to add something like this via the api, why do you feel that maybe it shouldn't be done? because it now makes savers more complex, adds in a single feature for what is a single use case and is not more generally useful. the buffer canvases do all of it - there is no need to add a saver scale option imho. it just puts more work into every saver (and loader) that is already generic and shared with a common single api (evas itself). ** I doubt it worth the pain, because if we go FDO we must remove any attempt to use .edj as thumbnail format, and it's a good alternative if you want to provide movie thumbnail. Going too generic may hurt more than help if nobody else use it, and believe me these guys are hard to get using done by others, you know the NIH syndrome... agreed it will be painful. i don't think we should force edje into a thumbnail format - BUT eet is possibly useful there as its agnostic when it comes to glib, qt, efl etc.. the gtnome/kde crowd as best i know do not have any such container format handler to pack many data items compactly into a single file with an easy api to access it again. so we are not competing. I can't see why what FDO wants or doesn't want to support as 'acceptable' formats should stop anyone from doing otherwise. In fact, I can't understand why any reasonable, OPEN format would not be acceptable, nor the reason for *requiring* that some particular format *must* be accepted.. and none others?? None of this sounds to me like a body whose decisions should be respected - if indeed that's the way it operates.. it doesn't sound to me like the spirit of foss to do so. a lot of foss is not what u think it would be. there is a lot of political infighting, ego stroking and other things that are not related to being open and free - often open and free decisions make way way for personal ambitions. if we present a format that does not have a native g-whatever or k/qt-whatever implementation it basically will be shunned. if we have a format that is not dependent on our own libs (eg edje depends on evas, ecore and edje so it would suck them into kde/gnome) and is stand-alone it has a better chance as it can be seen as less of an invasion from the nih lands. but in the end - standards bodies - FOSS ones included, are
Re: [E-devel] Epsilon problems
Man, we all say some silly things in time, but this has to be one of the good ones from you. :) It's a 'load option' so it's fine for this to be 'optionally' implemented in a loader? Wow! correct. load options include things like DPI settings. do you expect every loader to now scale images based on DPI - the loader doesnt even know what the DPI of most image formats is - will it fake one (eg 75dpi) just to make this work ? these options are Yes, because that's exactly what we did (for the one and only loader that respects that, the svg one), except I believe it was 90 dpi not 75 that we used. I can understand some 'option' so particular to a format that it had absolutely no relevance to other formats.. eg. a format might support various kinds of de-compressions, speed vs quality kinds of things or whatnot.. but that's just not what's being adressed here. We're talking about, essentially, about image sizes - likely the most common attribute you can think of for images. there if the loader can do something easily/for free while loading. for some formats like SVG rendering at a DPI is part of loading - or at a size, so it comes for free. for jpeg scaling down by 2, 4 or 8 in each dimension is for free. if every loader implements this i also need to add controls over the scalign quality (smooth or samples for example). None of this has any real bearing on the issue at hand - ie. wether evas itself should do the re-sizing on load, or let everyone who needs it have to copypaste your e17 solution. But it's your call so we'll leave at that. :) _ Live your dreams. Click here to find information on becoming a lawyer. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oFGmcsTG5zvq2NKKrizxPBJOtoZSV14O43SGaQcKaICuQqc/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
Carsten wrote: Unless... Oh, oh.. unless we didn't finish off implementing the load-size option for all loaders. I know we did it for the svg loader, and that the jpg loader respects loading scaled-down- by-dyads, but I can't recall if we really did finish off making sure that all loaders respected the load-size option.. need to take a look. If not, then it should be filed as an evas BUG. see my other mail. load-size is an option. a loader implements it ONLY if it can do a scale-down on load for free. it is a hint, not a requirement. you need to load, then check image size and see if you need to adjust/scale later yourself. so only the svg loader will scale to the size u want - as it can. the others wont' do anything. the jpeg loader will chose the nearest scale size it can manage (which is 1/2, 1/4 or 1/8th the width/height of the original jpeg file - that's all it can do. this it gets for free tho on load. in fact load is faster the more u scale down). Man, we all say some silly things in time, but this has to be one of the good ones from you. :) It's a 'load option' so it's fine for this to be 'optionally' implemented in a loader? Wow! Tell me, given that this is really trivial to add in evas, and you end up going thru inefficient loopshoops to get the 'option' to actually work in a 'non-optional' way, then why not just have this actually work? I think evas needs to add an image saving 'size' option, maybe best done via the current flags for saving, so that you can save an image that alreday exists at some size (for whatever reason), to a file at whatever other size one wants. not sure we should do that - as above - its possible to do this with buffer canvases and objects. it's much more flexible as i can ALSO put MULTIPLE objects into the thumb then. i can add watermarks and more to them. Sure, you can do all sorts of things.. but it doesn't mean that it's always the best way to get something simple done. Other than new work required to add something like this via the api, why do you feel that maybe it shouldn't be done? ** I doubt it worth the pain, because if we go FDO we must remove any attempt to use .edj as thumbnail format, and it's a good alternative if you want to provide movie thumbnail. Going too generic may hurt more than help if nobody else use it, and believe me these guys are hard to get using done by others, you know the NIH syndrome... agreed it will be painful. i don't think we should force edje into a thumbnail format - BUT eet is possibly useful there as its agnostic when it comes to glib, qt, efl etc.. the gtnome/kde crowd as best i know do not have any such container format handler to pack many data items compactly into a single file with an easy api to access it again. so we are not competing. I can't see why what FDO wants or doesn't want to support as 'acceptable' formats should stop anyone from doing otherwise. In fact, I can't understand why any reasonable, OPEN format would not be acceptable, nor the reason for *requiring* that some particular format *must* be accepted.. and none others?? None of this sounds to me like a body whose decisions should be respected - if indeed that's the way it operates.. it doesn't sound to me like the spirit of foss to do so. jose. _ Find the military school that meets your standards. Click now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l91uO8BwI8E6hEJHRkt2eScxmPs1zdarLaGSbnXUKoFNHdu/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
On Mon, 3 Dec 2007 06:07:22 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Gustavo wrote: - how expensive is evas/ecore_evas_buffer in comparison to imlib2 to generate thumbs; You don't need ecore_evas_buffer to generate 'thumbs' of jpg/png/svg, that's only for generating smaller views of a 'general' evas canvas rendering. For example, if you want to show a live thumb of an animated edje, or bunch of edjes, or just about anything. that's why I asked, without any testing I'd say it will be slower/ overkill... Depends. If you're already using evas, and want to load and save image files to smaller sized (thumbs) versions, then using evas rather than going thru imlib2 could be faster - certainly for jpegs. Maybe for pngs, *if* you're saving to eet. Evas premuls all loaded non-premul argb data, and when saving back to png it un-premuls back, so we have: png-file-in - premul - scale-down - un-premul - png-file-out. Which is slower than what imlib2 would do. But, if you save the png to an eet, then as raster wanted to go with the premul flow, he made it so the no un-premul takes place when saving pngs to eet.. and likewise, no premul takes place when loading pngs encoded in eet (like eg, in edj files). What would be slower is if you went thru intermediate buffer evases to do down-scaling, ie. one would then have: load-thing-at-its-natural-size-to-buffer-evas1 - resize-evas1-to- thing-size - draw-it-to-evas1 - set-pixels-of-buffer-evas1-as-data -of-image-obj-of-buffer-evas2 - resize-evas2-to-whatever - set-fill -and-size-of-image-obj-to-size-of-evas2 - draw-image-obj - [write- pixels-of-evas2-to-out-file-somehow] this last step either directly or again via setting the resulting pixels of buffer evas2 to another image obj that you'd have created when you 'resized' evas2, and then saving the image obj It's somewhat convoluted. I looked at e_thumb_main - it saves to eet files directly. That's not really sufficient for giving flexible thumbnail-file saving functionality for others to use - it's just too restrictive (and not really as fast as it could be in some cases). actually it uses a buffer canvas polus a sub-buffer canvas as per my other mail ee and ee_im in the code in _e_thum_generate() :) BUT it doesnt need to double-render. it only renders as much as neededc - the parent buffer canvas itself never is rendered to - it is just a container for the im object: im = ecore_evas_object_image_new(ee); ee_im = evas_object_data_get(im, Ecore_Evas); that creates the image object which *IS* a buffer canvas - gets the buffer canvas evas handle and adds anythign into that it wants to scale. I think evas needs to add an image saving 'size' option, maybe best done via the current flags for saving, so that you can save an image that alreday exists at some size (for whatever reason), to a file at whatever other size one wants. not sure we should do that - as above - its possible to do this with buffer canvases and objects. it's much more flexible as i can ALSO put MULTIPLE objects into the thumb then. i can add watermarks and more to them. seems that JPEG loader does respect load_size, PNG doesn't, not sure about others. Bummer. But it's very easy to finish this off, for anyone who wants to give it a shot.. :) jpeg does - BUT it will scale to one of the scale-down sizes. 1/2, 1/4 or 1/8th dimensions in each axis. e_thumb makes direct use of that. I'm newbie to this project, so maybe you can help me understand this: is epeg just a test and the functionality was integrated to Evas's JPEG loader? This would be amazing. That was raster's great desire - to have the evas jpeg loader do what epeg did, and so did he add that in. :) i did :) epeg ALSO did all the fine-tuning scaling (ie it would scale to the nearest 1/1, 1/2, 1/4 or 1/8th jpeg size for free on load and THEN scale to the exact size. evas doesnt do the last fine-tune scale. it leaves this to runtime (not load time) as evas can do this already as part of its rendering pipeline. you then can choose if you want smooth scale or not and anything else u like scaling-wise. As to your being a newbie to the project.. I think you've been a tremendous inspiration to everyone here Gustavo, you and your friends and collegues there at Canola. Really. i echo that - your work on canola2 has been amazing. i played with it and its reaaly nice. it's an amazing bit of work - and really shows what u can do with efl when you play with it right. jose. _ Study law at a school near you. Click for more info. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oFGmXCSm0cvWIFZ0N1bFZGJDUQ6vQVhZYPYDKK05IzLH0Ji/ - SF.Net email is sponsored by: The Future
Re: [E-devel] Epsilon problems
On Sun, 2 Dec 2007 11:02:09 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: - how expensive is evas/ecore_evas_buffer in comparison to imlib2 to generate thumbs; You don't need ecore_evas_buffer to generate 'thumbs' of jpg/png/svg, that's only for generating smaller views of a 'general' evas canvas rendering. For example, if you want to show a live thumb of an animated edje, or bunch of edjes, or just about anything. Unless... Oh, oh.. unless we didn't finish off implementing the load-size option for all loaders. I know we did it for the svg loader, and that the jpg loader respects loading scaled-down-by-dyads, but I can't recall if we really did finish off making sure that all loaders respected the load-size option.. need to take a look. If not, then it should be filed as an evas BUG. see my other mail. load-size is an option. a loader implements it ONLY if it can do a scale-down on load for free. it is a hint, not a requirement. you need to load, then check image size and see if you need to adjust/scale later yourself. so only the svg loader will scale to the size u want - as it can. the others wont' do anything. the jpeg loader will chose the nearest scale size it can manage (which is 1/2, 1/4 or 1/8th the width/height of the original jpeg file - that's all it can do. this it gets for free tho on load. in fact load is faster the more u scale down). _ Surf a world without wires. Click now for great wireless Internet solutions! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mFpiycmcZ4UgiHjwK5y5QltR0iyZyopTyddMt9vTAwuygac/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ 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] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
On Sun, 2 Dec 2007 09:16:30 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: As raster mentioned, and as I believe, the best thing for epsilon would be a rewrite using evas instead of imlib2... something extremely similar to e_thumb. Raster said that if this did occur, e would likely change to using epsilon as well. If epsilon is still using imlib2 for creating thumbs, it must be either because at the time it first appeared evas could not then save images to files, or maybe because it wanted to use more image correct. evas was unable to save images at the time. it can now. has been able to for a while. loaders/savers than evas had (evas had built-in jpg/png/eet only at first, or rather at second - at first it also used imlib2 for loading, and the original-original evas used imlib2 for drawing too). yup. evas still has fewer loaders, but i like it this way for now as it lets us more easily changing things. we can expand this over time as needed, but it does cover a lot of the most common formats. If so, these two issues should no longer be relevant: evas correct :) can save to files, and one can write as many loaders/savers as desired. In fact, I think that imlib2 doesn't have an svg loader, which evas does. Any special-purpose loaders that one may want for epsilon, but not in current evas, one could write expressly for epsilon if desired. or for evas - and add more loaders in. steal them from imlib2. port them over. not hard really. same pixel format (argb32). On the other hand, uing evas for simply loading and saving 'thumbnails' of a couple of images is somewhat of an overkill.. but not if you're doing many. true - but since epsilon already uses it - it's a moot point really. imlib2 is less and less useful - evas has taken over most of what imlib2 could do (and a lot more besides). for generating thumbnails evas has all u need. - how expensive is evas/ecore_evas_buffer in comparison to imlib2 to generate thumbs; You don't need ecore_evas_buffer to generate 'thumbs' of jpg/png/svg, that's only for generating smaller views of a 'general' evas canvas rendering. For example, if you want to show a live thumb of an animated edje, or bunch of edjes, or just about anything. well you will want a buffer - for the scaling. u load image int an evas image object in a buffer canvas. this buffer canvas lives in the image object of another buffer canvas (parent). you simply create, show (move, resize, set properties) on the image object u loaded, force an evas_render() on the buffer evas that holds this image object. this means the parent image object in the parent buffer canvas will now have pixels that are valid and rescaled down. now just save this image object in the parent buffer (u don't need to render the parent buffer canvas which means its just a wrapping data structure to give you and image object to be able to call save() on). it shouldn't be any significant overhead (almost none when compared to the expense of loading the image file from disk, decoding, scaling it and then saving it). - saving to eet the uncompressed data really help? Ok, this is more about testing on our hardware, but maybe it will not help and it's cheaper to uncompress a JPEG than read pixels from flash (flash slowness versus cpu usage). In that case, what's the best option to save the image as JPEG? Create an evas_object_image on the same canvas, set it's pixesl to buffer pixels and then evas_object_image_save() it? yup. compression in the end is a disk (or flash) IO tradeoff vs CPU. in the end you will find its faster to compress it as the extra Disk space used is huge when you don't compress, and you pay a big price in IO overhead if not compressed. jpeg tends to decompress VERY fast even compression is fast - much faster than png (going via libpng or libjpeg). Saving what to eet? Thumbs of jpgs/pngs? Depends what you want to do with them, and how many... The best option to save the image as JPEG is somewhat hard to say - it depends on the context you're working with. yup. eet does one thing u cant do with jpeg/png - it allows BOTH lossy compression (jpeg style) AND an alpha channel - so if you are thumbnailing something big - with an alpha channel, eet is the way to go for speed of saving the thumb, loading and disk usage for the thumb. But if you're using evas, and you want to use it to load and save 'thumbs' of jpgs back as jpgs, then just create an image object (hide it), set the load size (evas uses the same 'quick' thumbing mechanism for jpgs as epeg), set the file, and then save it to the thumb file (use flags for jpg quality and compression), repeating for as many image files as you want. Or if you want to do this in a separate evas, then create a buffer evas and then do as above. yup. in e17 e_thumb* does just that. use it/steal from it etc. this stuff should probably be rolled into epsilon replacing the
Re: [E-devel] Epsilon problems
On Mon, 3 Dec 2007 10:41:03 -0600 Nathan Ingersoll [EMAIL PROTECTED] babbled: This is a little off-topic for the thread, but there are some long term changes I would like to see for epsilon eventually. 1. Split thumbnail generation into pluggable processes. If we can specify external commands for generating thumbnails, we reduce the amount of code necessary to support new formats. This also gives us robustness when a dependency mis-behaves and crashes the thumbnailing process. agreed. a nice way to do really quick and dirty thumbnailers via external processes either executed once per file to load, scale save and forget or to load and then save a whole series of files (and provide some form of progress/feedback as it does it - eg via stdout or something). agree on all points here. 2. Switch to dbus for client to server IPC. Many of the issues currently with the epsilon daemon stem from some initial problems with ecore_ipc, and the hacky conversion to ecore_con. Dbus is also targeted at remote method invocation, which is essentially the goal of the epsilon daemon communications. nothing against this. 3. Develop a dbus standard communication protocol with FDO. Ideally, we could get a protocol adopted by the major desktops which would allow for a single thumbnailing process to be present regardless of your application mix. For instance, if you are running nautilus under E and it handles thumbnailing requests, then we don't need to start a background epsilon process. i think this is probably the real driver for dbus and i think its a good idea. mind u this can be a huge time sink. imho we should first just do it internally. develop something that works with a view to it being very generic and clean - yet easily able to be modified if needed - at least in small details, or extended. then when its settled - formalise the spec docs and propose? These don't really help the release schedule for iNDT, but I think they would create a better long term result. On 12/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I wrote (regarding raster's thumb), It seems to have an evas-object interface that abstracts away the 'thumb file' concept and just concentrates on giving you the display-object you want for a given input 'uri' and desired size (probably could give more info as well). It's.. kinda nice. :) I wonder if the fdo standards could be somehow geared more towards providing something like 'interfaces' of some sort for things like this.. rather than specifying that one should to give large and small image files somewhere. _ Dog supplies that give joy to man's best friend. Click Here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3naZ3vo7pnPMWDZKbC65edgry6H9JU4KlnEAklozN3Ee5KkA/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ 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] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
On Mon, 3 Dec 2007 14:32:37 -0300 Gustavo Sverzut Barbieri
[EMAIL PROTECTED] babbled:
On Dec 3, 2007 1:41 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote:
This is a little off-topic for the thread, but there are some long
term changes I would like to see for epsilon eventually.
1. Split thumbnail generation into pluggable processes. If we can
specify external commands for generating thumbnails, we reduce the
amount of code necessary to support new formats. This also gives us
robustness when a dependency mis-behaves and crashes the thumbnailing
process.
I'd like to have the minimum overhead with the safest approach, for
that I'd like to have just one worker process, if it crashes (or
take too long to reply) it would be restarted... but fork+exec
everytime is a no go... general usecase (not just canola) is to
thumbnail jpeg/png, these can be considered pretty safe/stable and
wouldn't cause much trouble... however using emotion to provide movie
thumbnails or an svg/edje reader may cause problems due the
flexibility to do bad things :-P
agreed. an approach where we CAN do both would probably be best.
2. Switch to dbus for client to server IPC. Many of the issues
currently with the epsilon daemon stem from some initial problems with
ecore_ipc, and the hacky conversion to ecore_con. Dbus is also
targeted at remote method invocation, which is essentially the goal of
the epsilon daemon communications.
I'm not really found of DBus, actually I was planning to have a
hand-written system to do the communication instead of ecore_{ipc,con}
because the messages are really simple and can be done to fit a fixed
size, much easier and fast to handle, also processing on peers could
avoid alloc/free and thus not trash the memory. If these are well
encapsulated like epsilon is today, I see no problem. Also, by having
such hand-written message system I'd not require ecore at all for the
server process, just the worker, it's good to have things as light as
possible.
ecore trashes memory a lot more - every event is alloced :) in general efl is
very alloc-happy. it allocs LOTS of things all the time. its kind of a
requirement that your malloc subsystem is fast and very goof at this kind of
usage. :)
3. Develop a dbus standard communication protocol with FDO. Ideally,
we could get a protocol adopted by the major desktops which would
allow for a single thumbnailing process to be present regardless of
your application mix. For instance, if you are running nautilus under
E and it handles thumbnailing requests, then we don't need to start a
background epsilon process.
I doubt it worth the pain, because if we go FDO we must remove any
attempt to use .edj as thumbnail format, and it's a good alternative
if you want to provide movie thumbnail. Going too generic may hurt
more than help if nobody else use it, and believe me these guys are
hard to get using done by others, you know the NIH syndrome...
agreed it will be painful. i don't think we should force edje into a thumbnail
format - BUT eet is possibly useful there as its agnostic when it comes to
glib, qt, efl etc.. the gtnome/kde crowd as best i know do not have any such
container format handler to pack many data items compactly into a single file
with an easy api to access it again. so we are not competing.
These don't really help the release schedule for iNDT, but I think
they would create a better long term result.
As for INdT today, yes, it won't help, but it's good to discuss the
long term so we can help. Probably I'll hack some nasty epsilon2 to
get it done in time, but I'll not even commit to CVS, it'll stay in
staff.get-e.org GIT... after we have something good for the long term,
then I can help with it and then convert canola to use it.
yeah - a bit late now :) but this discussion is good. :)
--
Gustavo Sverzut Barbieri
--
Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
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]
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Re: [E-devel] Epsilon problems
On Tue, 4 Dec 2007 16:36:48 -0600 Nathan Ingersoll [EMAIL PROTECTED] babbled: On 12/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I don't think there's a need to require that 'thumbnailing' must involve a specific means for storing some standard image format somewhere.. one may not want or need to store anything really. There's really very little difference between 'thumbnailing', 'iconifying', 'pre-viewing', ... or 'full-viewing'. At the very least, it should be a negotiable process where clients can specify the result formats they can support and the thumbnailer can select from those supported formats. A fallback requirement of png or some other standard format would be reasonable. This would allow us to support jpg, mpeg, edje, or whatever format we choose, and any clients that also support those formats could benefit. agreed - or not even a negotiation. client sends a list of formats it can handle (maybe with a priority number for each as it may handle one better than another) and the thumbnailer then choses one - if it can't, it just reports an error that it can't generate a thumb. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
On Tue, 4 Dec 2007 07:36:56 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Depends. If you're already using evas, and want to load and save image files to smaller sized (thumbs) versions, then using evas rather than going thru imlib2 could be faster - certainly for jpegs. Maybe for pngs, *if* you're saving to eet. Evas premuls all loaded non-premul argb data, and when saving back to png it un-premuls back, so we have: png-file-in - premul - scale-down - un-premul - png-file-out. Which is slower than what imlib2 would do. But, if you save the png to an eet, then as raster wanted to go with the premul flow, he made it so the no un-premul takes place when saving pngs to eet.. and likewise, no premul takes place when loading pngs encoded in eet (like eg, in edj files). Hum... that pre-mul conversion just went unoticed to me :-) BTW, how does it pre-unmul? It looks like the conversion looses bits that you can't get anymore if you're using no-premul (other softwares other than evas-based), but maybe I'm overlooking things (maybe to get the blend done you'd loose the bits anyway). Premul vs. non-premul is a long story.. I'm not sure any of us has enough years left of life to get into it here, much less when you're pressed for time (we can take it up later if you wish). :) Yes, there are 'issues' either way with this, eg. scaling deosn't give the same results with premul vs non-premul, and many other aspects here and there. But overall, premul is the way that makes the most sense for what evas is doing and what it's working with. yup. scaling is correct with premul if you have an alpha channel - without it it's not. For jpgs you don't have to worry about it since we only deal with rgb images then, hence there's no difference (and no premul or un-premul takes place). It does matter for pngs with alpha though, and then it's fastest to deal with pngs embedded in eet. But I think the cost of disk access is likely a far greater factor than any premul/un-premul operations anyway. yup. load-thing-at-its-natural-size-to-buffer-evas1 - resize-evas1- to-thing-size - draw-it-to-evas1 - set-pixels-of-buffer-evas1- as-data-of-image-obj-of-buffer-evas2 - resize-evas2-to-whatever - set-fill-and-size-of-image-obj-to-size-of-evas2 - draw-image- obj - [write-pixels-of-evas2-to-out-file-somehow] this last step either directly or again via setting the resulting pixels of buffer evas2 to another image obj that you'd have created when you 'resized' evas2, and then saving the image obj It's somewhat convoluted. I don't get why I'd need these extra steps. I'll not use current Canola's Evas to generate the thumb because the thumb generator will run on another process. But from that process I plan to just create the ecore_evas_buffer at the right thumb size and load image there (img1) resize and show, then use a hidden img2 to set the pixels based of buffer pixels, just to be able to save... I guess this is almost what you mean in your fast case? Yes, except that img2 will need to allocate its own pixels no matter what you do - because evas doesn't really allow you to set external data without it first allocating data the size of the image you want (unless there've been changes I don't know about). So, either you create the buffer evas at thumb size and also create img2 at that same thumb size (thus allocating another set of pixels) and either copy the buffer pixels to img2 pixels, or just set the buffer's pixels as img2's pixels (which will cause evas to free the pixels it first allocated for img2, since it will note that the data being set is different from the one it had) -OR- you'd first want to create img2, set its size to the thumb size, get its data, and use that data as the buffer evas' pixels, then render img1. But setting up the buffer evas this way is a bit more subtle. Neither of these are the best way though, not for images. A better way is to set img1's load options to have the image load the file data at the thumb size, and then just save it - that's all. Except of course that won't work for all image formats since it hasn't been completely implemented.. :( About size option to save, yes, it would be awesome. It's a good way for more efficient thumbing of things like edjes, and also for being able to do custom drawing on image data and have that saved directly. One other aspect I think evas could use is the ability to really set external data on images, ie. have the user set its own data+size+has_alpha, without evas allocating extra stuff. One extra idea: maybe this thumbnailer could have the ecore_evas_buffer +2 image objects created on the master process and used by children processes? Maybe this help a bit since it would be just a copy on write, no calcs would have to be done... maybe just a minimal
Re: [E-devel] Epsilon problems
On Tue, 4 Dec 2007 11:16:37 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: I wrote: For jpgs you don't have to worry about it since we only deal with rgb images then, hence there's no difference (and no premul or un-premul takes place). It does matter for pngs with alpha though, and then it's fastest to deal with pngs embedded in eet. But I think the cost of disk access is likely a far greater factor than any premul/un-premul operations anyway. I forget that the system you're dealing with is flash-drive based, not disk-drive.. so maybe it might have some impact to have to do the premul/un-premul conversions - if saving images with alpha to png. Both premul and un-premul conversions use only ints though, no floats. it may be flash- but its flash on jffs2 or on SDIO - its still not that fast. SEEK times are non-existant, but bulk IO transfer still is not that fast. hdd's still beat flash on this. flash kicks the derriere. example: on the n800 (for example), reads from the RAW flash device: Read: Flash (RAW): 14.79mb/sec Flash (JFFS2): 11.84mb/sec SD Card (RAW): 5.95mb/sec (bizarre i know - less than via FAT) SD Card (FAT): 7.53mb/sec so you win in seek times - they don't exist, but IO is still slow. either way - ballpark figures he are far below what your average hdd can get these days (60-80mb/sec sustained linear reads). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
On Thu, 6 Dec 2007 04:08:28 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Nathan wrote: I don't think there's a need to require that 'thumbnailing' must involve a specific means for storing some standard image format somewhere.. one may not want or need to store anything ... At the very least, it should be a negotiable process where clients can specify the result formats they can support and the thumbnailer can select from those supported formats. A fallback requirement of png or some other standard format would be reasonable. This would allow us to support jpg, mpeg, edje, or whatever format we choose, and any clients that also support those formats could benefit. I suppose a minimal 'standard' format for animated images would be good. This is something that doesn't seem as well-established as say png/jpg are for static images.. eg. things like mng/mpeg don't seem too widely used by the 'major' toolkits to provide say animated icons or whatnot. Animated svgs are lacking as well, but even if used eventually, it's likely that one may want to save 'thumbs' of them as animated raster images. mpg is very widely used - but it support no alpha channel. mng doesn't support lossy comrpession to the extend mpeg, xvid, ogg etc. do (it supports jpeg compression with alpha - that's about it). mng just never took off. One thing that isn't really dome in e, but could be, is to let edjes that correspond to backgrounds provide 'largesmall' thumbs in the edje itself.. ie. have two additional groups, say thumb_large and thumb_small, that give a (tweened) image representation of the thumnailed main background. Thus, the edje already contains the two generic fdo-'sized' thumbs, in the edje bg file itself - and thus no need to generate the things and save them to some other file, at least not for the two fdo-'sizes'. it COULD but then the definer has to create these, include them AND keep them up to date - which invariably is never done. :( _ Boost your business with a small business loan. Click now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3no7boEJlIdW6uesq3bZQ1Bys0EO5gL12fgDhJFHDs2D73La/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ 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] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
Carsten wrote: At the very least, it should be a negotiable process where clients can specify the result formats they can support and the thumbnailer can select from those supported formats. A fallback requirement of png or some other standard format would be reasonable. This would allow us to support jpg, mpeg, edje, or whatever format we choose, and any clients that also support those formats could benefit. I suppose a minimal 'standard' format for animated images would be good. This is something that doesn't seem as well- established as say png/jpg are for static images.. eg. things like mng/mpeg don't seem too widely used by the 'major' toolkits to provide say animated icons or whatnot. Animated svgs are lacking as well, but even if used eventually, it's likely that one may want to save 'thumbs' of them as animated raster images. mpg is very widely used - but it support no alpha channel. mng doesn't support lossy comrpession to the extend mpeg, xvid, ogg etc. do (it supports jpeg compression with alpha - that's about it). mng just never took off. As it turns out though, there's a new attempt to fix many of the 'issues' people had with the original mng format. It's being proposed by the Mozilla project, and its main focus is to have a simple format for obtaining animated pngs (with alpha), which they're calling apng. Here's a link to their spec: http://wiki.mozilla.org/APNG_Specification I briefly looked at it and it does indeed seem well suited to the goals they had in mind. I'd brought this up briefly with Vincent a few days ago since I was curious of the animated image format work he'd started a bit back (I can't recall the original email where he mentions it). Vincent had something similar in mind to Mozilla's as well, but he'd like to use some method of further compressing the animation. I'm sure he can be more specific for anyone who might be curious to help him with it.. it could end up being very nice. In any case, Mozilla's apng seems like a reasonable animated image format for people to use right now, and I hope it'll get wide adoption (I think the png group still wants to stick by mng, even if essentially no one uses it). They even have some tools to create apngs from various kinds of sources. jose. _ Click to become an artist and quit your boring job. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mzjrY1oPA0xIernC8yoLkHVhbIwrQl7DJmjShiM7bB8krqg/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
One thing that isn't really dome in e, but could be, is to let edjes that correspond to backgrounds provide 'largesmall' thumbs in the edje itself.. ie. have two additional groups, say thumb_large and thumb_small, that give a (tweened) image representation of the thumnailed main background. Thus, the edje already contains the two generic fdo-'sized' thumbs, in the edje bg file itself - and thus no need to generate the things and save them to some other file, at least not for the two fdo-'sizes'. Let's play with this idea a bit and see what we can squeeze out of it. Let's suppose we want to write an e17 module to display e17 backgrounds in a way similar to Apple's iTunes coverflow. Now, it's not difficult to actually do this exactly the same as they've done it, we might just need to be able to projectively rotate and gradient-fade images - and indeed evas may one day get such a capability, one way or another. But we could do something like this without direct support from evas if we had a little support from the bg's themselves. Let's say that some bg's had thumb_large_front, thumb_ large_left and thumb_large_right groups which held thumbs with gradient reflections, with the latter at some left/right angles. Given that, it would be just a matter of implementing the dynamics of an e17 coverflow-like background browser.. It might not be exactly as smooth and whatnot as Apple's, but it'd likely be nice enough - and quite fast (and with animated 'covers'). We could go all the way and do this exactly (or better) than Apple's, just use a thumb_large group if there, or generate the live thumb (as is now done) if not, and dynamically generate the projective rotations and grad-reflections via fast-enough software routines (it's not difficult), then do the browser-module. Or do other similar kinds of ideas.. maybe things with shadows, maybe things that come in at some angle, like raster's expedite flowers but with the thumbs slightly overlapping, or whatever. The point here being that the notions of a thumbnailer and that of the thumbnail display browser might optionally be 'fitted' to work together, or not, and that one really has a lot of flexibility in what can be done here.. either way. _ Credit card rates to high? Click here to find home equity line of credit options. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m3ub5L2NtUoQSXl6grLlNO0R2cb8FBzXn6DwOFfq84wsawQ/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
Nathan wrote: I don't think there's a need to require that 'thumbnailing' must involve a specific means for storing some standard image format somewhere.. one may not want or need to store anything ... At the very least, it should be a negotiable process where clients can specify the result formats they can support and the thumbnailer can select from those supported formats. A fallback requirement of png or some other standard format would be reasonable. This would allow us to support jpg, mpeg, edje, or whatever format we choose, and any clients that also support those formats could benefit. I suppose a minimal 'standard' format for animated images would be good. This is something that doesn't seem as well-established as say png/jpg are for static images.. eg. things like mng/mpeg don't seem too widely used by the 'major' toolkits to provide say animated icons or whatnot. Animated svgs are lacking as well, but even if used eventually, it's likely that one may want to save 'thumbs' of them as animated raster images. One thing that isn't really dome in e, but could be, is to let edjes that correspond to backgrounds provide 'largesmall' thumbs in the edje itself.. ie. have two additional groups, say thumb_large and thumb_small, that give a (tweened) image representation of the thumnailed main background. Thus, the edje already contains the two generic fdo-'sized' thumbs, in the edje bg file itself - and thus no need to generate the things and save them to some other file, at least not for the two fdo-'sizes'. _ Boost your business with a small business loan. Click now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3no7boEJlIdW6uesq3bZQ1Bys0EO5gL12fgDhJFHDs2D73La/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
Nathan wrote: 1. Split thumbnail generation into pluggable processes. If we can specify external commands for generating thumbnails, we reduce the amount of code necessary to support new formats. This also gives us robustness when a dependency mis-behaves and crashes the thumbnailing process. 2. Switch to dbus for client to server IPC. Many of the issues currently with the epsilon daemon stem from some initial problems with ecore_ipc, and the hacky conversion to ecore_con. Dbus is also targeted at remote method invocation, which is essentially the goal of the epsilon daemon communications. 3. Develop a dbus standard communication protocol with FDO. Ideally, we could get a protocol adopted by the major desktops which would allow for a single thumbnailing process to be present regardless of your application mix. For instance, if you are running nautilus under E and it handles thumbnailing requests, then we don't need to start a background epsilon process. I think these are all reasonable ideas. I especially like the idea of having pluggable thumbnail generation that can be used by different desktop/handheld environments. It's absurd that right now there's really just: everything has to be some 'standard' image format or everyone does their own thing and no one else can use it but them. I don't think there's a need to require that 'thumbnailing' must involve a specific means for storing some standard image format somewhere.. one may not want or need to store anything really. There's really very little difference between 'thumbnailing', 'iconifying', 'pre-viewing', ... or 'full-viewing'. If web-browsers have a notion of interfaces for plugings that can display stuff as varied as they do, there shouldn't be any reason why desktops can't be as flexible, or maybe do even better. jose. _ Looking for insurance? Click to compare and save big. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m275pfSc0Kmxy2ouBR0YuLqtPmFmIrPpMwHwci7k448XSWU/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
I wrote: For jpgs you don't have to worry about it since we only deal with rgb images then, hence there's no difference (and no premul or un-premul takes place). It does matter for pngs with alpha though, and then it's fastest to deal with pngs embedded in eet. But I think the cost of disk access is likely a far greater factor than any premul/un-premul operations anyway. I forget that the system you're dealing with is flash-drive based, not disk-drive.. so maybe it might have some impact to have to do the premul/un-premul conversions - if saving images with alpha to png. Both premul and un-premul conversions use only ints though, no floats. _ Free information on hiring a Business Consulting Service. Click here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m0mYEcDI9G4NoYxgzY3bLAGgAk35H8Jh0LfBtPMnL14vCQo/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
On 12/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I don't think there's a need to require that 'thumbnailing' must involve a specific means for storing some standard image format somewhere.. one may not want or need to store anything really. There's really very little difference between 'thumbnailing', 'iconifying', 'pre-viewing', ... or 'full-viewing'. At the very least, it should be a negotiable process where clients can specify the result formats they can support and the thumbnailer can select from those supported formats. A fallback requirement of png or some other standard format would be reasonable. This would allow us to support jpg, mpeg, edje, or whatever format we choose, and any clients that also support those formats could benefit. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
I wrote: I looked at e_thumb_main - it saves to eet files directly. That's not really sufficient for giving flexible thumbnail-file saving functionality for others to use - it's just too restrictive ... Having said that, I also just took a quick look at epsilon.. and it seems to me that 'e_thumb' has some nice aspects as well over epsilon - for efl based stuff. It seems to have an evas-object interface that abstracts away the 'thumb file' concept and just concentrates on giving you the display-object you want for a given input 'uri' and desired size (probably could give more info as well). I'm not sure what the real difference is between an e_live_thumb vs a 'plain' e_thumb, though the former seems to want the latter. Well, maybe there's room here for some kind of revamp/merger/ new-thing or whatever that could take the best from both.. But I think that something like this could benefit greatly from: 1. Contrast and compare with other existing solutions, say from kde/gnome. 2. Feedback from people who could use such a thing, say toolkit, fm, wm, ... writers. jose. _ Click for free info on earning your associates degrees. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l8StEIKOKuEUXtIZoRwUDYMvjvRS7bBFdvoSgHrd4cnXnaY/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
I wrote (regarding raster's thumb), It seems to have an evas-object interface that abstracts away the 'thumb file' concept and just concentrates on giving you the display-object you want for a given input 'uri' and desired size (probably could give more info as well). It's.. kinda nice. :) I wonder if the fdo standards could be somehow geared more towards providing something like 'interfaces' of some sort for things like this.. rather than specifying that one should to give large and small image files somewhere. _ Dog supplies that give joy to man's best friend. Click Here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3naZ3vo7pnPMWDZKbC65edgry6H9JU4KlnEAklozN3Ee5KkA/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
On 12/3/07, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote:
On Dec 3, 2007 1:41 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote:
I'd like to have the minimum overhead with the safest approach, for
that I'd like to have just one worker process, if it crashes (or
take too long to reply) it would be restarted... but fork+exec
everytime is a no go... general usecase (not just canola) is to
thumbnail jpeg/png, these can be considered pretty safe/stable and
wouldn't cause much trouble... however using emotion to provide movie
thumbnails or an svg/edje reader may cause problems due the
flexibility to do bad things :-P
Just to be clear, I'm not advocating fork+exec for each thumbnail for
every case. My thinking is more along the lines that we keep thumbnail
generation for core formats (jpeg, png) inside the primary worker
thread. The difference is rather than requiring a new plugin for each
format we want to support, allow for fork+exec style generation for
specified file formats in order to re-use existing infrastructure.
This could also be improved if some external handlers could take a
batch of arguments. We can certainly provide plugins for formats that
we support, which could improve efficiency, but we can't expect to
support all file types.
Thumbnailing is also a task that fits well in a parallel model, since
the task has a fair amount of latency reading from disk. By using
multiple workers you can take advantage of this latency and have CPU
bound processes while others are IO bound. Also, since the tasks are
independent they can be scaled out nicely across multiple cores. Both
of these aspects may be irrelevant for Canola, since it is running off
a flash based drive on single core CPU.
I'm not really found of DBus, actually I was planning to have a
hand-written system to do the communication instead of ecore_{ipc,con}
because the messages are really simple and can be done to fit a fixed
size, much easier and fast to handle, also processing on peers could
avoid alloc/free and thus not trash the memory. If these are well
encapsulated like epsilon is today, I see no problem. Also, by having
such hand-written message system I'd not require ecore at all for the
server process, just the worker, it's good to have things as light as
possible.
While I agree that keeping things light is important, I would like to
know your reasoning behind why dbus is not a reasonable candidate in
this case? I don't have any data to back it up, but I find it hard to
believe that the communication overhead of dbus would be anywhere near
the relative slowness of the actual thumbnail generation. As long as
you can queue requests, the latency should be completely dominated by
waiting for the resulting thumbnail. The IPC speed should really only
be a problem if you are making round-trip requests and waiting on the
result before the next request.
I doubt it worth the pain, because if we go FDO we must remove any
attempt to use .edj as thumbnail format, and it's a good alternative
if you want to provide movie thumbnail. Going too generic may hurt
more than help if nobody else use it, and believe me these guys are
hard to get using done by others, you know the NIH syndrome...
Except what you're encouraging is exactly NIH (not that we have any
lack of that around here). What is the advantage of using edje for
storing generated thumbnails vs using the filesystem? The main
advantage of edje is efficient bundling of data into a single file,
but with thumbnails, they are more tied to their original source than
with other surrounding files. Also, edje writes out the entire eet
each time a save is done, this means that you will now be writing out
every enclosed thumbnail instead of the single one that is updated.
It's difficult to say if no one else would use it if we're not talking
to anyone else about it. I think it is worth opening a discussion with
FDO members with a base spec as a point of reference.
As for INdT today, yes, it won't help, but it's good to discuss the
long term so we can help. Probably I'll hack some nasty epsilon2 to
get it done in time, but I'll not even commit to CVS, it'll stay in
staff.get-e.org GIT... after we have something good for the long term,
then I can help with it and then convert canola to use it.
Oops, I got the capitalization scheme of INdT wrong again. This sounds
like a reasonable plan for your short-term issue.
Good luck with your release.
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
On Dec 3, 2007 9:46 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote:
On 12/3/07, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote:
On Dec 3, 2007 1:41 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote:
I'd like to have the minimum overhead with the safest approach, for
that I'd like to have just one worker process, if it crashes (or
take too long to reply) it would be restarted... but fork+exec
everytime is a no go... general usecase (not just canola) is to
thumbnail jpeg/png, these can be considered pretty safe/stable and
wouldn't cause much trouble... however using emotion to provide movie
thumbnails or an svg/edje reader may cause problems due the
flexibility to do bad things :-P
Just to be clear, I'm not advocating fork+exec for each thumbnail for
every case. My thinking is more along the lines that we keep thumbnail
generation for core formats (jpeg, png) inside the primary worker
thread. The difference is rather than requiring a new plugin for each
format we want to support, allow for fork+exec style generation for
specified file formats in order to re-use existing infrastructure.
This could also be improved if some external handlers could take a
batch of arguments. We can certainly provide plugins for formats that
we support, which could improve efficiency, but we can't expect to
support all file types.
ah, ok, this makes sense. I was afraid of one trying to call
imagimagick's convert to just process jpeg, but it make sense to use
it as a fallback (that app understand almost every format on earth).
Thumbnailing is also a task that fits well in a parallel model, since
the task has a fair amount of latency reading from disk. By using
multiple workers you can take advantage of this latency and have CPU
bound processes while others are IO bound. Also, since the tasks are
independent they can be scaled out nicely across multiple cores. Both
of these aspects may be irrelevant for Canola, since it is running off
a flash based drive on single core CPU.
yes, I agree with parallel and most implementations (epsilon/e_thumb)
seems to support multiple workers, I'd like to keep it. As for it
doesn't make sense for us, _today_ it doesn't but there are multi-core
ARM comming, so it's good to think a bit ahead here :-)
I'm not really found of DBus, actually I was planning to have a
hand-written system to do the communication instead of ecore_{ipc,con}
because the messages are really simple and can be done to fit a fixed
size, much easier and fast to handle, also processing on peers could
avoid alloc/free and thus not trash the memory. If these are well
encapsulated like epsilon is today, I see no problem. Also, by having
such hand-written message system I'd not require ecore at all for the
server process, just the worker, it's good to have things as light as
possible.
While I agree that keeping things light is important, I would like to
know your reasoning behind why dbus is not a reasonable candidate in
this case? I don't have any data to back it up, but I find it hard to
believe that the communication overhead of dbus would be anywhere near
the relative slowness of the actual thumbnail generation. As long as
you can queue requests, the latency should be completely dominated by
waiting for the resulting thumbnail. The IPC speed should really only
be a problem if you are making round-trip requests and waiting on the
result before the next request.
it can be, I also don't have any numbers to back me up... maybe I'm
just too paranoid after some problems we had with the device, things
that looked ok suddently turned into bootleneck, but with more time to
test I can prove myself wrong... these things always happen when I'm
under pressure :-P
I doubt it worth the pain, because if we go FDO we must remove any
attempt to use .edj as thumbnail format, and it's a good alternative
if you want to provide movie thumbnail. Going too generic may hurt
more than help if nobody else use it, and believe me these guys are
hard to get using done by others, you know the NIH syndrome...
Except what you're encouraging is exactly NIH (not that we have any
lack of that around here). What is the advantage of using edje for
storing generated thumbnails vs using the filesystem? The main
advantage of edje is efficient bundling of data into a single file,
but with thumbnails, they are more tied to their original source than
with other surrounding files. Also, edje writes out the entire eet
each time a save is done, this means that you will now be writing out
every enclosed thumbnail instead of the single one that is updated.
I was not clear here: I was saying to use edje to store each file, but
it was more target at movie thumbnails (see what rage_thumbd does).
But sure, we could use some mng/mjpeg/mpeg1 or another simple format.
It's difficult to say if no one else would use it if we're not talking
to anyone else about it. I think it is worth opening a
Re: [E-devel] Epsilon problems
Depends. If you're already using evas, and want to load and save image files to smaller sized (thumbs) versions, then using evas rather than going thru imlib2 could be faster - certainly for jpegs. Maybe for pngs, *if* you're saving to eet. Evas premuls all loaded non-premul argb data, and when saving back to png it un-premuls back, so we have: png-file-in - premul - scale-down - un-premul - png-file-out. Which is slower than what imlib2 would do. But, if you save the png to an eet, then as raster wanted to go with the premul flow, he made it so the no un-premul takes place when saving pngs to eet.. and likewise, no premul takes place when loading pngs encoded in eet (like eg, in edj files). Hum... that pre-mul conversion just went unoticed to me :-) BTW, how does it pre-unmul? It looks like the conversion looses bits that you can't get anymore if you're using no-premul (other softwares other than evas-based), but maybe I'm overlooking things (maybe to get the blend done you'd loose the bits anyway). Premul vs. non-premul is a long story.. I'm not sure any of us has enough years left of life to get into it here, much less when you're pressed for time (we can take it up later if you wish). :) Yes, there are 'issues' either way with this, eg. scaling deosn't give the same results with premul vs non-premul, and many other aspects here and there. But overall, premul is the way that makes the most sense for what evas is doing and what it's working with. For jpgs you don't have to worry about it since we only deal with rgb images then, hence there's no difference (and no premul or un-premul takes place). It does matter for pngs with alpha though, and then it's fastest to deal with pngs embedded in eet. But I think the cost of disk access is likely a far greater factor than any premul/un-premul operations anyway. load-thing-at-its-natural-size-to-buffer-evas1 - resize-evas1- to-thing-size - draw-it-to-evas1 - set-pixels-of-buffer-evas1- as-data-of-image-obj-of-buffer-evas2 - resize-evas2-to-whatever - set-fill-and-size-of-image-obj-to-size-of-evas2 - draw-image- obj - [write-pixels-of-evas2-to-out-file-somehow] this last step either directly or again via setting the resulting pixels of buffer evas2 to another image obj that you'd have created when you 'resized' evas2, and then saving the image obj It's somewhat convoluted. I don't get why I'd need these extra steps. I'll not use current Canola's Evas to generate the thumb because the thumb generator will run on another process. But from that process I plan to just create the ecore_evas_buffer at the right thumb size and load image there (img1) resize and show, then use a hidden img2 to set the pixels based of buffer pixels, just to be able to save... I guess this is almost what you mean in your fast case? Yes, except that img2 will need to allocate its own pixels no matter what you do - because evas doesn't really allow you to set external data without it first allocating data the size of the image you want (unless there've been changes I don't know about). So, either you create the buffer evas at thumb size and also create img2 at that same thumb size (thus allocating another set of pixels) and either copy the buffer pixels to img2 pixels, or just set the buffer's pixels as img2's pixels (which will cause evas to free the pixels it first allocated for img2, since it will note that the data being set is different from the one it had) -OR- you'd first want to create img2, set its size to the thumb size, get its data, and use that data as the buffer evas' pixels, then render img1. But setting up the buffer evas this way is a bit more subtle. Neither of these are the best way though, not for images. A better way is to set img1's load options to have the image load the file data at the thumb size, and then just save it - that's all. Except of course that won't work for all image formats since it hasn't been completely implemented.. :( About size option to save, yes, it would be awesome. It's a good way for more efficient thumbing of things like edjes, and also for being able to do custom drawing on image data and have that saved directly. One other aspect I think evas could use is the ability to really set external data on images, ie. have the user set its own data+size+has_alpha, without evas allocating extra stuff. One extra idea: maybe this thumbnailer could have the ecore_evas_buffer +2 image objects created on the master process and used by children processes? Maybe this help a bit since it would be just a copy on write, no calcs would have to be done... maybe just a minimal saving? Do you see any problems with that (some file descriptors that would be inherited and problems could show?) Ummm... let's hold those thoughts til a bit later. :) _
Re: [E-devel] Epsilon problems
As raster mentioned, and as I believe, the best thing for epsilon would be a rewrite using evas instead of imlib2... something extremely similar to e_thumb. Raster said that if this did occur, e would likely change to using epsilon as well. If epsilon is still using imlib2 for creating thumbs, it must be either because at the time it first appeared evas could not then save images to files, or maybe because it wanted to use more image loaders/savers than evas had (evas had built-in jpg/png/eet only at first, or rather at second - at first it also used imlib2 for loading, and the original-original evas used imlib2 for drawing too). If so, these two issues should no longer be relevant: evas can save to files, and one can write as many loaders/savers as desired. In fact, I think that imlib2 doesn't have an svg loader, which evas does. Any special-purpose loaders that one may want for epsilon, but not in current evas, one could write expressly for epsilon if desired. On the other hand, uing evas for simply loading and saving 'thumbnails' of a couple of images is somewhat of an overkill.. but not if you're doing many. - how expensive is evas/ecore_evas_buffer in comparison to imlib2 to generate thumbs; You don't need ecore_evas_buffer to generate 'thumbs' of jpg/png/svg, that's only for generating smaller views of a 'general' evas canvas rendering. For example, if you want to show a live thumb of an animated edje, or bunch of edjes, or just about anything. - saving to eet the uncompressed data really help? Ok, this is more about testing on our hardware, but maybe it will not help and it's cheaper to uncompress a JPEG than read pixels from flash (flash slowness versus cpu usage). In that case, what's the best option to save the image as JPEG? Create an evas_object_image on the same canvas, set it's pixesl to buffer pixels and then evas_object_image_save() it? Saving what to eet? Thumbs of jpgs/pngs? Depends what you want to do with them, and how many... The best option to save the image as JPEG is somewhat hard to say - it depends on the context you're working with. But if you're using evas, and you want to use it to load and save 'thumbs' of jpgs back as jpgs, then just create an image object (hide it), set the load size (evas uses the same 'quick' thumbing mechanism for jpgs as epeg), set the file, and then save it to the thumb file (use flags for jpg quality and compression), repeating for as many image files as you want. Or if you want to do this in a separate evas, then create a buffer evas and then do as above. Also, what to change in e_thumb to make it the perfect epsilon? fdo-compatible saving? Use epeg? What is fdo-compatible saving? A more general question would be: What does epsilon not have right now that would make it better for people's needs? Any capabilities it's missing that people want? Any api additions or modifications anyone have in mind? jose. _ Discount Online Trading - Click Now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mJ8XfD6Y4cnWo37eHOLUtROMi38mJQe5Buj2XyWLbBt0ctS/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
- how expensive is evas/ecore_evas_buffer in comparison to imlib2 to generate thumbs; You don't need ecore_evas_buffer to generate 'thumbs' of jpg/png/svg, that's only for generating smaller views of a 'general' evas canvas rendering. For example, if you want to show a live thumb of an animated edje, or bunch of edjes, or just about anything. Unless... Oh, oh.. unless we didn't finish off implementing the load-size option for all loaders. I know we did it for the svg loader, and that the jpg loader respects loading scaled-down-by-dyads, but I can't recall if we really did finish off making sure that all loaders respected the load-size option.. need to take a look. If not, then it should be filed as an evas BUG. _ Surf a world without wires. Click now for great wireless Internet solutions! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mFpiycmcZ4UgiHjwK5y5QltR0iyZyopTyddMt9vTAwuygac/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
On Dec 2, 2007 6:16 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
As raster mentioned, and as I believe, the best thing for epsilon
would be a rewrite using evas instead of imlib2... something
extremely similar to e_thumb. Raster said that if this did occur,
e would likely change to using epsilon as well.
If epsilon is still using imlib2 for creating thumbs, it must
be either because at the time it first appeared evas could not then
save images to files, or maybe because it wanted to use more image
loaders/savers than evas had (evas had built-in jpg/png/eet only at
first, or rather at second - at first it also used imlib2 for loading,
and the original-original evas used imlib2 for drawing too).
If so, these two issues should no longer be relevant: evas
can save to files, and one can write as many loaders/savers as desired.
In fact, I think that imlib2 doesn't have an svg loader, which evas
does. Any special-purpose loaders that one may want for epsilon, but
not in current evas, one could write expressly for epsilon if desired.
On the other hand, uing evas for simply loading and saving
'thumbnails' of a couple of images is somewhat of an overkill.. but
not if you're doing many.
we're doing many, and working on an embedded device :-(
- how expensive is evas/ecore_evas_buffer in comparison to imlib2
to generate thumbs;
You don't need ecore_evas_buffer to generate 'thumbs' of
jpg/png/svg, that's only for generating smaller views of a 'general'
evas canvas rendering. For example, if you want to show a live thumb
of an animated edje, or bunch of edjes, or just about anything.
that's why I asked, without any testing I'd say it will be slower/overkill...
- saving to eet the uncompressed data really help? Ok, this is
more about testing on our hardware, but maybe it will not help
and it's cheaper to uncompress a JPEG than read pixels from flash
(flash slowness versus cpu usage). In that case, what's the best
option to save the image as JPEG? Create an evas_object_image on
the same canvas, set it's pixesl to buffer pixels and then
evas_object_image_save() it?
Saving what to eet? Thumbs of jpgs/pngs? Depends what you
want to do with them, and how many... The best option to save
the image as JPEG is somewhat hard to say - it depends on the
context you're working with.
since our thumbnailer is still just used for photos and thus JPEG (ok,
some people have them in different formats, but JPEG is the most used
here), we're fine with a EPEG based thing.
But if you're using evas, and you want to use it to load
and save 'thumbs' of jpgs back as jpgs, then just create an image
object (hide it), set the load size (evas uses the same 'quick'
thumbing mechanism for jpgs as epeg), set the file, and then save
it to the thumb file (use flags for jpg quality and compression),
repeating for as many image files as you want. Or if you want to
do this in a separate evas, then create a buffer evas and then do
as above.
basically what I wrote :-)
Also, what to change in e_thumb to make it the perfect epsilon?
fdo-compatible saving? Use epeg?
What is fdo-compatible saving?
save to ~/.thumbnails/{large,normal,failed}/$md5hash.$ext
A more general question would be: What does epsilon not
have right now that would make it better for people's needs?
Any capabilities it's missing that people want? Any api additions
or modifications anyone have in mind?
Epsilon is almost good for us, we even have it patched to generate in
this canola size, we could make this sizes pluggable (at compile or
runtime) in some way, but the problem for us is that it is crashing
for no good reason... and I couldn't find out the reason and I really
don't have the time to do some more elaborated analysis (the Canola
release is 12-December :-D)... that's why I'm trying to quickly solve
our problem then, after the release look into fixing this properly.
--
Gustavo Sverzut Barbieri
--
Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
On Dec 2, 2007 8:02 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: - how expensive is evas/ecore_evas_buffer in comparison to imlib2 to generate thumbs; You don't need ecore_evas_buffer to generate 'thumbs' of jpg/png/svg, that's only for generating smaller views of a 'general' evas canvas rendering. For example, if you want to show a live thumb of an animated edje, or bunch of edjes, or just about anything. Unless... Oh, oh.. unless we didn't finish off implementing the load-size option for all loaders. I know we did it for the svg loader, and that the jpg loader respects loading scaled-down-by-dyads, but I can't recall if we really did finish off making sure that all loaders respected the load-size option.. need to take a look. If not, then it should be filed as an evas BUG. seems that JPEG loader does respect load_size, PNG doesn't, not sure about others. I know that EPEG is there and Evas doesn't use it... e_thumb doesn't use it, but use Evas... I'm newbie to this project, so maybe you can help me understand this: is epeg just a test and the functionality was integrated to Evas's JPEG loader? This would be amazing. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
Gustavo Sverzut Barbieri wrote: On Dec 2, 2007 8:02 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: - how expensive is evas/ecore_evas_buffer in comparison to imlib2 to generate thumbs; You don't need ecore_evas_buffer to generate 'thumbs' of jpg/png/svg, that's only for generating smaller views of a 'general' evas canvas rendering. For example, if you want to show a live thumb of an animated edje, or bunch of edjes, or just about anything. Unless... Oh, oh.. unless we didn't finish off implementing the load-size option for all loaders. I know we did it for the svg loader, and that the jpg loader respects loading scaled-down-by-dyads, but I can't recall if we really did finish off making sure that all loaders respected the load-size option.. need to take a look. If not, then it should be filed as an evas BUG. seems that JPEG loader does respect load_size, PNG doesn't, not sure about others. I know that EPEG is there and Evas doesn't use it... e_thumb doesn't use it, but use Evas... I'm newbie to this project, so maybe you can help me understand this: is epeg just a test and the functionality was integrated to Evas's JPEG loader? This would be amazing. epeg was created a long time ago, as the then gnome thumbnailer sucked. So it is a drop-in replacement for it. http://64.233.183.104/search?q=cache:K87JHskYhNwJ:enlightenment.sourceforge.net/Libraries/Epeg/+epeghl=enct=clnkcd=6gl=noclient=firefox-a Sebastian - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
Gustavo wrote: - how expensive is evas/ecore_evas_buffer in comparison to imlib2 to generate thumbs; You don't need ecore_evas_buffer to generate 'thumbs' of jpg/png/svg, that's only for generating smaller views of a 'general' evas canvas rendering. For example, if you want to show a live thumb of an animated edje, or bunch of edjes, or just about anything. that's why I asked, without any testing I'd say it will be slower/ overkill... Depends. If you're already using evas, and want to load and save image files to smaller sized (thumbs) versions, then using evas rather than going thru imlib2 could be faster - certainly for jpegs. Maybe for pngs, *if* you're saving to eet. Evas premuls all loaded non-premul argb data, and when saving back to png it un-premuls back, so we have: png-file-in - premul - scale-down - un-premul - png-file-out. Which is slower than what imlib2 would do. But, if you save the png to an eet, then as raster wanted to go with the premul flow, he made it so the no un-premul takes place when saving pngs to eet.. and likewise, no premul takes place when loading pngs encoded in eet (like eg, in edj files). What would be slower is if you went thru intermediate buffer evases to do down-scaling, ie. one would then have: load-thing-at-its-natural-size-to-buffer-evas1 - resize-evas1-to- thing-size - draw-it-to-evas1 - set-pixels-of-buffer-evas1-as-data -of-image-obj-of-buffer-evas2 - resize-evas2-to-whatever - set-fill -and-size-of-image-obj-to-size-of-evas2 - draw-image-obj - [write- pixels-of-evas2-to-out-file-somehow] this last step either directly or again via setting the resulting pixels of buffer evas2 to another image obj that you'd have created when you 'resized' evas2, and then saving the image obj It's somewhat convoluted. I looked at e_thumb_main - it saves to eet files directly. That's not really sufficient for giving flexible thumbnail-file saving functionality for others to use - it's just too restrictive (and not really as fast as it could be in some cases). I think evas needs to add an image saving 'size' option, maybe best done via the current flags for saving, so that you can save an image that alreday exists at some size (for whatever reason), to a file at whatever other size one wants. seems that JPEG loader does respect load_size, PNG doesn't, not sure about others. Bummer. But it's very easy to finish this off, for anyone who wants to give it a shot.. :) I'm newbie to this project, so maybe you can help me understand this: is epeg just a test and the functionality was integrated to Evas's JPEG loader? This would be amazing. That was raster's great desire - to have the evas jpeg loader do what epeg did, and so did he add that in. :) As to your being a newbie to the project.. I think you've been a tremendous inspiration to everyone here Gustavo, you and your friends and collegues there at Canola. Really. jose. _ Study law at a school near you. Click for more info. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oFGmXCSm0cvWIFZ0N1bFZGJDUQ6vQVhZYPYDKK05IzLH0Ji/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
As raster mentioned, and as I believe, the best thing for epsilon would be a rewrite using evas instead of imlib2... something extremely similar to e_thumb. Raster said that if this did occur, e would likely change to using epsilon as well. On Nov 30, 2007 8:01 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: Hi guys, So the canola team is in a hurry to launch the new version, but we have some problems that we cannot solve that easily, one of them is about Epsilon. I have not much information, that's why I'm asking help, if I did have this info, probably I'd have fixed this already, but here it goes: 1 - we're using an ARM platform (omap2420, Nokia N800) and getting problems with ld-linux doing unaligned loads! Really, it's not about libepsilon.so execution, but ld-linux loading it. It's really hard to understand/check/solve. Possible this is the cause of other problems. If possible, could you help me to look at epsilon code and improve possible bits? 2 - from time to time we get SPANK SPANK errors from clients accessing the server. I'm not sure if the server is not replying, if it's dying or if it's being launched and client is timing out before it's able to reply. If someone have time to improve anything, please do and commit, I read the commit list so I'll compile and report ASAP. Thanks, -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
On Dec 1, 2007 4:44 PM, Stephen Houston [EMAIL PROTECTED] wrote: As raster mentioned, and as I believe, the best thing for epsilon would be a rewrite using evas instead of imlib2... something extremely similar to e_thumb. Raster said that if this did occur, e would likely change to using epsilon as well. Ok, I've discussed this at #edevelop with some folks, I'll probably use e_thumb myself because for Canola we need a special, non-standard size: instead of bounding box of 128x128 or 256x256 we need a fixed height of 96 with variable width (see http://www.marceloeduardo.com/blog/design/graphical-design/canola-20-design-process-the-photo-viewer). So using the fdo stuff will not help that much, at least not at this part... sure we can try to use fdo sizes for video thumbs or something else. As for e_thumb, I did a quick view of its code and looks nice and small, that's great, but I wonder: - how expensive is evas/ecore_evas_buffer in comparison to imlib2 to generate thumbs; - saving to eet the uncompressed data really help? Ok, this is more about testing on our hardware, but maybe it will not help and it's cheaper to uncompress a JPEG than read pixels from flash (flash slowness versus cpu usage). In that case, what's the best option to save the image as JPEG? Create an evas_object_image on the same canvas, set it's pixesl to buffer pixels and then evas_object_image_save() it? Also, what to change in e_thumb to make it the perfect epsilon? fdo-compatible saving? Use epeg? I'll have a look at this next week, so any tips before that is appreciated :-) -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
Well I don't understand why you couldn't have the fdo sizes and then another option as a feature for setting a custom size.. and of course, you wouldn't want to save to eet. On Dec 1, 2007 5:16 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Dec 1, 2007 4:44 PM, Stephen Houston [EMAIL PROTECTED] wrote: As raster mentioned, and as I believe, the best thing for epsilon would be a rewrite using evas instead of imlib2... something extremely similar to e_thumb. Raster said that if this did occur, e would likely change to using epsilon as well. Ok, I've discussed this at #edevelop with some folks, I'll probably use e_thumb myself because for Canola we need a special, non-standard size: instead of bounding box of 128x128 or 256x256 we need a fixed height of 96 with variable width (see http://www.marceloeduardo.com/blog/design/graphical-design/canola-20-design-process-the-photo-viewer ). So using the fdo stuff will not help that much, at least not at this part... sure we can try to use fdo sizes for video thumbs or something else. As for e_thumb, I did a quick view of its code and looks nice and small, that's great, but I wonder: - how expensive is evas/ecore_evas_buffer in comparison to imlib2 to generate thumbs; - saving to eet the uncompressed data really help? Ok, this is more about testing on our hardware, but maybe it will not help and it's cheaper to uncompress a JPEG than read pixels from flash (flash slowness versus cpu usage). In that case, what's the best option to save the image as JPEG? Create an evas_object_image on the same canvas, set it's pixesl to buffer pixels and then evas_object_image_save() it? Also, what to change in e_thumb to make it the perfect epsilon? fdo-compatible saving? Use epeg? I'll have a look at this next week, so any tips before that is appreciated :-) -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
