<div class="gmail_quote"><div>LukasT wrote:<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> Now, with respect to "boring, very regular" hatching, the current algorithm<br>
> (described in the GUI as trigonometry-algebra) has the problem that lines<br>
> thicken in incremental mode (opaque background off) and look jagged in wash<br>
> (opaque background on). Part of the jagging comes from the fact that the<br>
> tips in the borders of the lines look different than the inner parts, so<br>
> cutting those borders would help; that would have the extra benefit of<br>
> reducing thickening in incremental mode. But even so, the lines get<br>
> inherently out of sync when drawn little-chunk by little-chunk instead of<br>
> all at a time; I am sure that it is due to the rasterization step, because<br>
> I did the algebra carefully, and floating-point calculations aren't THAT<br>
> imprecise to cause such errors to arise (or are they?).<br>
<br>
</div>You might revisit the rasterization code. Maybe try to write some debug code<br>
and see how is our rasterization code behaving and fix the problem, if you are<br>
able. I spent some time on rasterization when I was working on GSoC 2008,<br>
there were problems with lines so I left the code as it was.<br></blockquote><div><br>I'll try to read that and see if I can do something.<br>I'm a bit intimidated by touching the existing codebase, as I think I may break something.<br>
I'm also very slow reading code, as I need to familiarize with many things I don't know, though I'm getting faster.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
<br>
> I believe the "no jagging and less thickening" benefit is remarkable, it<br>
> would make the hatching generated look almost as clean if it were made by a<br>
> filter, but it would be generated in real time and directly on the canvas<br>
> by the user, instead of requiring the user to mount an elaborate set of<br>
> layers and apply filters on it to get his final result (besides, the<br>
> GIMP's Newsprint filter isn't too versatile with the hatching, so it would<br>
> take the user many iterations and therefore a great deal of time to<br>
> achieve areas with different thickness or with crosshatching, using that<br>
> filter).<br>
<br>
> Endnote: with respect to Incremental and Wash: the dialogue the UI offers<br>
> for choosing between incremental and wash mode has different effects than<br>
> what I envisioned as the "opaque background" option, that's why I want both<br>
> to coexist. When I link the BrushTip dialogue I'll make a proof of concept.<br>
<br>
</div>Would you document all those options you have in your paintop in the wiki?<br>
E.g. I did preliminary docs for spray [1] long time ago (older then Internet),<br>
it's not up-to-date, but you have inspiration.<br>
<br>
[1] <a href="http://wiki.koffice.org/index.php?title=Paintops/Spray_brush" target="_blank">http://wiki.koffice.org/index.php?title=Paintops/Spray_brush</a><br><br></blockquote><div>No problem, I will.<br></div></div><br>