Exchanging the font & software render


#1

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.


#2

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


#3

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)?


#4

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.


#5

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.


#6

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.


#7

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


#8

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).


#9

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.


#10

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


#11

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:


#12

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…


#13

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.


#14

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.


#15

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.


#16

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)?


#17

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 ?


#18

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.


#19

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


#20

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.