On Sat 08 Nov 2003, Carsten Haitzler wrote: > On Fri, 7 Nov 2003 01:17:09 -0800 (PST) "Ben Rockwood" <[EMAIL PROTECTED]> > babbled: > > > Any thoughts on adding some ability to provide pseudo-trans to Edje? > > The nicest thing would be to use a statement in E image parts which > > instructed Edje to pull the bg and render it moved and clipped appropriately. > > Adding fx to that (tinting/etc) would be nifty but easily accomplished via > > a rect placed on top and alpha'd appropriately. > > > > Raster, I know you not hot on people using pseudo-trans and thus wouldn't > > be inclined to provide a dead simple method of doing it but right now I > > dont' see any clear method of doing pseudo via Edje since I can't > > manipulate an Edje image from code. > > > > So is anyone keen on the idea or should this stay a "do it in EVAS direct" > > thing? > > me for one will be saying "nup - NOT going into edje". for ONE it breaks the > model where now edje is dependant on X. no. the answer is NO. if you want this - > DIY. >
I certainly agree that inside of Edje is not the place to add such a hack. However, I would rather favor it as an image loader of sorts in Evas instead -- that seems to be much more logical. And since it is an ugly hack and has its problems, it should be optional, rather than compiled in by default -- and application developers will have to make sure that their apps look fine without the feature available. > people just don't appreciate how HORRID this system really is. and it doesnt > even give you real transparency even with the MASSIVE overhead of having 1 copy, True enough, but the demand for it is too high for us to ignore it. There should be some sort of compromise -- there is no doubt that this hack, while ugly, would be faster and more efficient than implementations in other projects (notably KDE). > 1 convert and a downgrading of image quality along the way i you dont run > 32/24bpp (as the pixmap is at screen depth). if you are @ 16bpp like many are > you end up with one image with reduced quality, dithered (or not) represented as > 32bpp aned then re-rendered back to 16bpp and re-ditherered making it even more > horrid. > > now every app needs to keep a copy of the 32bpp version of the entire root > background itself... and if it changes do it all again. > > its horrid. its nasty. its just plain WRONG (tm). wait until x has REAL > transparency. until then i'm not putting in such horrid hacks - ESPECIALLY not > in edje. it just breaks the model entirely. > It's going to be another aeon before X gets support for alpha masks and alpha color values. In the mean time, half a loaf is better than none. My proposal is -- make it optionally available (rather than a core functionality) so that whomever wants to use it can. It really wouldn't hurt that much, as long as it is not made a core feature such that the system would have to depend on it. Speaking of Edje, I liked Azundris' idea of the "transparency" keyword. The actual implementation of that should not be in Edje as Edje should never be tied diretly to the rendering backend (whether it be X11, FB or Qtopia). But Edje should be able to invoke the necessary functionality in Evas to effect that if necessary. For the mean time it will be an ugly hack, but in the future if and when X finally gets the ability, it can easily be changed. -- Ibukun Olumuyiwa http://xcomputerman.com "Wisdom is the principal thing; therefore get wisdom: and with all thy getting get understanding." - Proverbs 4:7 ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
