When I do a bucket fill I store the result as a collection of lines going from one inside edge to the other than enumerate the list to redraw the lines.

Something like gimp would typically trace the extremities to produce a selection outline and fill a bit mask in the same way as I would bucket fill. To create a selection.

I don't think a GPU would handle the outline trace at-all well, but most fill patterns and styles are quite possible using shaders, or tilled textures. (I just did a search and came across an OpenCL implementation of filters)

https://bugs.webkit.org/show_bug.cgi?id=70099

I don't know what licence the code uses but it's a good example of what's achievable.

Oh, I see now, there's fill rule evenodd and fill rule nonzero, so i was almost right..

That's a lot of experimentation, hopeful we should be able to identify what SVG elements or parts of elements can be calculated or rendered at high performance and which ones require a more traditional approach.

Even then performance could possibly be improved manually vectorizing if GCC doesn't for a good job. (I expect you have to structure your code in a way that's friendly to GCC's algorithms) and switching to scaled integers over floats which are higher performance and give you more control over the (I've forgotten the word), basically the number of bits you've got to play with to maintain a desired rounding error.

Integers having higher performance is certainly the case for older generation CPUs where that bit of performance may be really noticeable to the end user who may not have an acceleration viable GPU.