Exchanging the font & software render

[TheVinn]

I guess that the only way to do it is to have a factory base class that can create the right type of renderer, and a static method to register your new factory as the default producer of them. Unfortunately that means they all have to be heap-allocated, which is a bit inelegant, but not too big an overhead. Bit of a faff to write it all though, I was hoping to do this with minimal impact.

Yes, this is exactly what I had in mind. There would be a virtual function on the ComponentPeer that would act as the "Factory" to return a heap allocated renderer, and the default implementation would just return what it is making now.

Further refinements would virtualize the drawing so that the factory could be to create a graphics context for each CPU core and divide the area to be redrawn into strips, and render them in parallel on multiple CPUs.

[jules]

In fact, it wouldn't be enough to add a method to ComponentPeer, because there are places where you're not creating the peer yourself, or where there isn't one (e.g. rendering to an image).

Since I'm playing with openGL rendering at the moment too, which has similar problems, I'll try to figure out a clean solution that covers all these things.

[zamrate]

Does that mean we'll get cool animation effects using OpenGL etc..? I'd dream of that! We're 2011 and JUCE really would kick a** with something like that.

[jules]

Well, the idea is that you'll be able to render into an opengl framebuffer using a normal Graphics context, and mix up normal openGL commands with the 2D stuff, so yes, you'd be able to render your component into a framebuffer and then whizz it around in 3D if you wanted to!

[OBO]

Well, the idea is that you'll be able to render into an opengl framebuffer using a normal Graphics context, and mix up normal openGL commands with the 2D stuff, so yes, you'd be able to render your component into a framebuffer and then whizz it around in 3D if you wanted to!

This is my F5-thread!

Would that be a pure OGL renderer or does it need to mix in software rendering?
I think pure OGL would certainly be fastest as it could allow some batching optimizations.

Since it seems you nailed Paths in pure OGL i think that was the hardest part, in terms of antialising problems?
For smooth lines, i would think it works to construct them at a high resolution, with transparent vertices on the edges and supersample at a renderbuffer - maybe thats what you already did to paths.

[jules]

AFAICT it should all be possible without software rendering.

The bit that had me puzzled was anti-aliased polygons, but I got that working by rendering a jittered set of triangles into just the alpha channel of a framebuffer to create a mask, and then I'll render the various gradient fill patterns into just its RGB channels, after which it can all get copied to the target. It's a lot of triangles and data moving, but that's what GL is good at, so hopefully it'll work out to be pretty fast!

[zamrate]

Sounds absolutely awesome! When do you think you'll have finished coding on it? I assume it will still be possible for me to do my own font-rendering, even with OpenGL (via exchanging the software renderer by my own one) ?

[jules]

Am working on it at the moment - there's quite a lot of work involved, but am really enjoying it, so it'll probably get done fairly soon!

As far as font rendering goes.. yes, it probably won't make much difference there.

[onar3d]

Hi Jules, if I didn't misread your description, it seems to me that you are achieving anti-aliasing manually by rendering elements more than once and shifting them around?

If so, perhaps this is a useful piece of knowledge: relatively recently (the last few years) OpenGL also allows rendering into multisampled framebuffer objects, so the graphics card does the AA for you. I wrote a contribution to the Processing GLGraphics library doing this two years ago. Now I don't remember what I did exactly, but briefly looking at the code I see "GL_TEXTURE_RECTANGLE_ARB" and "glRenderbufferStorageMultisampleEXT()" having something to do with it.

Let me know if this seems interesting/relevant to you and I can dig out some code examples, or point you in the right direction.

[jules]

Yeah, I was hoping multisampling would be the answer, but unfortunately

a) it looks rubbish! 4 or even 8 levels of grey isn't enough!
b) it's not available on all systems
c) it uses more memory
d) I need to do it in a framebuffer, and to only set the alpha channel, so I can then fill the RGB channel with a gradient or other fill pattern

The system I've figured out is quite neat, and works for all hardware - in the future there'll probably be better ways using fragment shaders and pixel coverage, but I'm only just getting started with openGL so not going to worry about that yet.

[TheVinn]

I would just like to weigh in...


...openGL and other renderering engines is great, but I hope that we always keep the built-in software rendering engine (the awesome one that Jules wrote) in tip-top shape, so we have something that achieves these goals:

1) Is available in source code form and can be modified
2) Produces a consistent result regardless of platform
3) Is immune to proprietary changes in third party libraries (*glares at Apple*)

[jules]

Don't worry, the software renderer isn't going away! On some older systems it's probably going to be faster than openGL anyway - will be interesting to see how the benchmarks perform.

[TheVinn]

Don't worry, the software renderer isn't going away!

Oh, I'm not worried that its going away, only that improvements to it will be abandoned in favor of latest the new shiny toy.

Kind of like a faithful girlfriend who gets dumped for a younger model.

[zamrate]

@Vinn: But at least you'll be able to optimize it yourself now when it becomes exchangeable! For instance, for me only a couple of functions need to be faster or better. I don't care about the rest.

[jules]

FYI I've added a LookAndFeel::createGraphicsContext method now, which will let you replace the renderer with your own class.