Fwd: Glamo secrets, acceleration, X11, directfb, was: [E-devel] X11 dependencies hardcoded in ecore_evas

[Carsten Haitzler (The Rasterman)]

On Sun, 18 Apr 2010 13:38:11 +0200 mobi phil <mobi at mobiphil.com> said:

> did not "reply to all" ... so here is the forward maybe it is of interest
> for someone else...

better :)

> Changed the topic name....
> 
> Thanks for your time for helping clarifying the mistery

np.

>  > 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.
> >
> > dfb isnt common to fb and x11 - it is an enitre display system of its own.
> > there is a specific xdirectfb server on top of dfb. but it is not a common
> > component. i think you misunderstand directfb... :) \
> 
> No!!! I do not misunderstand... Yourself you said the same... Indeed there
> is a simple xdirectfb on top of dfb. So If everybody, Qt based apps (QtMoko)
> and X would talk to directfb, then directfb would be an almost perfect
> lowest common denominator.

so... if xdfb was so great... why is it not the standard display server for
linux? :) directfb was a solution to set top box hardware. it hasn't seemed to
remain competitive with x - for a long time it was very interesting, but it
just never caught on. xdfb was a compatibility layer - your overhead will go up
compared to regular x - just by a little, but it will.

> > but - you'd need all the acceleration written and even then the chip simply
> > is not capable of many ops
> > you need or it makes them needlessly complex (you will need to go via the
> > 3d
> > unit and that limits all pixel primitives to 256x256 as a source and output
> > cant be more than 512x512 for any buffer - you'd need to do complex tiling
> > of
> > all input and output and that will wreak havoc on things like
> > transforms/scaling to make it look right - and effectively make it
> > impossible).
> 
> Why would I go through the 3d unit? Again... I have limited info, but what
> is the most important is to have at least the

because your 2d unit cant do all the things you need - as you are hunting for
units that can do the work you need. you can pretty much choose to use the 3d
unit to do 2d work - or use the 2d parts. sometimes you can create a bastard
frankenstein combo of them. but you have a 3d unit and a 2d accel unit. i know
the 2d accel unit better than the 3d one (the 3d docs were fairly sparse).

so you either try do it with the 2d unit - and then fall back to software to
make up for missed operations more often (see later on), or... you try and do
as many ops all in hardware (much better) but create rediculous complexity to
work around even more restrictive limits.

> > trust me - have full hw docs. had them from the day i started with glamo
> > long
> > before gta02 came out. after some reading i went from excited to
> > despondent.
> > glamo does not live up to what it seems to appear reading its checklist
> > features. sure - it's possible to go accelerate some things and get some
> > benefit.
> 
> If one would get the first 80% (that is for me scrolling and maybe huge fill
> rects), then I think it would be a huge step, or?

scrolling == redraw. you can't just copy pixels when you scroll in efl - those
pixels may be on top of a background (they are transparent/translucent) that
doesn't move. that means you NEEED to redraw. in fact thats how all things in
evas work - they can be blended, layered etc. - even text - something as simple
as that has an alpha channel. and parts of your text are semi-transparent. you
cannot just "copy pixels in the framebufffer and redraws the newly exposed
things". that is an old model of redraw. its the 1980's and 1990's model. it's
NOT the model you use in this millenium - or you shouldn't. it's simply not
where hardware is going. hardware  is going - nor ui design and application
requirements. as such games have done the redraw model for a VERY long time.
the rest of the 2d ui world is moving that way. efl is designed to be there
already. it has redraw minimisation, but it's still redraw.

you CANNOT scroll something that has an alpha channel by just copying pixels in
the fb up and redrawing the new bits. it simply is impossible. it creates
artifacts and the backgrounds also shifts with the pixels. it ALSO creates
redraw artifacts where you copy that then wait for the new pixels to be drawn,
having "flickery" displays that "catch up" to the user. it also means you have
zero hope to ever have tear-free synchronous drawing as you are blitting around
in the front buffer as opposed to rendering new frames/updates in a backbuffer.

> for each of those you now have a downside as u need a software
> > fallback for the ones you can't - and... those now get more complex WITH
> > more
> > overhead. you make operation a 2x faster and operation b gets half the
> > speed.
> >
> Why would op. be get half speed? Unless we are talking about concrete
> example, would be difficult to argue.

take your desktop pc. write data to vieo ram - memcpy() go for it.. now memcpy
() it back... time the operations. go for it... try. :) notice the memcpy back
is something like 10-100 TIMES slower than the write. read up on video buses.
but... thats a desktop. glamo - you also have a video bus - and it is anemic.
last time i timed it i got 7m/s write rates - i didn't time read rates. you
will spend cpu cycles in waitstates waiting on the glamo bus to "catch up" and
thus - create software fallbacks that run slower than they would in system ram
doing the same thing as they now get hobbled by "waiting on the glamo bus". not
to mention your fallbacks will, unless you rewrite them, be from pixman - and
that won't make them awfully fast ones either. :)

> > and so on. my bet is that even if you do it all as optimally as possible
> > with
> > glamo+gta02 arch - you will have spent a mountain of effort going nowhere.
> > ie
> > not be able better in general. some things improved, some worse. and now
> > you
> > have a monster of complexity that has no future. glamo is a dead end chip.
> 
> openmoko a dead end product line. a source base that will not be useful for
> > any
> > future hardware developed nor even todays hardware.
> 
> Not dead end for me and others who bought it. I think 99% people on the list
> have more interest to improve/hack as potentiality, not as commercial
> intention etc.

you cross-posted to e-devel. so you are talking to a large group of people who
care very little about your hardware. :) what you are doing is wasting time.
wasting your time and wasting my time - and other peoples time. my time is
precious. i have very little spare, i am actually totally time-poor. i spend my
time on things that will have long term major benefits. glamo is far off my
list of things to spend any time on. dead end. and unless you are a student or
unemployed - who has pretty much limitless time of very little value, then
spending your time on glamo will also be a waste... but - if you want to - go
for it. but listen to me when i tell you why things are as they are and that
i've many years of experience under my belt and an insight greater than yours
into the glamo, and a much better one into efl and why it does what it does.

> the future is mostly
> > opengl-es2 based with the ability to punt off preparation pipeline stages
> > to
> > multiple cpu cores - or if you are lucky, some dsp cores. as such even
> > without
> > this punting off to multiple cores, with gl-es2 - things work damned well -
> > silky smooth on a modern soc. thats including rendering everything at
> > 32bpp,
> > compositor in x11, and more.
> >
> That is also true... unless I spend another few bucks, I will not get
> another hardware...

correct.  the entire device industry is built around you spending money every
1, 2 or 3 years on a new device. if you choose not to do so - you will quickly
get left behind in the dust. it would have been awesome if openmoko continued
and made a gta03, gta04, gta05 etc. that would continue a line of devices and
offer openness and products - but they didn't. you will have to jump ship
sooner or later.

> > > 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 disagree. how do u think you get a vkbd up on screen separate to the app,
> > or
> > the top-shelf (place for app name, battery, reception etc.) ?
> 
> There are ways... directfb has also multi app mode and basic window manager.

at which point you have re-implemented windows in x11.

> The vkbd as I mentioned would be a completely different story. The magic
> idea (and this could apply even in the future for opengl stories) is to
> capture any "paint" access to the video, and as final step redraw the (full
> screen transparent) keyboard on top of it with a given alpha.

it's called compositing - in x11. xcomposite, xdamage combined handle this. a
composite manager does the actual nuts and bolts of putting the display
together. interestingly enough e17 has a composite manager (module) - comp. it
has a full software path and opengl path too. software for glamo will work,
but suffer horribly. gl simply isnt possible on glamo thanks to the limits of
its 3d unit.

> > i think you are
> > under the illusion also that somehow windows have some massive overhead in
> > x11
> > - they don't - they are simply clipping regions for doing draws - that go
> > to
> > the framebuffer (with compositing - different story with redirection but
> > you
> > end up producing the same design no matter the display system).
> > clip regions are just a list of rectangles "only draw within this region"
> > when
> > drawing. you ask x11 to do the drawing to the fb for you to make sure all
> > of
> > this is co-ordinated and the clip regions obeyed. x11 is also asynchronous
> > and
> > buffers so its NOT:
> 
> draw thing, wait for x, x sends "draw done",...
> draw next thing, wait for x, x sends "draw done"...
> 
> I know about X arguments. However I was reading even on efl homepage
> somewhere the argument that efl apps on fb are much faster than on X

where? *MUCH* faster? ahhahahahahahahahahhahahahahahahhahahahahahaha rotfl.
give me numbers. you will find that fb gets a small speedup as evas can combine
a copy and convert stage as opposed to making it 2 stages. this is for 16bpp.
for 32bpp (which glamo can't do - but modern devices can) there is zero
overhead - its the same oprations, just done via shm segments and ipc to x as
oppsoed to a memcpy. no extra copieds and no converts. thhere is a very small
bit of overhead in some context switches and x protocol requests - you will
pay that kind of price with dfb anyway with locks and ipc too. in the 16bpp fb
path yes - copy and convert is combined (for the 32bpp engine) but most of your
work is doing the actual rendering of the buffer, not the copy +convert (unless
all u are doing is drawing solid color rects).

> windows. On the other side, as mentioned in my prev emails, loading X and
> apps adds to slowness due to a little fat libraries.

i seriously doubt this. show me numbers. x libs have very few symbols and are
generally small libraries. the only thing you have a point with is they connect
to x and talk back and fort a bit on setup - with dfb in the end you will
re-create the same overheads in the end and just have spent a lot of time going
nowhere.

> > that'd be stupid. you CAN write code that works like that with x11 - but
> > then
> > i'd shoot you to save the world a little more oxygen as you'd be using up
> > too
> > much of it. :) (joking! but you would be stupid) :)
> >
> > in x11 (with efl) it's like this:
> >
> > prepare stuff locally, send draw, send draw, send draw, prepare locally,
> > send draw, send draw, send draw, .... frame finished
> >
> > at frame finish it waits for x (to syncronise and make sure app doesnt go
> > and
> > queue many frames ahead of what x has managed to draw/copy to the screen).
> > all
> > those prepare/send happens in the app without context switching to x11 -
> > there
> > is no overhead compared to anything fb oriented.
> >
> 
> Well as far as I know direcfb does the same... draw draw draw (internally
> clipp if necessary) and then Flip.

then why is x so much worse? :) explain. :)  i am harsh on you for all this
dfb stuff because i have seen this same kind of arguing countless times over
my years with no numbers or actual proof (or numbers based on fallacies - ie
based on a badly written x11 app/toolkit etc.)- and i have spent my years
proving the opposite - that x11 is capable and fast - and that is what efl
does, so it;s on your head to prove me wrong ad i've spent my efforts in
proving myself right for many years - yes x11 has overhead. its relatively
small, and the gain is a LOT of compatibility and standards - that's worth the
very small cost. when there is actual bad x11 overhead it is generally isolated
and  i can happily commiserate with you over it - i know a few sore spots,  but
they are few. if it becomes such a major issue - x11 can be fixed and extended
- there is no need to go work with completely new display systems. that's like
dropping a nuke on the louvre because you don't like the mona lisa. so don't
get me wrong - i'm just being harsh because i just want you to avoid wasting
time on what is a view of things based on lack of information. i actually can't
spend my days educating people - i don't have the time for it. otherwise i
should start some school and charge for lessons :) maybe one day i'll write a
book, or do such a thing, but i'm not there now.

> > > 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.
> >
> > in theory xrender could accel some things, but it'd lose on others. as i
> > said -
> > i gave up on xrender - on desktop it's a waste of time. the only thins
> > worth
> > bothering with these days are:
> >
> I wonder what could xrender accelerate if you do not give it the oportunity.
> Maybe you should know based on the code if any oportunity is given. But
> probably not. If a new frame is prepared each time, I do not think that
> Xrender would do any delta to send only deltas etc...

xrender CAN accelerate a lot of what evas needs, but.. evs is now pushing where
xrender won't be able to go - soon. but i cave up because no xrender
implementation can match opengl. it SHOULD match opengl in performance at
least. most xrender driver backend barely scrap by equalling evas's software -
and in most cases perform much worse. i gave up.  xrender just performs too
poorly due to drivers. it can - technically, but doesn't and i'm not going to
go around fixing everyone's drivers, finding docs, and more - i have too much
to do already. opengl does the job - much better than xrender, and is there
now. that saves me time. 

as for xrender doign deltas - thats' not xrender's job - evas does that. and it
does do deltas in all non-gl engines. gl means a full window redraw (i can go
into why, but i won't). sftware and xrender engines redraw the CHANGED regions
of the screen those that don't change - don't redraw, but any change == redraw,
thus what to you is a scroll is a change - thus a redraw of the region you
scrolled. to evs you didn't scroll - you moved a bunch of text, image, rect
etc. objects around that make up a list (for example).

> > 1. software (use cpu - or multiple cpu cores - i include dsp's and other
> > such
> > things here if you can specifically write code that they run to
> > prepare/munge/calculate data).
> >
> Do not necessarily agree. Again... do not know too much about glamo. But,

i'm talking "these days" - that's a general statement. not glamo specific. for
glamo you have nastier limitations.

> again let's take the already mentioned example with scrolling. Given that
> scrolling adds some 5% of new info and removes 5%. Why would you prepare the
> full 100% of the frame and send it to any VRAM (lets not talk only about
> glame), when it would be just two memory copies in VRAM (done with 2d
> commands). I can bet that on devices like iPhone scrolling is implemented
> like that.

redraw == redraw changed region - and that is the scrolled one - see above. you
CANT copy - it's incorrect to do if your objects are not a big region - they
are separate specific objects with alpha (text) etc. etc.  - you can't do it.
you also create tearing and other render artifacts - see my previous comments.

and no - iphone doesn't do what you think. it's a composited rendering
environment. what it has is 1/2 the pixels to deal with compared to gtao02 AND
about 3x the processing power, NO piddly video bus (all gfx happen in system
memory) AND it has a decent 3d unit to use (mbx - no not as good as sgx but
beats the glamo hands down by having decent texture resolution support etc.).

> > 2. use opengl(-es). if you want shaders thats opengl-es2. and yes - you do
> > want
> > them. this means closed binary drivers n all cases these days. glamo is not
> > capable of gl-es2 - gl-es1.1 which is shader-free. glamo also is very
> > limited
> > in its gl features - like 256x256 max texture size, 512x512 max render/3d
> > buffer (thus u cant even to 640x480 in 3d - vga is already pushing the
> > limits
> > of glamo.if you look at it it was designed for qvga - maaaaaybe hvga at a
> > stretch - vga was just a "well lcd controller can do it - lets say we can
> > do it
> > to look good on spec sheets". it's like saying that your vw beetle can pull
> > a
> > semi-trailer - sure, on a flat smooth road, in 1st gear only, at 2 km/h -
> > but
> > it "can do it".
> >
> I was convinced about blown up spec sheets from the first day I had the
> device in my hands. I started a thread on openmoko with sthg. "glamo is
> slow, is that a bad joke?"
> Honestly, personally I have 0 interest in 3d. I need decent 2d especially
> for maps and reading some basic text.

3d can be used for 2d. see evas's gl enigne - same rendering, just done with
gl. fact is that all the effort to make thins fast is going into 3d units, not
2d, so to piggyback all that work to make games fast (and games do redraws),
you want to use the 3d unit, but the glamo is special. it's 3d is very hobbled
and useless for 2d (imho).

> > > > 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.
> > >
> > > 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..
> >
> > correct. :) dfb came and well - went. there was excitement over it - but it
> > never got anywhere. it's a dead end unfortunately and so the engine gets no
> > love. nothing dfb does that x11 can't do these days - and then some.
> >
> > > > > 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.
> > > >
> > > Sorry.. what do you mean "as far as I understood" ... you did not write
> > that
> > > part?
> 
> > you wrote that one. you'll have to ask yourself that question :):):)
> >
> :) ... sorry.... with all this quote the quote the quote:)
> 
> >
> > > hm... did not know this issue with rgb565... You mean I cannot blit from
> > an
> > > "unvisible" VRAM area to the "visible" one?
> >
> > you can - but there are limits on the source and destination formats. and
> > formats directly have vvisiblee implications - eg NO alpha channel, or 1
> > bit
> > onoff alpha - or rgb4444 (4 bits for r, g, b and a only) and so on.
> >
> Personally would be happy with less colors, but smoother ops. But... hm...
> few months ago was playing with some commands. Was drawing rectangles in
> random position with different flags. I had the impression that something
> more than on/off alpha was happeinnig... hm.. will redo that

dunno. depends precisely what you were doing.

> > > 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..
> >
> > not possible in the efl world. evas is designed to work with modern gpu
> > architectures - and that means redraws due to alpha channels and just
> > general
> > gpu design (as games dont blit. they redraw the whole screen every frame so
> > gpu's are optimised for redraws). the scrolling you think of is a subset of
> > what evas actually does. in the end it just does a redraw as that covers
> > all
> > cases.
> >
> Well, I believe you ... but after looking deeper into gui/drawing patterns,
> was a bit dissapointed.
> 
> 
> >
> > not in efl design - doing what you want creates limitations - and those
> > limitations then perform poorly on other modern rendering mechanisms - thus
> > in
> > return for making a a poor bit of hw a little better - you screw yourself
> > for
> > the future. all the toolkits have had to change their ways and move to a
> > "redraw things" model to work with gpu's and modern requirements. efl just
> > started there from its design and thus can be 100% gpu accelerated as its
> > design is in-step with how gpu's work. the software enigne has an optimised
> > redraw path too - and it tries to limit redraws where it can. but you can't
> > just blit as that doesn't work if your drawing model is more powerful -
> > like
> > having alpha channels etc. yes - you can go on about not wanting/needing
> > them
> > and being a waste of resources - if thats all you care about then efl is
> > not
> > for you. you can do your apps in raw xlib - or gtk if you like, but you
> > will
> > hit their limits eventually, but.. that assumes you will move off the
> > freerunner eventually to some hardware that is vaguely modern.. but then
> > you
> > will have painted yourself into a corner and want all the features efl has
> > offered for years and need to redo everything anyway... so more work.
> >
> > time is money - and i am very short on time. hardware is cheap and easy to
> > come
> > by - compared to time. the time to invest in things lime freerunenr (glamo
> > +s3c2442 etc.) is simply not worth it as that kind of model is a dead-end.
> >
> well after all I agree...
> 
> 
> >
> > > 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.
> > >
> > > in memory usage of RAM or VRAM?
> >
> > wherever the buffers are stored. depends on the rendering subsystem.
> >
> 
> 
> 
> >  > > you can do this via map... but.. gasp.. that needs an
> > > > intermediate buffer and... glammo cant generate those other than in
> > > > software.
> > > >
> > > what do you mean "other than in software"
> >
> > there is no silicon on glamo to do it. i'm now talking 2d.
> >
> still did not understand this. I will quote again your original text:
> 
> 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.
> 
> You have 8MB (if remember well) of VRAM. We have enough for intermediate
> buffers, or? Whoever (opengl) was drawing, we move the 90% and let opengl
> repaint the rest..

that 8mb includes frameuffer (600k) plus buffers for sdio, all textures/pixmaps
if you want them accelerated, etc. etc. - evas can use such intermediiate
buffers. evas_map does that - but you will be limited by the acceleration
mechanisms - and glamo cannnot RENDER such a buffer. you can only render with
the cpu and upload. glamo cannot WRITE to argb32. it can only WRITE to rgb565
(it can READ agb32).

but... with using opengl (3d unit) on glamo this buffer can only be 256x256 at
best - and your output is still limited to 512x512 - so you can't even draw to
the full screen. unless its in multiple passes. already a waste. and no
"leaving blank bits" is just stupid. it crates horrible gotchas for generic
abstractions. the glamo is being run at a resolution its not really intended to
work with. drop to qvga and you'll be better off. it's bad hardware choices.

> > > I think with drm/dri it can be done ..
> >
> > drm/dri cant do anything - they are simply interfaces to get access to the
> > gpu
> > hw - get memory management sorted and access to the registters or
> > cmd-queue.
> > the actual gpu is not covered by dri/drm.
> >
> "can be done" I mean to have access to the full VRAM (or more than the
> /dev/fb0). -- well I am still focusing on scrolling --

if you use efl - scrolling is a redraw. you can only make redraws faster.

> > glamo has a 2d subsystem. it has a 3d one. the 2d one has a max size of
> > 640x640
> > for any source or destination buffer. this is already close to useless as
> > yes -
> > images and buffers do extend beyond 640x640 - this means you need to create
> > a
> > tiling architecture for all pixmaps etc. and source/dest
> > buffers/primitives.
> > hooray. the 2d engine can handle argb32 as a source format - but not as a
> > destination. this is the ACTUAL chip - the transistors. the silicon. it
> > CANT do
> > it. so - you need to use software to render to argb32 buffers as glamo
> > can't.
> >
> I will need to read more... Probably I have a simplistic idea about several
> things... Maybe you could "share in secret" all those documents you were
> talking about... It is easy to be king of the castle if you have the wisdom
> in your hands :)

no can do. NDA's. i can't share those docs. i was (and am still) allowed to
talk about them - but i can't share the docs. not my decision. talk to smedia
about that one.

> What I thought was that you have the "visible area" (the one thatmaps to
> lcd) and rest invisible, where you could store/do whatever you want. So you
> have 16 bit depth (I even do not know why we are talking about 32 bits)

because evas renders in 32bit internally. all data (images etc.) are 32bit.
there is a special 16bit enigne that works in 16bpp internally but it suffers
quality-wise pretty badly and is now woefully incomplete. to have an alpha
channel at all you need space - and the simplest and most logical way without
compromising quality is to use 4 bytes (argb32) per pixel. this also simplifies
the engine internals and allows more fast paths to exist and actually be used.
if you have a matrix of N colorspaces/formats you support it gets exponentially
more complex and thus less likely to be optimised.

> areas. The visible area is 480*640*2 bytes lets call it A. And for the
> invisible one we allocate again 480*640*2, we call it B. So what you say
> that we cannot just copy with 2d engine A to B ?

now you are talking a world that is utterly diverged from evas - its much lower
level and specific to your hardware. as such what you are talking about is you
create a 640x480 pixmap and xcopyarea to the window on screen. that does what
you want (assuming x actually uses video memory for pixmaps and not system
memory - but thats a driver issue).

> Let's assume that this works.... But... Well.. for scrolling I have oversee
> a little detail. copying from A to B+ y*480*2 can do simply the scrolling
> down /up, but hm... not scrolling left right... Baffffffff!!! that means I
> would need to send almost 640*2 commands to the engine to move each line "a
> bit left" or " a bit right"...

evas redraws. because that thing u think u are scrolling can - and is on top of
a static background. and.. you can see through it. thus it means:

create scratch space for updated region (lets say u scroll a list that is part
of the screen: 400x480

1. copy "background image" into scratch space
2. "red source" for each list item background, blend on top at right position
in scratch buffer
3. draw text labels (blend) in their right positions
4. now copy scratch buffer to right location on screen
5. free scratch buffer

repeat. the xrender engine does ALL of this via xrender requests to x11 - if
you can implement all of this in hardware - then you will do well. problem
is... you can't. thus all my other comments. the gl engine does all of this via
drawing triangles with textures etc. - and it doesn use scratch space. it uses
full gl buffers and bufferswaps, but same otherwise. software enigne does this
all with the cpu and the "cop scratch buffer to right location on screen" is
the upload to video ram.

you can't just copy the front buffer around - nor can you just copy from back
to front buffer. you have alpha.

> > the simplest way to deal with the 640x640 limit is to use software instead
> > of
> > any hardware for source or dest buffers bigger than 640 in any dimension.
> > ho.
> > did i mention you will need to migrate these buffer (copy) in and out of
> > video
> > ram? hardware can't work on them if they are not in vram - and software
> > will
> > take a big speed hit if it works on them directly in vram - so copying out
> > first is good if you then will do lots of work on the buffers, but copying
> > is a
> > cost. software engine (100% software) can get away with 0 copies until
> > final
> > display of buffer. in some hybrid some accelerated, some not driver you
> > will be
> > copying around often during draws and the overhead of all of this - or of
> > software directly working in vram trying to not copy, will negate any gains
> > you
> > make by using glamo to accelerate some ops. you likely will come out slower
> > even.
> >
> 
> well... I started to "feel" the full picture...

:)

> > now there is the 3d unit - here it has more limitations 256x256 for any
> > texture - thus the above 640x640 tile limit but worse. you will hit this
> > one
> > almost instantly. then you need to do meshes. and thats a pain - also
> > suffers
> > quality-wise and complexity (and thus speed due to complexity overhead).
> > max
> > dest buuffer - 512x512 - also limited. cant even cover the screen. that
> > alone
> > is enough for me to say the 3d unit is useless for anyting other than
> > trinkety
> > little qvga 3d games with low resolution textures (where if you have a
> > TEXTURE
> > for a game you wrap around a model - you can afford to have it degrade to
> > lower
> > res - and display quality simply duffers with blurry textures, but this not
> > possible in 2d - you cant make such tradeoffs. howd you like your text to
> > be
> > blurry and buttons to be blurry/blocky blobs? due to the images being used
> > being dropped to 1/2 or 1/4 resolution etc. etc. - in 3d you have triangles
> > define the shapes and outlines of your primitives and textures simply add
> > "skin". in 2d - not so. and the 3d unit n the glamo is at best useful for
> > such
> > simple 3d game-lets and tasks, nothing vaguely serious. it's interesting
> > that
> > 2d actually is relatively demanding on 3d units mostly due to it not being
> > able
> > to make such quality tradeoffs very often.
> >
> >  ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler)    raster at rasterman.com
> >
> >
> Spendito time ergo sum (" I spent time therefore I am " -- in very vulgar
> latin :) )
> 
> Well... thanks for all the clarifications... Well openmoko and glamo will
> remain a playground to learn how not to do things, with less chance to learn
> how to do :)

sure. if it's a playground - go play, but beware - your time will be wasted on
a dead architecture and working around stupid in the  limits. things like
256x256 textures when even the mbx in the iphone 2g offered 1024x1024 - and u
had only 320x480 to worry about. that was a SENSIBLE hardware design decision.
correct screen resolution given the grunt powering it and desired ui. the 3gs i
think offers 2048x2048 - and some more modern embedded gpus go even higher.
life is sane to go using gl there - and this is when evas's design decisions
really come to the fore - it works wonderfully as its 100% in-line with how
modern gpu's work. )

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