 |
Animation in Blu-ray, OCAP, MHP and other GEM devices
Problem Overview
When authoring a Blu-ray title, it's essential to have a solid,
crisp graphical presentation. This almost always means double-buffering.
Becaue and HD screen is quite large - 1920x1080 if you're doing full HD,
and 960x540 if QHD - and because Blu-ray players are consumer devices
with relatively modest computational power, it's important that you
make your drawing operations efficient.
The HD cookbook discusses drawing modes in Chapter 17, particularly
starting on page 17-12.
It describes the three drawing modes: direct draw, repaint draw,
and sync frame-accurate animation (SFAA). Direct draw is probably the best
choice for most situations. Repaint draw is less efficient, but you
might need to use it if you're integrating your drawing with a widget
set. Sync frame accurate animation is a great tool, particularly if
you want tight integration with video, but it does involve some more
overhead, and as of this writing it was
not known to have been implemented well across all player implementations.
The HD cookbook open-source project includes an optimized animation
framework, described below. It does direct draw or repaint draw, and
was designed to be easily extended
to use SFAA, but the focus is really on direct draw. You can read more
descriptive text about this package in the animation framework overview
at https://hdcookbook.dev.java.net/animator.html. Note that the GRIN
scene graph uses the animation framework, but the GRIN animation
framework can be used completely independently of the GRIN scene graph.
In fact, if you only want the animation framework you should be able to
just use the animator package
by itself, along with the util package, and just strip the
rest of the GRIN framework out of your project.
that's included in the same source code repository.
With typical player speeds, in order to efficiently paint a moving
animation over a large screen like
the HDTV attached to your customer's Blu-ray player it's usually essential
to figure out what parts of the screen have changed, and repaint the changed
parts. This applies both to the drawing to the pixel buffer you use for
double-buffering, and for the BLT operation from that pixel buffer to the
screen's frame buffer.
The GRIN Animation Framework
Optimized drawing can be hard to program directly. The GRIN animation
framework provides
support that will hopefully make this easier. For each logical unit of drawing,
your application creates a DrawRecord instance. This understands
drawing within a rectangular area. It tracks for you what pixels had been
filled with drawing in the previous frame, whether those pixels were drawn
to in that actual frame of drawing, or in a previous frame. It also tracks
which pixels are changed in the current frame. It uses this tracking
information to inform the animation framework which areas of the
pixel buffer need to be erased, which need to be repainted, and which
areas of the pixel buffer need to be copied to the frame buffer for
the current frame of animation.
A detailed writeup of the API to the GRIN animation framework is available
at https://hdcookbook.dev.java.net/javadocs/grin/javame/com/hdcookbook/grin/animator/doc-files/index.html.
This includes a pretty detailed general analysis of the tradeoffs that go into
optimized drawing.
Conclusion
Getting efficient animation performance can require some pre-planning
and organization, but it's necessary to get adequate performance on
typical Blu-ray players. Optiized drawing can easily be the difference
between achieving 24 fps on a full HD animation, versus achieving 3 fps.
Hopefully, the GRIN animation framework provides a good set of flexible
tools you can use to do optimized, double-buffered animations of your own.
-- Main.billf - 20 Jun 2008
|