Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
Carsten Haitzler (The Rasterman)
raster at rasterman.com
Tue Nov 18 23:06:09 CET 2008
On Tue, 18 Nov 2008 15:01:51 +0100 "Nicola Mfb" <nicola.mfb at gmail.com> babbled:
> 2008/11/17 The Rasterman Carsten Haitzler <raster at rasterman.com>
> > [...]
> no - it's not possible to do a "scroll" (via blit) as you have
> > alpha channels, layered objects etc. etc. - just trust me in that the cost
> > of
> > trying to figure out a blit - if it is possible is probably much higher
> > than
> > the cost of just doing a redraw in almost all cases - the upload speed of
> > the
> > glamo is so low though that it may just be worth it...
> I understand and trust your huge experience :), so correct me where wrong,
> I'm not expert but I'd like to have an high level view on this:
> *) standard toolkit do complex operation so it's simple/better recompute and
> upload the view, this means that porting existing software based on them may
> result in slow performance.
it depends. its a tradeoff of flexibility and power to change the look and feel
of things vs cost.
> *) toolkits that advantages of OpenGL to accelerate its widgets (for example
> Qt let you choose an opengl viewport for their canvas implementation) does
> not advantage as Glamo has only 2d acceleration.
evas supports opengl too. no it doesn't have an advantage, as glamo won't be
doing opengl at VGA (the resolution of the device) so you won't be doing it for
normal 2D UI's (thus my comments of it being of limited use for some fullscreen
games for example where you drop to QVGA for the game). also the 256x256 max
texture size leads to problems even if it could do VGA output. you'd need to
now do texture meshes - and these are nasty if you want scaling to work right
(with interpolation and/or mipmaps, anisotropic filtering etc. etc. - in the
more general case).
> *) when necessary you can use directly Xlib because X is 2d accelerated ?
you ALWAYS use xlib* - if you want to interact with x in any way.
(* or xcb... or write your own x protocol but same - both are x protocol wrapper
> *) when necessary you may use lowlevel library/toolkit to bypass X overhead
> and use accelerated 2d graphics (sdl?) ?
sdl offers screen setup - not acceleration (really - ok for some specific
things it wraps that too - but not in general). sdl USES x. same as anyone else
(i am ignoring using sdl on the framebuffer - that's no different to using the
> *) about video streams, bandwidth is not an issue if decoding mpeg4 in
> glamo, but is a issue if you decode the stream with the main CPU and upload
> the frames to the glamo?
yes. it's an issue in this case. decoding mpeg4 on glamo is problematic due to
audio not being decoded on the glamo and having to synchronise. all uploads to
video block the cpu so you have no cycles to decode the next frame while
uploading the current one (slowly). same with ANY pixel uploads.
> *) glamo will be abandoned, the cost to develop a 3d driver is very high,
> what's about completing 2d acceleration and mpeg4 hardware decoding?
imho it'd dubiously useful - sure. it works. the audio issues, synchronisation,
there being no standard x extension/mechanism to upload codec data (having to
invent one - this is though a very worthy idea) etc.
> *) the community may produce now or at later time the wanted 3d driver, but
> this is hard as openmoko has to extend the nda in some legal way
om can't. unless you work for om. smedia control the nda - not om.
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
More information about the community