: Am I able to use the alpha blending support in nano-X? Do I need to
: change mode? Is it supposed to work with filled ellipses et al with
: GrSetGCForeground using GR_ARGB?
I am in the process of fleshing out alpha blending support for the
upcoming 0.92 release, and beyond. There are quite a few
issues relating to alpha blending, whose full implementation is
also called compositing.
Currently, the following alpha blending mechanisms are
supported and working (in git 0.92RC4):
o freetype 2 rendering when GR_TFANTIALIAS set.
This uses the drawarea_alphacol (alpha blend with constant fg color)
subdriver entry point, which is now implemented in
8bpp palette, 15bpp, 16bpp, 24bpp, and 32bpp (ARGB
and ABGR) formats.
When freetype 2 is used without anti aliasing/(alpha blending),
then the drawarea_bitmap_bytes_msb_first entry point is
used, which will now draw fg or fg and bg when asked.
o image drawing using GrDrawImage*() for image formats
that support an alpha channel. Currently, these image
formats are PNG and TIFF. The GdDrawImage routine
current implements alpha blending for the following
pixel formats: 32bpp ARGB and ABGR, 24bpp, 16bpp
and 15bpp (555).
Currently, GdDrawImage uses drawpixel to draw any
image. I plan on moving all image drawing to using
the blit subsystem in v0.93, which will result in a large
speed improvement for image drawing. The drawarea
and blit drivers will be combined in that release also.
o blit rendering with MWROP_BLENDCONSTANT.
This implements a blit operation using a constant
alpha (used in bin/malpha demo) for transparent windows.
This is implemented in 32, 24, 16, 15 and 8bpp drivers.
o blit rendering with MWMODE_SRC_OVER, otherwise
known as compositing. With this mode, the required
32bpp ARGB src pixmap is alpha blended using the
alpha values created from the GR_ARGB alpha values,
allowing fully or partially transparent areas to be not
drawn or blended in the destination pixmap. Currently
only the 32bpp ARGB and ABGR drivers support
SRC_OVER compositing.
There is no current support for drawing ellipses, circles,
rectangles or lines using alpha blending. I have extensive
plans for v0.93 to implement a full-blown compositing
engine in microwindows, which will use a the newer
SVG/PostScript imaging model of paths, with filled
and stroked shapes drawn using a complex anti-aliasing
rasterizer. This same path oriented rasterizer will also
support freetype and t1 (adobe postcript) outline fonts,
and ultimately allow microwindows programs to display
text and images on a page that can be resized quickly
without re-rendering in the same style as the iPhone/iPad.
This work requires pulling together all the various blits,
stretchblits, stretchblitex, and drawimage code into a
single blit routine with various compositing and raster
operators. I've decided it would be better to the
the (very long awaited) 0.92 out first with the large
number of submitted patches before changing the
driver architecture significantly.
:
: It doesn't work with current setup and I'm having a hard time figuring
: out how the SCREEN_PIXTYPE param in config corresponds to the current
: framebuffer mode, and so on.
The SCREEN_PIXTYPE only sets sizeof(MWPIXELVAL).
If you look at the fb_open code in drivers/scr_fb.c, you'll
see that it then asks linux for the current framebuffer mode,
and then loads a drawing subdriver (fblin32.c, fblin24.c, etc)
based on the results. All the drawing subdrivers from
32bpp to 1bpp are linked into the nano-X server, so no
recompilation is required when switching modes. (The
drawing subdrivers are also required for say the X11 screen
driver, as they are also used when drawing offscreen
pixmaps, which are then blit'ed to the X11 screen driver.
:
: Any input on how to get alpha blending working is very appreciated!
Hope this helps. Pull down the latest snapshot/git and things
should work.
Regards,
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org
For additional commands, e-mail: nanogui-h...@linuxhacker.org
