[quote=“zamrate”]Listen, you have the call stack there. I made it especially for you. And you can clearly see that fillRect() calls fillRectWithColour() there?!!
BTW not only paths are filled using the EdgeTableRenderer, everything is, even fonts, AFAIK.[/quote]
I see what you mean, you’re right. Fonts are paths so it makes sense they would render as anti-aliased polygons. But I’m puzzled as to why its going through the pixel blending code. It used to be the case that when a 100% opaque colour rectangle on integer coordinates with only a translation was drawn, it bypassed the blending and used a scanline renderer that just filled each row with solid colours. Maybe this has something to do with replaceExisting:
forcedinline void handleEdgeTablePixel (const int x, const int alphaLevel) const noexcept
{
if (replaceExisting)
linePixels[x].set (sourceColour);
else
linePixels[x].blend (sourceColour, (uint32) alphaLevel);
}
From your profile it looks like you’re going through blend() instead of set(). I would think that juce_GraphicsContext.cpp or some related part would set “replaceExisting” to true when the fill is a solid colour with 100% opacity. Try this, in:
juce_Graphics.cpp
void Graphics::fillRect (int x, int y, int width, int height) const
{
// passing in a silly number can cause maths problems in rendering!
jassert (areCoordsSensibleNumbers (x, y, width, height));
context->fillRect (Rectangle<int> (x, y, width, height), false);
}
Replace “false” with “true” in the call to fillRect() and post the profile and performance results.
I’m not on Mac right now (to profile), but all I can tell you is that the gfx performance problems I had have nothing to do with the blending per se.
The problem was definitely due to this whole clipping regions stuff and nothing else! As said, calling performAnyPendingRepaints() on the first 30 level meters, then on the next 30 level meters instantly solved the problem (12% cpu usage versus >20%).
See my comment regarding setPaintingIsUnclipped(). You should be using false (the default) not true, or else it will result in MORE rectangles in your RectangleList rather than less.
Regardless, your first profile shows PixelARGB::getARGB() as the top time consumer and that could be a consequence of replaceExisting == false.
I did try with both setPaintingIsUnclipped(true) or setPaintingIsUnclipped(false) on all level meters. Doesn’t change much in the whole. I think I’ve mentioned that a couple of times already in my previous posts.
As for the speed of the actual painting itself - my renderer is anyway 2x-4x faster than JUCE (I’ve implemented my own software renderer for fonts, blits, lines and rectangles). So I don’t even have to look at these bottlenecks (blending etc…).
Yep ignore that. I stepped completely through a call to Graphics::fillRect() with no transform, integer coordinates, and a solid colour fill. It made it all the way to EdgeTableFillers::SolidColour::handleEdgeTableLineFull() where it promptly called replaceLine() instead of blendLine().
Addressing the profile that shows PixelARGB::blend() at the top, there is no way that this could be happening if the only drawing taking place is solid colour rectangles without transforms. Something else is being drawn and going through the anti-aliased polygon renderer. This will of course be slower on account of the numerous clip rectangles as well as the blending.
