On Sat, May 23, 2009 at 12:12 AM, Jose Gonzalez <jose_...@juno.com> wrote: > Gustavo wrote: > >>>> .......... >>>> >>> >>> Nonsense. It's just as possible to do vector stuff as raster >>> stuff with evas, api wise. It's just a pain to support all the >>> various engines people have been adding (in particular the >>> 16bpp ones which you pushed for and now have no interest in >>> supporting), and also to work with its primitive internal engine >>> func api which was designed a long time ago for a quick and >>> limited set of abilities. This latter wouldn't be such a big deal >>> to change if again there were fewer engines. >>> >> >> Where do you want to go with this? I keep reading you complaining >> about 16bpp engine, actually you're the only one that seems to not get >> it right. Even raster got to understand with its purpose and accepts >> it, but you keep pushing against it. The purpose of this engine was >> never to be complete (no gradients), or super-correct (no smooth >> scale, no render ops, ...), but to be fast and cover the basics that >> embedded world uses, you could consider it a subset. And there are >> people using it, just not myself. Cedric uses it with SDL, Vincent and >> Lars use it with WinCE. >> >> >> > > It's not a 'subset', it's crap. And completely unnecessary.
Ok, you are right and the world is wrong. Canola is totally unusable in maemo without 16bpp engine. You can get noticeable speedups in openmoko as well. I'm pretty sure Cedric and WinCE guys can step in and say their experiences as well. And regarding crap, it's such a hard word to describe work that INdT paid me to do for more than 3 months. It's very optimized and measured, I'm pretty sure it's not crap. > The return on their investment is a net negative, increasingly > heavier and heavier over time. Ok, so negative that it enable one of the strongest advocate of EFL. Without Canola's marketing of EFL we would not have things like BlueMaemo (maemo/bluetooth remote control), the openmoko version of bluemaemo, Carman. Without Canola we'd have no Python-EFL that is did bring lots of developers to our platform, and probably would not have myself or the dozen guys that I pay to work on EFL. That said, better not write such stupid thing than write it "just in case". You're doing no help in the last 2 years or so, then you come to the project to start creating such stupid flamewars. > Time and effort spent on those 'engines' would've been *far* > better spent in optimizing transform/sampling/compositing and > 32->16 conversion, for the 'important' architectures. I don't know if you forgot on purpose or not, but I keep saying that's not JUST ABOUT THE FSCKING TRANSFORM, IT'S ABOUT THE AMOUNT OF DATA. 24bpp will consume 4 bytes per pixel (due alignment), 16bpp will consume 2 bytes, that's half of the data that you have to load, that's half data to saturate your memory bus, cache. And it's less data to operate on, you can do all R, G and B multiply by A in the same instruction (given some quality constraints that were good enough for users and even graphical designers accepted it). Sure it will use more shifts and masks, but that's almost for free in most ARM platforms. But go ahead, "show me the code" as we usually say. Prove me wrong, don't flame me wrong. > As to what Carsten feels now and/or earlier regarding these > 'engines', only he can really say. > > Mind you there are too many engines period, it's just that > these engines have one particular aspect to them: they introduce > the 16bpp color space into input/src data, and doing so is what > amounts to a destructive result. You can easily ignore that, you did so for gradient2. There is no YUV->RGB (video/emotion), there is no gradient, there is no smooth scale. You're not forced to implement such. I doubt you have not finished a fast gradient2 on software/32 or gl because of software/16. > PS. > Gradients are actually one of the few things that you *could* > add fairly easily to these engines, and have them look decent. > It's just about everything else that's a problem. Why care about things that nobody cares? I worked with over dozen designers and none could think of use of single gradients. They usually want layers or semi transparent and radial and all you can imagine, you'll not be able to render that during runtime, specially on such devices. And even if you're able to, you don't need to. And given the absurdly slow code in gradient for software32 that relies on sin/cos/whatever is not present in systems without FPU, we're talking about a dead end. If you ask me, I'd actually add an option to disable gradient build altogether to save space on embedded devices that will not use it. I guess this thread is pretty over, things went really out of control. People were arguing about ethumb and we ended fighting about stupid stuff. I still hope that Viktor did not give up on trying to come with Ethumb/plugins requirements, I'd really like to know what is missing so we can think, design and implement a good platform. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
