From: Søren Sandmann Pedersen Date: Wed, 29 Apr 2009 05:44:56 +0000 (-0400) Subject: More refactoring notes X-Git-Tag: pixman-0.15.4~47 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=3d73ce6813743811ff4413df554b438d3790c361;p=platform%2Fupstream%2Fpixman.git More refactoring notes --- diff --git a/pixman/refactor b/pixman/refactor index a3ee523..b57e68a 100644 --- a/pixman/refactor +++ b/pixman/refactor @@ -10,6 +10,21 @@ The pixman code is not particularly nice to put it mildly. Among the issues are may be one of the uglies names ever created. + coding style: + use the one from cairo except that pixman uses this brace style: + + while (blah) + { + } + + Format do while like this: + + do + { + + } + while (...); + - PIXMAN_COMPOSITE_RECT_GENERAL() is horribly complex - switch case logic in pixman-access.c @@ -29,6 +44,11 @@ The pixman code is not particularly nice to put it mildly. Among the issues are - Code related to particular image types should be split into individual files. + pixman-bits-image.c + pixman-linear-gradient-image.c + pixman-radial-gradient-image.c + pixman-solid-image.c + - Fast path code should be split into files based on architecture: pixman-mmx-fastpath.c @@ -67,4 +87,16 @@ Issues that must be kept in mind: whenever possible. The "horizontal" classification should be a bit in the image, the -"vertical" classification should just happen inside the gradient file. +"vertical" classification should just happen inside the gradient +file. Note though that + + (a) these will change if the tranformation/repeat changes. + + (b) at the moment the optimization for linear gradients + takes the source rectangle into account. Presumably + this is to also optimize the case where the gradient + is close enough to horizontal? + +Who is responsible for repeats? In principle it should be the scanline +fetch. Right now NORMAL repeats are handled by walk_composite_region() +while other repeats are handled by the scanline code.