Since I cannot update my proposal here is the revised one.
==About your project==
The project I would like to propose is to get XBMC, an award winning
media center software, running better on slower hardware found in
embedded systems. If the project would be successful it would allow
the community to build a small, cheap and open HTPC / media center
(Home theater PC - Wikipedia) based on XBMC and the
BeagleBoard.
XBMC have already been ported to ARM but runs at about 10fps on the
BeagleBoard. I believe there is room for improvements in this
department. To explain how I wish to accomplish this we first begin
with a little history.
XBMC was created for the Xbox gaming platform and designed in a game-
loop design. This means that the application renders the graphical
user interface from the ground up every single frame. This approach is
fine for a game were each frame is different and since the Xbox is
still rather powerful in terms of graphics it was not a big
limitation. Since most of the graphical user interface is built around
static elements this is very wasteful, especially on slower hardware.
The graphical library used by XBMC is made up by windows and dialogs,
both of these are populated by controls. A control can for example be
an image, text or button. There also exist a control, control-group,
which is a group of controls (classic composite pattern). The
graphical library is extremely flexible and everything can be defined
by the skinner.
The core problem with slower hardware is that it cannot render the
entire graphical interface in a decent frame rate hence it needs to
render less. My proposal to fix this is to firstly only render when
something needs to be redrawn, moving towards an event based rendering
system. This change will lower idle usage but is useless in itself
since even if some views are static a skinner can easily add a control
which is not static (scrolling text or animated image) and the
graphical library would need to render at full speed again. So to
lower the actual rendering overhead I would like to allow some of the
more advanced controls (say a text field or control group) to be
rendered once into a frame buffer, this frame buffer could then be
used instead of rendering the whole control when the rest of the
viewport needs rendering and would therefor lower the polygon count
drastically (each glyph is a quad). Finally since OpenGL supports to
only render into a specific region of the viewport I would also like
to make the graphical library able to leverage this. This would allow
to only clear a region which is likely to be in need of rendering and
then just render the selected region. Problematic part of this
technique is that it involves a great deal of processing to finalize
the region needed to be rendered since the graphical library is in 3D.
It has been suggested in the Beagle Board IRC to utilize OMAP3 for yuv-
rgb conversion which is currently done by a shader.
Since XBMC is mostly written in C/C++ that would be the core
programming language on this project. The libraries used would be
OpenGL ES.
Since my school system in Sweden continue throughout May the first
weeks (1-2) would be spent on profiling to finalize which of the
strategies would yield the biggest impact on the rendering speed, also
know how advanced the controls are needed to be before its beneficial
to pre render them. This point is vital since it gives an insight on
what to focus on during the next steps and it may be possible to begin
profiling earlier to give a chance to alter the focus.
Week 3 would be spent on general optimizations like smartly disable
blend on controls which does not need it, occlusion culling so the
graphical library don't render controls which have no possible impact
on the final viewport.
The following week (4-5) would be spent on refactor to allow the
solutions needed for Beagle Board to be possible. For example since
the graphical library calculate positions and render at the same time,
these needs to be separated to be able to calculate if the control
needs rendering. When the graphical library knows which controls are
needed to be rendered the move towards an event based rendering can
begin.
Week 6 would be spent on actually get the event based rendering
working, making other parts of the XBMC core able to issue a render
event when something have changed (input device pressed or a label
have changed).
Week 7 would be spent on adding a pre rendering stage accessible for
controls which can be used in render.
Week 8 would be spent on solving the dirty region problem, allowing
each control to have a transformation matrix so we can guess the
outcome of an added transformation. Here is also room for adding
frustum culling to not render and calculate controls which has no
possible impact on the final viewport.
Week 9 would be spent utilizing the OMAP overlay to remove the need
for yuv->rgb. This step should hopefully get lag free video playback
(SD content). This week could alternatively be spent on getting neon
up and running with ffmpeg.
Week 10 is pencil down and thus the bugg testing and documentation-
week begins.
I think I will be able to pull this off since I have been a member of
the development team of XBMC for over a year and can bring in the
knowledge of the rest of the team to help.
Also I have always been very interested and played alot with rendering
code and given that I know a great deal about XBMC code I think that I
would be a perfect candidate to making the needed optimizations of the
rendering.
==You and the community==
If the project succeeds it would make it possible to build a small,
affordable HTPC based on open source software on an open platform.
This would make it possible to create HTPC's that are based on the ARM
platform and are open source.
Outside Beagle Board community this project would lower the general
requirements on running XBMC so its of benefit to more than just
Beagle Board even if its the more important one.
From the wikipedia from BeagleBoard/GSoC/Ideas-2023 - eLinux.org
"XBMC is an open-source, cross platform media center that would allow
you to display high definition video on your TV that is streamed from
your local network or the internet. XBMC on Beagle Board would would
be a very low cost, low power platform that would allow the media
center to literally be embedded in the TV."
If I get stuck and my mentor isn't around I can always get help in the
XBMC community (we have a few Beagle Board equipped developers) or the
Beagle Board community over IRC.
==Miscellaneous==
I don't have a running Beagle Board yet but a TI sponsored one is in
shipping.