diff options
author | David Herrmann <dh.herrmann@googlemail.com> | 2012-09-04 17:37:14 +0200 |
---|---|---|
committer | David Herrmann <dh.herrmann@googlemail.com> | 2012-09-04 17:37:14 +0200 |
commit | 816dcfb14814e19a0d4aed90db7f2e0166839d11 (patch) | |
tree | 32d764ce9869122848e606d90de296a4db1a63a1 /docs | |
parent | 69bde6077e178a0049763e42c551574f7aa84a81 (diff) |
docs: add some pixman-rendering comments
We didn't use pixman for rendering in kmscon. This documents shows some
code how we could do it but also explains why this would not improve
performance.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Diffstat (limited to 'docs')
-rw-r--r-- | docs/pixman.txt | 47 |
1 files changed, 47 insertions, 0 deletions
diff --git a/docs/pixman.txt b/docs/pixman.txt new file mode 100644 index 0000000..e42e9d1 --- /dev/null +++ b/docs/pixman.txt @@ -0,0 +1,47 @@ += Pixman accelerated Rendering = + +Several people recommended using pixman for 2D blitting to improve performance +as pixman has assembler-accelerated backends. However, pixman does not provide +the functions we need. +Most rendering operations we need, do alpha compositing with a foreground and +background color. With pixman we would have to do something like: + + pixman_image_t *pdst = pixman_image_create_bits( + PIXMAN_x8r8g8b8, + width, + height, + (uint32_t*)dst, + rb->stride); + pixman_image_t *pmsk = pixman_image_create_bits( + PIXMAN_a8, + width, + height, + (uint32_t*)src, + req->buf->stride); + + pixman_color_t fcol = { 0xffff, 0xffff, 0xffff, 0xffff }; + pixman_image_t *psrc = pixman_image_create_solid_fill( + &fcol); + + uint32_t bcol = (req->br << 16) | (req->bg << 8) | req->bb; + pixman_fill((void*)dst, rb->stride / 4, 32, 0, 0, + width, height, bcol); + + pixman_image_composite(PIXMAN_OP_OVER, + psrc, pmsk, pdst, + 0, 0, 0, 0, 0, 0, + width, height); + +That is, we create pixman-images for the destination and the mask. We could +save them in the video-display and glyph objects so there is actually no need +to allocate them dynamically. However, the solid color object can be any RGB +value and thus it must be allocated for every blit. This is way too heavy and +pixman should really provide a way to create solid images easier. Preferably +without any function call. +But the bigger problem is actually that we have to copy data twice. We need to +first call pixman_fill() and then pixman_image_composite() to get the +behavior we want. This totally kills performance. + +Profiling pixman_image_composite(), we see that it definitely is better than +our unoptimized blitters, but we need to add a function which does both +operations at once to pixman to get a decent performance. |