Site navigation

Low level graphics renderer

General JUCE discussion
#1

I’m trying to implement the LowLevelGraphicsContext with the Agg2D AntiGrainGraphics wrapper, and am now coming to the point where I’d like to test it.

On Win32, the Win32ComponentPeer uses the LowLevelGraphicsSoftwareRenderer in the paint message handler, but it would be cool to have some “plugin” structure where I could provide my own LowLevelGraphicsContext implementation.

Jules, I can imagine you have thought about how to do this “neatly”. I was thinking on the line of letting the Win32ComponentPeer take a template argument which is the renderer. Or… maybe let LookAndFeel have a LowLevelGraphicsContext * LookAndFeel::getLowLevelGraphicsContextImpl(Image&) which default returns the LowLevelGraphicsSoftwareRenderer… but that allocates the object on the heap as opposed to on the stack… hmm… :?

/R

#2

i think no one would switch at runtime a low level renderer (unless you want to compare differences and results while coding immediately).
Or maybe yes…
but specifying an overall #define JUCE_USE_AGG is a better way to go for me, so you can decide which primary low end graphics implementation you would like to use. It’s less modular but more secure (switching / messing with low level contexts at runtime could be dangerous).

#3

btw, one of the coolest stuff about agg… it’s that you can do things like this:

[code] agg::trans_affine matrix;
matrix *= agg::trans_affine_translation(-frame_width/2, -frame_height/2);
matrix *= agg::trans_affine_rotation(agg::deg2rad(35.0));
matrix *= agg::trans_affine_scaling(0.3, 0.45);
matrix *= agg::trans_affine_translation(frame_width/2, frame_height/2);

agg::trans_warp_magnifier lens;
lens.center(120, 100);
lens.magnification(3.0);
lens.radius(18);

agg::conv_curve<agg::path_storage> curve(path);
agg::conv_segmentator<agg::conv_curve<agg::path_storage> > segm(curve);

agg::conv_transform<
    agg::conv_segmentator<
        agg::conv_curve<
            agg::path_storage> >,
    agg::trans_affine> trans_curve(segm, matrix);

agg::conv_transform<
    agg::conv_transform<
        agg::conv_segmentator<
            agg::conv_curve<
                agg::path_storage> >,
        agg::trans_affine>,
    agg::trans_warp_magnifier> trans_warp(trans_curve, lens);
    
agg::conv_stroke<
    agg::conv_segmentator<
        agg::conv_curve<
            agg::path_storage> > > stroke(segm);

agg::conv_transform<
    agg::conv_stroke<
        agg::conv_segmentator<
            agg::conv_curve<
                agg::path_storage> > >,
    agg::trans_affine> trans_stroke(stroke, matrix);

agg::conv_transform<
    agg::conv_transform<
        agg::conv_stroke<
            agg::conv_segmentator<
                agg::conv_curve<
                    agg::path_storage> > >,
        agg::trans_affine>,
    agg::trans_warp_magnifier> trans_warp_stroke(trans_stroke, lens);

[/code]

to create segmented-warped-magnified stroke styles… pretty weird (both extreme flexibility and luxurious complexity)!

#4

Heh! Yeah… weird! :slight_smile:

The #define is ok, but only if its in the juce code base (which is up to Jules). Not if I have to patch juce everytime a new version comes out. In that case, its much better to have an application specified “plugin-renderer” that implements the LowLevelGraphicsContext…

#5

Cool! I’d love to see how it performs.

I think kraken is right - using a #define to enable it would be my preferred method if I was going to integrate it into the codebase. If it does a better job than the juce rendering stuff, then there’d be no reason not to leave it turned on if you’ve got agg on your machine to build with.

Are you trying to replace all the rendering methods with agg functions? There might be a few where you’ll find the juce ones better (e.g. some methods are optimised for MMX in juce, so are probably quicker than the pure C++ agg ones).

#6

For now I patched LookAndFeel and juce_win32_Windowing.cpp so I can test agg and then easily switch back as its not 100% working yet.

Pretty much everything, yes. I agree that MMX optimized functions should perform better, but ultimately I’m not targeting the intel platform…

I have a small problem though, as the Agg2D currently runs with ARGB I must use the transparent win32 window and that performs lousy in both juce & agg… :frowning:

#7

Hi Robiwan…

Any luck with this yet?
If so, any code to show?

Thanks!

#8

[quote=“bigjim”]Hi Robiwan…

Any luck with this yet?
If so, any code to show?

Thanks![/quote]

None I’m afraid, I’ve had zero to no time to put on this the last couple of months…

#9