Hi !

I experienced a few "bucket deceptions" when I started, and took a look at how things are done (not that i could do better myself, but i wanted to know how things work), so here are some thoughts:

The current bucket tool[1] works by:
-> creating a rasterized image of the screen
-> "fill" the adjacent pixels that have ~ the same color as the pixel you clicked on, with a quite simple algorithm (that may be improved)
-> vectorize the resulting bunch of pixels with potrace, and simplify the result, creating another path on top of the image.

This probably can be improved or done differently, of course, but the current version has some points to keep in mind: it "works" on vector parts, including overlapping ones, but also on bitmap parts, or on anything, vector or not, allowing people to use it to quickly and simply "vectorize" parts of anything with it.


For a while now I'm only using it when i have no choice and on raster parts ( = almost never. And I don't miss it ! In 99% of the cases when people i know ask me for help there is no need for bucket[and in some cases, it is as simple as "select the object, change its fill. Why did you want to use the bucket, did you think this was MSPaint ? --the "object fill" paradigm is not obvious for people coming from the raster world that see the existence of a bucket like-the-one-they-know-but-not-quite-the-same -- ]). When it's vector I always find a way to use path operations to get something more satisfying.

There could potentially be a way to do things "the vector way" automatizing what can be done with path operations, but doing something that would work with potentially mixes of gradients, patterns, masking, filters, texts, and so on, without going through a pixel representation can be tricky. And if you want to fill "the pixel way" there will always be the question of what zoom to go, what level of precision you want, in the rendering AND in the tracing, etc. Maybe the two approaches can be mixed in some way (first pixel-based, then looking for vector segments that already exist and would seem to be on the tracing edge ... or vectorization done at the same time as the "filling" and not with potrace afterwards... just random thoughts here.) You mentionned toonboom's vector bucket in g+, but a quick google search only gave me a store page with something at $1200 and probably closed-source...

Anyway, I'll wait for your proposal: I have convinced myself for some time that "paint bucket is inherently a raster tool" but if I'm proved wrong and an awesome vector bucket tool gets implemented in inkscape, or if the tool is hugely improved in some way, all the better :)

--
Mc

[1] http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/ui/tools/flood-tool.cpp



----- Mail original -----
De: "Todor Imreorov" <blurymind@...400...>
À: inkscape-devel@lists.sourceforge.net
Envoyé: Dimanche 26 Avril 2015 00:36:09
Objet: [Inkscape-devel] Access to the wiki to add a better bucket tool  design proposal



Hello everyone!
There was a google+ discussion where I expressed thought on a better bucket tool implementation and discussed issues with the current one.
https://plus.google.com/u/0/+inkscape/posts/4ZGgz6XKmGo

As a result + Martin Owens and + Tavmjong Bah invited me to this mailing list to get involved in the effort to improve the bucket tool in inkscape.

I need to write a proper design proposal at inkscape's wiki. In it I plan to outline the workflow issues and include examples of better bucket fill implementations from other open source software and public algorithms / research papers .
How do I go about getting write access to the wiki page and where do I exactly file my proposal?


Thank you in advance for the time.


Best regards,
Todor