nanogui: Thread: Current status on alpha blending support?


[<<] [<] Page 1 of 1 [>] [>>]
Subject: Current status on alpha blending support?
From: Daniel ####@####.####
Date: 29 Apr 2010 09:14:51 -0000
Message-Id: <v2id08fc9ca1004290214q2d4cc3d3v7e5d90731e3c91d5@mail.gmail.com>

I find random discussions regarding alpha blending in the mailing list
archive, but there has been pretty much changes since.

I'm running Nano-X on a big endian architecture (avr32). Running on
framebuffer with the current modeline:

mode "640x480-48"
  # D: 23.333 MHz, H: 26.042 kHz, V: 48.405 Hz
  geometry 640 480 640 480 24
  timings 42857 96 96 34 8 64 16
  rgba 8/0,8/8,8/16,0/0
endmode

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?

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.

Any input on how to get alpha blending working is very appreciated!

Regards
Daniel
Subject: Re: [nanogui] Current status on alpha blending support?
From: "Greg Haerr" ####@####.####
Date: 29 Apr 2010 15:05:30 -0000
Message-Id: <04a101cae7ad$60d8cd60$6564a8c0@winXP>

: 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
Subject: Re: [nanogui] Current status on alpha blending support?
From: Daniel ####@####.####
Date: 3 May 2010 15:46:10 -0000
Message-Id: <p2wd08fc9ca1005030845y5c06d385h5101ef696d6a63d5@mail.gmail.com>

2010/4/29 Greg Haerr ####@####.####
> : 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.
>
> ...snip...
>

Thanks alot for this fully covering overview!

> 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.

Any thoughts of integrating Cairo for this? http://cairographics.org/

Regards
Daniel
Subject: Re: [nanogui] Current status on alpha blending support?
From: "Greg Haerr" ####@####.####
Date: 3 May 2010 17:03:17 -0000
Message-Id: <022801caeae2$85332330$6564a8c0@winXP>

> Any thoughts of integrating Cairo for this? http://cairographics.org/

No, Cairo is way too big, and a bit ugly.  There are far more
simple and elegant projects out there, including mupdf/fitz,
and antigrain.

Regards,

Greg
[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.