Exchanging the font & software render

73 posts / 0 new
Last post
zamrate
Offline
Last seen: 1 year 5 months ago
Joined: 24 Sep 2007 - 17:33
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.

jules
Offline
Last seen: 8 hours 40 min ago
Joined: 29 Apr 2013 - 18:37
Re: Exchanging the font & software render

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

zamrate
Offline
Last seen: 1 year 5 months ago
Joined: 24 Sep 2007 - 17:33
Re: Exchanging the font & software render

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

jules
Offline
Last seen: 8 hours 40 min ago
Joined: 29 Apr 2013 - 18:37
Re: Exchanging the font & software render

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.

zamrate
Offline
Last seen: 1 year 5 months ago
Joined: 24 Sep 2007 - 17:33
Re: Exchanging the font & software render

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.

jules
Offline
Last seen: 8 hours 40 min ago
Joined: 29 Apr 2013 - 18:37
Re: Exchanging the font & software render

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.

zamrate
Offline
Last seen: 1 year 5 months ago
Joined: 24 Sep 2007 - 17:33
Re: Exchanging the font & software render

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

sonic59
Offline
Last seen: 1 day 11 hours ago
Joined: 9 Mar 2010 - 16:51
Re: Exchanging the font & software render

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

TheVinn
Offline
Last seen: 10 hours 10 min ago
Joined: 29 Aug 2009 - 11:31
Re: Exchanging the font & software render

jules wrote:
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.

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.

zamrate
Offline
Last seen: 1 year 5 months ago
Joined: 24 Sep 2007 - 17:33
Re: Exchanging the font & software render

anything goes, as long as I don't have to modify the JUCE sourcecode :)

robiwan
Offline
Last seen: 1 week 5 days ago
Joined: 18 Dec 2006 - 20:38
Re: Exchanging the font & software render

TheVinn wrote:
jules wrote:
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.

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.

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

Welcome to oblivion, will you be staying?

Pages