[E-devel] X11 dependencies hardcoded in ecore_evas
mobi at mobiphil.com
Sun Apr 18 03:05:24 CEST 2010
Thanks for the detailed answer... You told me what I did not find out in
weeks :)... nevertheless:
if you are talking of directfb accelerated on top of glamo - good luck. last
> checked it wasn't and you'd have something a LOT slower.
No.. there is nothing... was thinking to write sthg. on top of Thomas
My main point was to have sthg. that is common to both X world, and fb (Qt,
non-X elf etc, other lightweight fb apps), the lowest c. denominator.
And that could have been directfb, but I am more convinced that not. One of
usage of this c. denominator would have been to have a "global" keyboard,
that would cold be rendered on top of any application. "taping" the
rendering engine, probably would have been easy.
> 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.
in this situation, I admit, no point to have nor directfb nor sdl. Just a
broken illusion, that efl on top of directfb would make things faster.
But I can draw very fast the conclusion that in case of glamo, running
illume and other apps, there is no point to have X windows...
I wonder if anybody from the openmoko community can confirm that efl would
be faster with accelerated X, what I doubt... probably the opposite, at
least what concerns loading times, as less binary has to cross the narrow
> 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
> up with you there, but they seem to be having some fine success.
Honestly I just discovered, that you guys do a superset of directfb
features. And directfb did not evolve the last 4-5 years since I keep an eye
> > The intention of my experience was to see if evas/ecore would behave
> > 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.
Sorry.. what do you mean "as far as I understood" ... you did not write that
> in theory they would - fact is directfb won't be accelerated. all the
> 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
> in real life and not worth the trouble. nothing dfb does can't be done in
> > 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
> 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
> 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.
> ago. i have the full glamo hw docs. i read them in entirety and made
> off that. what you see in the checkbox list of features vs what glamo
> does makes you think again about it as a useful chip.
> > 2. is there any "interface" to inject some 2d accelerated code into the
> > driver?
> no. you do a new engine. eg fb-glamo. it will fail becauuse in the end you
> 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
> asymmetric. you can use rgba as src - but never create rgba as a dest -
> rgb565. pointless for intermediate buffers than now need fallbacks. also
> to cumulative rendering error when dropping down to rgb565 and quality will
> suffer badly.
hm... did not know this issue with rgb565... You mean I cannot blit from an
"unvisible" VRAM area to the "visible" one?
The idea was, when scrolling (like when moving maps) to redraw only new
parts, and the rest do by two copies inside the VRAM.
I wonder if there is sthg. similar implemented for scrolling in Xglamo..
> For example the most annoying on openmoko freerunner is slow scrolling.
> > example your map example becomes the same sluggish. This could be
> > solved by scrolling through a temp invisible video memory buffer.
> the freerunner itself is slow - it's a very poor piece of hardware.
We know that... And the most annoying is the scrolling when everything has
to be redrawn, whereas only parts should be.
Well.. in the worst case I will understand that it is impossible (hower it
does not seem to be)..
scrolling in efl is a redraw. why? because doing otherwise is nuts -
> if you want to support things like opengl. also in the need when people
> their translucent list items with static bg's etc. - you do redraws anyway.
> can cut out some redraw with intermediate buffers - but then you pay a
> price in
> memory usage.
in memory usage of RAM or VRAM?
> you can do this via map... but.. gasp.. that needs an
> intermediate buffer and... glammo cant generate those other than in
what do you mean "other than in software"
I think with drm/dri it can be done ..
being mobile, but including technology
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the community