On Sun, Feb 25, 2007 at 01:35:09PM -0400, bulia byak wrote:
On 2/25/07, Aaron Spike <aaron@...749...> wrote:
bulia byak wrote:
So, it looks like due to this stupid byte-order issue, cairo for us is practically an all-or-nothing proposition - and much more hassle than I expected. I'm not saying it's impossible but it is quite a major project that cannot be done gradually.
Is there enough developer support to do this in a non-gradual fashion?
That's what I was trying to measure by sending that email :)
Well, how about this...
We'd been assuming previously that a cairo conversion was going to be a major project already - it was only recently that we got hope that it could be a quick switch. So we had been planning on focusing 0.46 on prepatory refactoring, to get the codebase into a better shape where all-or-nothing switches like cairo could be done a bit easier. With your work there's now a better understanding of the specifics, so maybe it'll be clearer where the refactoring is needed?
I haven't gotten much into the internals of the renderer, so don't know much about how the RGBA ordering is handled (could you point out an example?), but I do know what you mean about rendering code being scattered all over the place.
An initial thought would be - could the RGBA-specific rendering code be better compartmentalized? E.g., instead of being present in 30 different files, reducing that to 5 or 10?
Along with that, could the existing renderer calls be modified to be exact analogs to the cairo calls, to the degree that we'd be able to later just search and replace them with the corresponding cairo calls?
If this is not doable, another thought to incrementalize the mass change would be to incorporate preprocessor macros, and a WITH_CAIRO configure option, that allows us to put the new cairo code while still preserving the old system for those who need to use it. Obviously this incurs some ugliness in the short term.
Of course, a branch is another option. We've done this before, with inkboard, gtkmm, and so on, and know it works. It also has some downsides of re-integration hassles and the risk of not getting sufficient developer attention when it's outside the codebase. However, you *can* work much more swiftly on a branch where you can cause mass breakage to get things converted over. The big price to pay for this approach will be lots of new bugs (offset somewhat by other bugs that will become obsoleted).
Bryce