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. The return on their investment is a net negative, increasingly heavier and heavier over time. 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. 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. 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. > >> There's no loss and large gains in having evas support vgfx >> directly, as well as further filter and other gfx notions. It's >> not a problem at all. There is a bit of other stuff at the canvas >> level that needs redoing if one wants to support complex gfx >> operations on arbitrary objects, and some of the problems there >> are due to the way smart-objects were implemented at the canvas >> level. But again, there's nothing that can't be done, and done >> quite efficiently - far more so than most current gfx libs do. >> >> ____________________________________________________________ Save on Cell Phones. Click Now! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTKdW2FZI7qLYUPD6yeCfNG6sFTd78OBF257Jd8iAktxS9932VJls8/ ------------------------------------------------------------------------------ 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
