On Wed, 16 Jan 2013 17:16:55 -0200 Gustavo Sverzut Barbieri
> On Wed, Jan 16, 2013 at 4:39 PM, David Seikel <onefang@...> wrote:
> > On Wed, 16 Jan 2013 16:24:44 -0200 Gustavo Sverzut Barbieri
> > <barbieri@...> wrote:
> >> On Wed, Jan 16, 2013 at 4:12 PM, Ross Vandegrift <ross@...>
> >> wrote:
> >> > On 01/13/2013 10:38 PM, Carsten Haitzler (The Rasterman) wrote:
> >> >> On Sun, 13 Jan 2013 22:26:11 -0500 Ross Vandegrift
> >> >> <ross@...> 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
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...