Thanks for the detailed answer... You told me what I did not find out in weeks :)... nevertheless:<br><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
if you are talking of directfb accelerated on top of glamo - good luck. last i<br>
checked it wasn't and you'd have something a LOT slower. </blockquote><div>No.. there is nothing... was thinking to write sthg. on top of Thomas White's:<br><br> <a href="http://www.bitwiz.org.uk/s/dri-for-the-freerunner.html">http://www.bitwiz.org.uk/s/dri-for-the-freerunner.html</a><br>
<br>drm/kms work. <br><br>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.<br>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. <br>
<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">the hardware there is
a dead end. sdl doesn't provide any acceleration itself anyway - sdl is a<br>
wrapper to get a dumb fb. evas's raw fb engine/support will be just as good, if<br>
not better. </blockquote><div>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.<br><br>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...<br>
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 channel.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
as such directfb is little-loved and not maintained. as and engine. sdl is<br>
being loved/used on the palm pre (webos) and it works there, so no idea what's<br>
up with you there, but they seem to be having some fine success.<br></blockquote><div><br>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 on it..<br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> The intention of my experience was to see if evas/ecore would behave better<br>
> on top of a potentially accelerated directfb backend. However as far I<br>
> understood from the code evas/ecore would have zero benefit from a 2d<br>
> accelerated directfb driver.<br></div></blockquote><div>Sorry.. what do you mean "as far as I understood" ... you did not write that part? <br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
</div>in theory they would - fact is directfb won't be accelerated. all the rendering<br>
is done by evas - ecore isn't involved there beyond providing events and<br>
mainloop. but dfb is not maintained and behind. as such it's very little used<br>
in real life and not worth the trouble. nothing dfb does can't be done in x11.<br></blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> My question is:<br>
><br>
> 1. as was reading on some other threads that one wants to get rid of<br>
> Xrender. Would however efl be able to use some 2d acceleration (blit from<br>
> videa ram to videa ram, draw/fill rectangle etc.)<br>
<br>
</div>useless when all the other ops are slow. waste of time and effort. i've been<br>
wasting and waiting for a decade. i've had enough of it. xrender engine is<br>
already partly broken as it doesn't support some of the modern things like map.<br>
note that on glamo xrender als is not accelerated and in fact is not able to be<br>
properly accelerated and you will have lots of software fallbacks doing<br>
read/modify/write across the anemic video bus to glamo. i've been here. long<br>
ago. i have the full glamo hw docs. i read them in entirety and made decisions<br>
off that. what you see in the checkbox list of features vs what glamo actually<br>
does makes you think again about it as a useful chip.<br>
<div class="im"><br></div></blockquote><div><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> 2. is there any "interface" to inject some 2d accelerated code into the fb<br>
> driver?<br>
<br>
</div>no. you do a new engine. eg fb-glamo. it will fail becauuse in the end you will<br>
create something very complex that is actually no faster. you will win on<br>
operation a and then lose on operation b. glamo's problem is its operations are<br>
asymmetric. you can use rgba as src - but never create rgba as a dest - only<br>
rgb565. pointless for intermediate buffers than now need fallbacks. also leads<br>
to cumulative rendering error when dropping down to rgb565 and quality will<br>
suffer badly.<br></blockquote><div><br>hm... did not know this issue with rgb565... You mean I cannot blit from an "unvisible" VRAM area to the "visible" one? <br>The idea was, when scrolling (like when moving maps) to redraw only new parts, and the rest do by two copies inside the VRAM.<br>
<br>I wonder if there is sthg. similar implemented for scrolling in Xglamo..<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> For example the most annoying on openmoko freerunner is slow scrolling. For<br>
> example your map example becomes the same sluggish. This could be probably<br>
> solved by scrolling through a temp invisible video memory buffer.<br>
<br>
</div>the freerunner itself is slow - it's a very poor piece of hardware. </blockquote><div>We know that... And the most annoying is the scrolling when everything has to be redrawn, whereas only parts should be. <br>
Well.. in the worst case I will understand that it is impossible (hower it does not seem to be)..<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
scrolling in efl is a redraw. why? because doing otherwise is nuts - especially<br>
if you want to support things like opengl. also in the need when people want<br>
their translucent list items with static bg's etc. - you do redraws anyway. you<br>
can cut out some redraw with intermediate buffers - but then you pay a price in<br>
memory usage. </blockquote><div>in memory usage of RAM or VRAM?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">you can do this via map... but.. gasp.. that needs an<br>
intermediate buffer and... glammo cant generate those other than in software.<br><div class="im"></div></blockquote><div>what do you mean "other than in software"<br><br>I think with drm/dri it can be done ..<br>
<br> </div>
</div><br><br clear="all"><br>-- <br>rgrds,<br>mobi phil<br><br>being mobile, but including technology<br><a href="http://mobiphil.com">http://mobiphil.com</a><br>