Exchanging the font & software render

[jules]

Yeah, for vertical hinting you'd need to use a custom typeface class too.

[zamrate]

Took me quite some time to grasp JUCE's font system, but I start getting results now with my own LowLevelGraphicsSoftwareRenderer inheriting renderer.

On the left you see the result (my renderer), compared to the original in JUCER on the right. I'll do some performance comparisons later on.

[mucoder]

*very* readable and easy on the eyes
and while taste is subjective of course, I personally find it esthetically quite pleasing as well. Great job!

[Andrew J]

Wow, I'm getting excited - looks like a leap forward for Juce GUIs on LCD screens!

[zamrate]

Jules, would it be possible to make the states of the LowLevelGraphicsSoftwareRenderer accessible to sub-classes? Without that it's difficult to just exchange some functions without rewriting everything...

[jules]

Jules, would it be possible to make the states of the LowLevelGraphicsSoftwareRenderer accessible to sub-classes? Without that it's difficult to just exchange some functions without rewriting everything...

No, I don't think that should be made public, I may want to change it in future, and don't want to have to worry that people have written code that depends on it. (I'm really not at all keen on the idea of subclassing it)

Please bear in mind here that I've told you that I think you're doing it the wrong way, and have explained what I think is the only sensible approach. If you want to implement it the way I suggested, I'd be happy to help you get that working. If you want to ignore my advice, then fine, but in that case you're on your own!

[zamrate]

Well I did it that way not because I'm stubborn but because 1) I had the working code for it already (with bitmaps), and 2) because it is faster (I'm using bitmaps for the glyphs, not edge tables). Furthemore I'm also replacing some drawing functions, it's not only the font rendering that changes. I'll try to find a workaround then, by using my own stack. If you want to implement this in JUCE (which should be very easy for you to do), I'd recommend having a look at that AGG page where it's described how it works (with code). What's important is that you do vertical hinting for optimum results. It makes a big difference.

[jules]

I've seen the AGG page before, and agree totally. It's always been something that I've meant to do, which is why I can say pretty confidently that what I suggested is the cleanest, simplest, and best way to achieve it.

My point was that it'd probably only take a couple of days and maybe ~200 lines of code to modify the juce codebase to do it my way. It sounds like you're writing huge amounts of code, as well as pulling in external dependencies for AGG (and freetype??), and unless you actually finished already, I can't see what you're gaining.

And beware of assuming that bitmaps are faster than edge tables. The whole rendering pipeline is written for edge-tables, and they're very very quick to draw. Since bitmaps don't give you any sub-pixel positioning, I presume you're also going to have to write some kind of bodge to handle that too, adding yet more complexity and bloat, and you may not actually get any measurable speed increase from it. You'll also have to write vast amounts of extra code to make it deal with gradient-filled text, etc., which you'd get for free with edge-tables.

[zamrate]

I've finished since a week, and ofcourse I use a few more bitmaps (3) for sub-pixel accuracy movement. I can't render gradient-filled text, correct, but don't need it. If that is needed I can just revert to JUCE's rendering. As you seem pretty confident that rendering edge tables is as fast as using bitmaps, I'll do that test for you, would really like to know if that is true.

Edit: I've just measured the performance, and it seems the bitmap approach is only slightly faster (about 20-50%), but since it uses 3 bitmaps (one for each colour), I assume that the EdgeTableRenderer would be slowed down too a bit if using LCD optimization (not sure though as you only need to apply the LCD optimization on the borders).

[zamrate]

It's been some time... Jules, is it now possible to exchange the renderer in JUCE with a custom one easily, so it applies to all cases (including offline rendering to Image contexts) ?
I remember I still had to hack a fair amount of lines in JUCE to get it work in the last version (but that's about from the time when I last posted in this thread).

[jules]

I can't remember what has changed since November, but I don't think I did anything specifically to help with this.

[TheVinn]

I suggested a simple change for templating and exposing some low level graphics internals, Jules you told me to remind you. I will try to dig it up.

[TheVinn]

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.

Can we please add an interface available on all platforms, for a virtual ComponentPeer function that allows overriding the creation of the LowLevelGraphicsContext ?