On Wed, 16 Jan 2013 17:16:55 -0200 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> On Wed, Jan 16, 2013 at 4:39 PM, David Seikel <onef...@gmail.com> wrote: > > On Wed, 16 Jan 2013 16:24:44 -0200 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> wrote: > > > >> On Wed, Jan 16, 2013 at 4:12 PM, Ross Vandegrift <r...@kallisti.us> > >> wrote: > >> > On 01/13/2013 10:38 PM, Carsten Haitzler (The Rasterman) wrote: > >> >> On Sun, 13 Jan 2013 22:26:11 -0500 Ross Vandegrift > >> >> <r...@kallisti.us> said: > >> >>> Yep - enabling compositing fixes that issue. ARGB was enabled. > >> >> > >> >> theme designed to work well on compositing. non-compositing ymmv. > >> >> for e18 we are going compositing only.. in fact e17 in svn already > >> >> is there... so not something that is going to change :) > >> > > >> > And as usual, compositing proves its worth. Just started up > >> > VirtualBox, whole desktop ground down to about 2fps. Took about > >> > three minutes to flip to another virtual console to kill it. As > >> > soon as I unloaded the module, all better. > >> > > >> > Maybe someday before compositing is mandatory for every window > >> > manager, composite will get fixed to not break lots of working > >> > installations. > >> > >> Really? I'm using E17 exclusively inside VirtualBox on a MacOSX host, > >> 1024x768 and with composite. Works pretty fast on a MacBook Pro 2.8 > >> GHz Intel Core i7 with NVIDIA GeForce GT 330M 512 MB. > > > > I think Ross meant VirtualBox is running inside E17, not the other way > > around. I wonder if he's using OpenGL or software for the compositor? > > And maybe VirtualBox trying to use OpenGL caused a conflict? > > > > For what it's worth, I regularly test my embedded EFL stuff inside Qemu > > running on top of E17 with no problem. It does not need OpenGL or > > anything fancy though. > > > > And just to offset Gustavo's bragging, my embedded EFL project runs > > pretty fast on the actual x486 CPU with some crappy built in graphics > > chip, and 256MB memory shared between them. :-P > > last but not least, now that comp is mandatory it should be > rewritten/improved to be better, make "no composite fullscreen > windows" work properly and etc. > > I've read the code and it's huge and seems to be the "learn as I > write" kind of stuff. Now that people know it, the Composite extension > and pitfalls, it would be better to rewrite the whole thing and assume > the "always composite" path, linking it with e_border that used to > draw the decoration. it was written around needing to plug into an existing wm and x core. it also required learning how comp works and needed to turn on and off. fyi the no-comp thing i think is right. the problem is in an x11 world thats an evilly complex path involving many driver and x layers, wm, compositor and client. simple timing and sloppy code can kill it, but its currently pretty brute-force... it literally hides the composite window and turns off comp on every window (and unrefs all comp pixmaps etc.). and does the reverse when nocomp disables (go back to compositing). the evil bits of comp are that it listens not just to basic x events but also e border events and pokes inside of structs matching them up to x ids etc. and this is pretty unclean and something that comp-in-core can fix up as we make a comp evas object a first class citizen (base) for everything else... now it goes kind-of in reverse... we do everything in the comp canvas by default "primarily" and then glue in external resources we can't/don't control (client window id's mapped to image objects, override-redirect windows mapped to image objects). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
