[quote=“sonic59”]A curve to curve stroker would be useful as well.
http://fog-framework.blogspot.ca/2011/08/quadratic-bezier-curves-stroker.html[/quote]
Now that’s cool! How close is it to being done though? And what would be the improvement for 1 and 2 pixel strokes (the most common case I believe) ?
Good question. Since fog is MIT licensed, its worth finding out, so I’ve fired off a message to the author via fog’s Google Group.
Not sure. Numerically it should be more accurate, less approximation and the wavelet rasterizer rasterizes beziers directly. Whether you will actually see a difference is another question.
If I am understanding the paper correctly, Figure 6 is showing a comparison between a very small glyph with 1-2px widths in FreeType (which I am assuming flatten paths and does scanline rendering) and Wavelet (Direct Bezier Rendering). Without the diff image, I don’t know if I’d notice the difference
Here’s a reminder! 
Neither the new LowLevelGraphicsSoftwareRenderer nor the new SoftwareRendererSavedState are templates, so they can’t be re-used. RenderingHelpers is still a namespace and not a class so there’s no way to get compile-time polymorphism - there’s no way to override one implementation in RenderingHelpers while inheriting all of the rest. Curious to why you didn’t follow the steps In my previous post…at first glance at these latest changes, I don’t see any obvious way of overriding a subset of the software renderer’s behavior without duplicating a lot of the code.
By overriding one implementation I mean, at compile time - at run time of course there would need to be a completely different GraphicsContext-derived object, like I said in my post:
MyLookAndFeel.cpp
virtual LowLevelGraphicsContext* createGraphicsContext (const Image& imageToRenderOn,
const Point<int>& origin,
const RectangleList& initialClip)
{
return new LowLevelGraphicsSoftwareRenderer <SoftwareRendererSavedState <MySoftwareRendererClasses> > (
imageToRenderOn, origin, initialClip);
}The declaration for MySoftwareRendererClasses would look like this:
MySoftwareRendererClasses.h
class MySoftwareRendererClasses : public juce::RenderingHelpers
{
// cool stuff here
};This way, one can inherit all of the original functionality without copying and pasting code (which was the whole purpose to begin with!)
I know, I was just shuffling some stuff around, I didn’t say I’d finished. Just wanted to make some initial changes that didn’t interfere with the LowLevelGraphicsSoftwareRenderer class itself, and may return to it when I get chance.
That makes a lot of sense!
I got a response to my message. The curve to curve stroker is not complete yet. The quadratic stroker is working and near complete but the cubic stroker is not complete. The code isn’t in the fog SVN but the author is willing to both share it and collaborate on development since he would like to see curve to curve stroking working in fog as well.
Regarding stroking, another thought crossed my mind.
The fog curve to curve stroker, like the usual line segment based stroking, relies on approximations when creating offset curves. This approximation occurs because higher order offset curves are required to express quadratic and cubic curves.
The offset curve of an arbitrary cubic curve requires a 10th order bezier curve. The offset curve of an arbitrary cubic curve requires a 6th order bezier curve.
If I understand the original paper correctly, even though he only goes into detail with the quadratic and cubic cases, this new method is actually capable of rasterizing n-order bezier curves.
So it may be possible to stroke paths without any approximations at all. Which may (or may not) solve the many edge cases that crop up with curve to curve stroking.
The dRowAudio module is using Bezier curves. It is probably not too difficult to modify that code to support bezier curves with arbitrary number of vertices. I have done that to some extent in my application.
But maybe that’s not what we are talking about here?
Can we make the changes to the platform-specific ComponentPeer stuff, which allow customization of the LowLevelGraphicsContext at least? I’m talking about:
juce_win32_windowing.cpp
LowLevelGraphicsContext* createLowLevelContext()
{
return new LowLevelGraphicsSoftwareRenderer (Image (this));
}and the corresponding lines for OS X, iOS, Android, etc…
