e in framebuffer?

[Carsten Haitzler (The Rasterman)]

On Wed, 29 Apr 2009 12:04:09 +0100 (BST) "Tilman Baumann" <tilman at baumann.name>
said:

> 
> c_c wrote:
> 
> >  The thought came from the fact that QTE seems faster. So, if X was
> > removed
> > from the equation - how would the freerunner perform?
> 
> I never felt a noticeable speed difference.
> 
> > with e providing a
> > reasonable
> > windowing environment,
> 
> Window management on plain framebuffer? Are you sure?
> I would be very interested in learning more about this.
> My expectation would be that you still need some fb multiplexer that needs
> to be relatively smart.
> Probably by rendering into a shared mem that gets composed to a fb frame
> by some central daemon.

and thus.. you will re-invent x. so... stick to x. dont try re-invent it. e
can't run in the fb. it's an x11 window manager. it's for x11. the gfx libs its
built on though can draw there.. and then you'd be in the "1 process in fb only
- that's it" land.. as you have no way to share it... create a way and you
re-invent x.

xglamo has nothnig to do with the speed. it's fine. the problem is 1. video mem
access bandwidth - simply uploading data is slow, 2. evas by default draws in
32bpp internally then converts and dithers to 16bpp. it has a pure 16bpp engine
- it's faster, but it also has a significant quality drop. personally its
enough to make me prefer slower over uglier. thus the default is to use the
32bpp (default generic software engine).

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com