[Mesa-dev] [PATCH] st/xorg: add some support for non 32-bit color solid fills
michel at daenzer.net
Tue May 17 10:15:50 PDT 2011
On Die, 2011-05-17 at 18:59 +0200, Marcin Slusarz wrote:
> On Tue, May 17, 2011 at 06:40:02PM +0200, Michel Dänzer wrote:
> > On Die, 2011-05-17 at 18:30 +0200, Marcin Slusarz wrote:
> > > On Tue, May 17, 2011 at 09:27:45AM +0200, Michel Dänzer wrote:
> > > > On Die, 2011-05-17 at 00:12 +0200, Marcin Slusarz wrote:
> > > > > On Mon, May 16, 2011 at 10:51:58PM +0200, Roland Scheidegger wrote:
> > > > > > Otherwise, doesn't really look hacky to me - unless we could get other
> > > > > > channel ordering or something similar...
> > > > >
> > > > > It makes assumptions about how color components are ordered and what are
> > > > > their widths - e.g. it can't distinguish r5g6b5 from a1r5g5b5.
> > > >
> > > > Such assumptions should be fine for non-RENDER operations. For RENDER,
> > > > maybe you could use something like exaGetRGBAFromPixel, at least for
> > > > inspiration.
> > >
> > > The problem is that exa does not pass format to PrepareSolid - only raw color
> > > data and depth, but pipe_context->clear wants float, so we need to figure
> > > out color format first. (Or add raw_clear operation...)
> > The format can be determined from the destination pixmap if necessary?
> I couldn't find it. How to do it?
priv->tex is the underlying texture, so priv->tex->format should be what
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
More information about the mesa-dev