You seem to be taking this as a judgment on the quality of your work on your soft16 engines whereas if you stopped you'd realize that I'm addressing all rendering engines that use 16bpp data in their gfx pipeline. In this day and age, this is a disaster for anything that wants to grow towards building "richer" user interfaces.
Whatever these devices, they would ultimately be much better served with their software stacks/dev-frameworks investing in enabling 'richer' guis and optimizing things for their systems that can allow for such 'rich' graphical experiences. The benefits of something like the moderate speed gains from a 16bpp gfx pipeline is only seen when one imposes large restrictions on what can be done. If this also becomes a limiting or constraining factor in what your gui libs are allowed to support, then you have a serious problem brewing. According to you: "Evas is one example of such balance that I believe is good: it does not allow you to do everything, but the things that it allows you to do it does fast and it's very easy. If one want to do vector or direct pixel manipulation it's not the way to go.." If we buy into this logic, then evas is just perfectly balanced as is and doesn't need anything else.. Why then would I or anyone spend time developing anything further gfx wise? As for the rest of your tirade on gradients or me or whatnot.. I'll leave that up to you to have the final word. :) >>>>> .......... >>>>> >>>>> >>>> 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. > > ____________________________________________________________ Compete with the big boys. Click here to find products to benefit your business. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTI97zKj35EYpMbR3NLeVHPmf7v0RiFnuLqt4dX2v7IdRTXFytgoEY/ ------------------------------------------------------------------------------ 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
