Best practices of X demonstrations

[Evan K. Langlois]

Hi Alexander, 

To answer your "eye-candy" question ... there isn't a whole lot out
there that really demonstrates what is so great about the new Xorg.   
Its so new, that we really haven't tapped the new architecture yet.  

I'll begin with some background and to demonstrate whats so cool, and
you can start thinking about how you really want your demonstration and
what the goals of the demonstration should be.

Most of the new changes in Xorg are related to the "pretty shadow"
effect that everyone knows.

However, its the underlying architecture that makes this possible that
is really of importance.  For the past .. oh .. 20 years maybe, the
primary method of image composition has been the BITBLT, a method of
more or less pasting an image onto the screen, usually as a square block
of pixels.  To that we add a bitmask so we can have non-square regions,
but it still uses a bitblt, just with a few binary operations added to
the equation.  Pixels are on or off, or can have XOR or other bit
operations done, but you are always dealing with regions of solid color
on a single field of pixels.

The new method breaks up the screen so that top-level windows are
actually on their own "field" or "layer".  This layer can have partially
transparent portions.  The data is stored off-screen, and the final
display is generated using another helper application.  Currently this
is xcompmgr which renders the screen by using Porter/Duff image
composition of the layers, which is used extensively in the film
industry.  In computer terms, we call this the "Alpha Channel".  This is
like the difference between a GIF and a PNG.  A GIF can have a
transparent area, but thats just a hole in the image.  A PNG can have
levels of transparency.   By having this done by a seperate utility, you
expose the power of the system to whatever uses you can devise for it,
much like the original X made the Window Manager a seperate entity.  Now
the screen itself is rendered by a replaceable entity!

What you can do with these alpha levels is the important part.  Unlike a
GIF that has to be pre-anti-aliased to its background to remove jaggies,
a PNG can use its transparency layer for anti-aliasing so that it looks
smooth against ANY background (great to do with Web pages!).  This means
that if you have round or curved Windows, by using the alpha channel
they can be perfectly smooth.  All your icons can have smooth edges with
transparent drop-shadows, Windows can have drop-shadows against other
windows.  Imagine how this can be applied to remote display protocols
like VNC, that can now be told exactly what has changed on the screen!
Its the difference between the old blue-screen effect where you have a
border and subtle jagged edges around what is being pasted over the
video, and the new compositing where computer generated images are
seamlessly integrated into live video (see link below).  That right
there might be a good place to start with your demonstration.  Don't
just show the new X - people have seen KDE drop-shadows and fake
transparency effects for years.  Its the underlying principle thats
changed, and should be demonstrated in addition to the new X.  

A simple demonstration of what compositing is, can be done with a simple
web page.  Make a pretty image with lots of curves and such on a
transparent layer in GIMP.  Save it as a GIF and as a PNG.  Display it
on a web page with a background.  You'll notice PNG's anti-aliasing
works with any color.  The GIF you have to paste the right color
background under it and do the anti-aliasing on that color or image - a
manual composite with Gimp that has to be redone for every background. 
The new X server does this on the fly (like the PNG).  If you don't
think anti-aliasing is important since you normally have square windows,
think again about what happens under OS X when a window is iconified. 
During the animation, its not square at all, and it doesn't look jagged
thanks to alpha-blending.   How about mplayer/xine - some of those
themes don't use square windows either!  For an example of what I mean,
go to http://coolrunningconcepts.com/cgi-bin/alpha-demo.cgi  Then select
different background colors and patterns from the bar on the bottom (the
jaggies are most noticeable with white).

To make shadows and such fast, It's important to know what parts of the
screen have to be redrawn, and therefore, which ones have to be
recomposited.  In the past, a rectangle list was used to divide up the
screen and as a window was uncovered, the application was told to redraw
that portion.  Now, that portion might have a shadow over it, or the
window above it might be transparent, so the Damage extension keeps
track of what is damaged so it can be recomposited on the real display
screen from the off-screen bitmaps where the application actually writes
to.  Because the application is no longer writing directly to the
screen, the representation of the screen can be controlled by another
application, such as xcompmgr.   Imagine how this can be applied to
remote display protocols like VNC, that can now be told exactly what has
changed on the screen!

I'm wondering if any of the anti-aliased font code makes use of
semi-transparent pixel compositing.  I believe so, as I don't see how
else this could be done well, but I doubt its been integrated into the
compositing system, and probably exists on its own.

The compositing effects are limitless, from simple drop-shadows and
transparencies, to more advanced things like the eye-candy when you
iconify a window under OS X and it twists and slurps itself into its
icon.  The window can update during all this, so if you wanted
non-selected windows to shrink to 75% of their size slowly and twist and
curdle like cooking bacon, while working on another window, you could,
while it was updating!

Think of all the screen savers that take a snapshot of the screen!  With
Xorg 6.8, they can be rewritten to do these same effects without a
snapshot, on a live screen, while it updates!  If you have some
programming skills, this might be the place to hack up a nice demo. 
There are some desktop eye-candy programs that make a spinning cube as
you switch desktops, each desktop being a cube face ... but they
annoyingly have to grab constant snapshots and the screens aren't live
during the animation.  Now they can be rewritten to do it right!  3D
desktops with each window flipping and turning?  No problem, now that
the view of the desktop has been removed from the control of the
application!  Having a window display on the side of partially rotated
cube is just a matter of making a replacement for xcompmgr that does
some OpenGL.

Here's an example of how one application has gone from emulating an OS X
effect (with noticeable extra work and visual issues), to performing the
identical function gracefully.  Compare skippy and skippy-xd (XD for
XDamage) here : http://thegraveyard.org/skippy.php   This would be a
great application to show for your demo!  Also, demo Gnome, not KDE. 
People are used to the shadows under KDE, so demonstrate that its now
possible for the system to do these effects without special help like
the KDE hacks.  Also, drag a Window around really fast.  Then kill
xcompmgr and do it again.  Without xcompmgr, the system shows the
limitations of the old X.  You either bog the CPU with constant updating
of small portions of the screen, or you get a trail of the old mess as
each application waits its turn to update its window in bulk.  With
xcompmgr on, the off-screen displays and new features of X allow the
window to be smoothly dragged over the screen at any speed, without a
trail of waiting updates.

For more info on Alpha Blending, check out this PDF
ftp://ftp.alvyray.com/Acrobat/7_Alpha.pdf

Good luck with your demo, and sorry for the lengthy post.

Thank You,
Evan K. Langlois
Evan at CoolRunningConcepts.com

Cool Running Concepts. 
"Computing at the Speed of Thought"

http://CoolRunningConcepts.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20041006/e3820e90/attachment.html>