[E-devel] X11 dependencies hardcoded in ecore_evas

[Carsten Haitzler (The Rasterman)]

On Sat, 17 Apr 2010 20:27:06 +0200 mobi phil <mobi at mobiphil.com> said:

> The target device of my experiments is the openmoko. For this reason I put
> the openmoko-dev list to cc, maybe somebody is interested there.
> 
> oddd. lossy uses libjpeg. BOTH use eet. eet uses jpeg compression for lossy
> > and
> > zlib for comp. there is also raw that doesnt compress at all.
> >
> > well.. then I do not understand why it crashes.... I use libjpeg.7 ..
> Anyway it is not the main point now. I changed to COMP and it works.

ess is there is something my guess odd in your build environment - i assume its
some sort of cross-compile setup. as suc openembedded builds a non-x11 efl as
native binaries to get to have edje_cc work. and it all worked last i looked.

> anyway ... my experiment was not really successful... support for sdl and
> directfb seems to be "broken" at elementary lib level... tried to add myself
> the different cases in elm_wind_add and brohters, but did not work, I found
> a a patch on a a thread here to make directfb working, but it did not.

if you are talking of directfb accelerated on top of glamo - good luck. last i
checked it wasn't and you'd have something a LOT slower. the hardware there is
a dead end. sdl doesn't provide any acceleration itself anyway - sdl is a
wrapper to get a dumb fb. evas's raw fb engine/support will be just as good, if
not better. for that matter if its sdl on x11 - evas's own software-x11 layer
will do much better. sdl doesnt offer anything here. opengl support for sdl
doesnt do anything accelerated either except set up and sdl buffer with a gl
context attached - all the acceleration comes from using opengl.

as such directfb is little-loved and not maintained. as and engine. sdl is
being loved/used on the palm pre (webos) and it works there, so no idea what's
up with you there, but they seem to be having some fine success.

> The intention of my experience was to see if evas/ecore would behave better
> on top of a potentially accelerated directfb backend. However as far I
> understood from the code evas/ecore would have zero benefit from a 2d
> accelerated directfb driver.

in theory they would - fact is directfb won't be accelerated. all the rendering
is done by evas - ecore isn't involved there beyond providing events and
mainloop. but dfb is not maintained and behind. as such it's very little used
in real life and not worth the trouble. nothing dfb does can't be done in x11.

> My question is:
> 
> 1. as  was reading on some other threads that one wants to get rid of
> Xrender. Would however efl be able to use some 2d acceleration (blit from
> videa ram to videa ram, draw/fill rectangle etc.)

useless when all the other ops are slow. waste of time and effort. i've been
wasting and waiting for a decade. i've had enough of it. xrender engine is
already partly broken as it doesn't support some of the modern things like map.
note that on glamo xrender als is not accelerated and in fact is not able to be
properly accelerated and you will have lots of software fallbacks doing
read/modify/write across the anemic video bus to glamo. i've been here. long
ago. i have the full glamo hw docs. i read them in entirety and made decisions
off that. what you see in the checkbox list of features vs what glamo actually
does makes you think again about it as a useful chip.

> 2. is there any "interface" to inject some 2d accelerated code into the fb
> driver?

no. you do a new engine. eg fb-glamo. it will fail becauuse in the end you will
create something very complex that is actually no faster. you will win on
operation a and then lose on operation b. glamo's problem is its operations are
asymmetric. you can use rgba as src - but never create rgba as a dest - only
rgb565. pointless for intermediate buffers than now need fallbacks. also leads
to cumulative rendering error when dropping down to rgb565 and quality will
suffer badly.

> For example the most annoying on openmoko freerunner is slow scrolling. For
> example your map example becomes the same sluggish. This could be probably
> solved by scrolling through a temp invisible video memory buffer.

the freerunner itself is slow - it's a very poor piece of hardware. it''s the
worst one i've ever working with in a decade. the original ipaq3660 i worked on
at the start of my embedded games was far better performance-wise. you can
polish a turd - but a turd is still a turd. all you will do is create a mess
that is simply not maintainable in the long run in the name of a broken bit of
hardware. been there. done that. :)

scrolling in efl is a redraw. why? because doing otherwise is nuts - especially
if you want to support things like opengl. also in the need when people want
their translucent list items with static bg's etc. - you do redraws anyway. you
can cut out some redraw with intermediate buffers - but then you pay a price in
memory usage. you can do this via map... but.. gasp.. that needs an
intermediate buffer and... glammo cant generate those other than in software.

> -- 
> rgrds,
> mobi phil
> 
> being mobile, but including technology
> http://mobiphil.com
> 


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