Commit graph

5 commits

Author SHA1 Message Date
luz.paz
6d93bddbd6 Misc. typos
Found via `codespell -i 3 -w -I ../cairo-word-whitelist.txt -L tim,ned,uint`
Follow up of 12cb59be7d

Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
2019-01-31 17:37:15 -08:00
Maarten Lankhorst
a34cb719cd Add support for RGBA128F and RGB96F formats.
IGT wants to add support for planes with a bit depth >10, which
requires a higher precision format than we have currently.

I'm using RGBA as format, because of its existence in OpenGL.
With the new formats we can directly convert our bytes to half float,
or multiply a colro vector with a matrix to go to the Y'CbCr colorspace.

This requires pixman 0.36.0, so bump the version requirement.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
2019-01-07 19:10:44 -08:00
Chris Wilson
af9fbd176b Introduce a new compositor architecture
Having spent the last dev cycle looking at how we could specialize the
compositors for various backends, we once again look for the
commonalities in order to reduce the duplication. In part this is
motivated by the idea that spans is a good interface for both the
existent GL backend and pixman, and so they deserve a dedicated
compositor. xcb/xlib target an identical rendering system and so they
should be using the same compositor, and it should be possible to run
that same compositor locally against pixman to generate reference tests.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

P.S. This brings massive upheaval (read breakage) I've tried delaying in
order to fix as many things as possible but now this one patch does far,
far, far too much. Apologies in advance for breaking your favourite
backend, but trust me in that the end result will be much better. :)
2011-09-12 08:29:48 +01:00
Uli Schlachter
7b97533221 map-to-image: Handle non-32bpp formats
Fixes: map-all-to-image, map-bit-to-image for image16

Signed-off-by: Uli Schlachter <psychon@znc.in>
2011-08-08 21:06:09 +02:00
Chris Wilson
a69335a84e API: map-to-image and create-similar-image
A common requirement is the fast upload of pixel data. In order to
allocate the most appropriate image buffer, we need knowledge of the
destination. The most obvious example is that we could use a
shared-memory region for the image to avoid the transfer cost of
uploading the pixels to the X server. Similarly, gl, win32, quartz...

The other side of the equation is that for manual modification of a
remote surface, it would be more efficient if we can create a similar
image to reduce the transfer costs. This strategy is already followed
for the destination fallbacks and this merely exposes the same
capability for the application fallbacks.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-07-26 14:55:58 +01:00