Exchanging the font & software render

Is it possible to exchange the software renderer for Graphics by one’s own renderer? What I want to do is to rewrite a few functions and also change the font rendering to LCD-optimized rendering.

You can write your own LowLevelSoftwareRenderer class, though it’s not for the faint-hearted!

Ok, let’s say I have made my class MyLowLevelSoftwareRenderer. How do I tell JUCE to use it for all forthcoming rendering (without modifying the JUCE source code)?

Well, you can’t globally apply your class without modifying the platform-specific ComponentPeer code, because setting up a rendering context to use for a window repaint is obviously a very platform-dependent operation. You’d need to get your hands dirty in the component peer code for whatever platform you’re using.

I suppose that’s WindowsBitmapImage::createLowLevelContext() you are talking about for Windows, and on Mac the renderer is created & destroyed again in NSViewComponentPeer::drawRect (NSRect r). Just a suggestion: it would be nice to have a define JUCE_CUSTOM_LOWLEVEL_GRAPHICS_SOFTWARE_RENDERER or similar that could be set so it’s used instead of the hard-coded LowLevelGraphicsSoftwareRenderer. Modifiying the JUCE code is something I want to avoid, and that’s why I originally posted my question.

Yes, that’s a good suggestion. But I think you’d probably be the first person to try doing this, which is why I’ve not put anything like that in place.

Thanks. Maybe I’ll post my work here later on.

Zamrate, perhaps you should look into integrating fog-framework as a new renderer. It’s MIT Licensed and vastly faster than Cairo and GDI+, as seen in the benchmarks. It has single, multi-threaded rendering and CPU specific optimizations (MMX/SSE2/SSSE3).

Not really, I made a suggestion a while back in the platform-specific implementations to add a virtual method to ComponentPeer that returns a pointer to the graphics context to use. Currently its a stack variable. The default method could be to create the software renderer the way it does now, but overriding it would let the OP achieve his goal.

From juce_win32_Window.cpp:

    void handlePaintMessage()
    {
        //....
                LowLevelGraphicsSoftwareRenderer context (offscreenImage, -x, -y, contextClip);

“context” could be a pointer returned by calling a virtual method on the Component Peer.

anything goes, as long as I don’t have to modify the JUCE sourcecode :slight_smile:

Not really, I made a suggestion a while back in the platform-specific implementations to add a virtual method to ComponentPeer that returns a pointer to the graphics context to use. Currently its a stack variable. The default method could be to create the software renderer the way it does now, but overriding it would let the OP achieve his goal.[/quote]

+1 . I still have that AGG wet dream some nights… :slight_smile:

Yeah, something like that, although it shouldn’t be an object allocated on the heap, as I suspect it would slow the painting to a crawl…

I’ve tried fog and the 2 small examples don’t show much. Difficult to estimate how good or bad it is. But multi-threaded rendering seems like a no-go to me, for 2 reasons: 1) I think if 1 CPU-core is at 100% doing rendering that’s already too much CPU being vasted. 2) I cannot imagine that the complexity is worth it for normal desktop applications - I’m not coding games here.

Why do people always assume that operator new is never overloaded for a class? Forget about how the object gets created until it is a problem…then apply the existing C++ tools to fix it.

Why do people always assume that operator new is never overloaded for a class? Forget about how the object gets created until it is a problem…then apply the existing C++ tools to fix it.[/quote]
Eh? I said that it shouldn’t be allocated on the heap. Read again and read it right.

If operator new is overloaded for a class, and its implementation returns a pointer to an already existing object (i.e. re-used) how is this causing it to be allocated (on the heap, or anywhere for that matter)?

If operator new is overloaded for a class, and its implementation returns a pointer to an already existing object (i.e. re-used) how is this causing it to be allocated (on the heap, or anywhere for that matter)?[/quote]
Well if you implement the overloaded new that way, it won’t. But if you don’t you’ll have to allocate a new object somehow. And that usually is on the heap. Right ?

Allocating an object on the heap wouldn’t be a problem here - the rendering code creates a bunch of heap objects anyway as it does its work. But the problem with overloading a virtual method to create a custom context is that it might need to be supplied with a platform-specific handle of some kind to do its job, so there’s no way to write a virtual method with appropriate parameters.

Wrong again. It could come from a small array of objects with static storage duration, or array of bytes with static storage duration.

Wrong again. It could come from a small array of objects with static storage duration, or array of bytes with static storage duration.[/quote]

Usually mean usually, and usually it is the heap. You’re bringing up fringe cases. Drop it.