Graphics::drawHorizontalLine() broken on GIT head?


#1

Hello,

Using the current GIT head (after the iPhone update) drawHorizontalLine() seems to draw in the wrong place.

I have a scope that looks like this (using the GIT from 2009-09-25 1700hrs):

But with the GIT head the faint lines (drawn with drawHorizontalLine()) are in the wrong position:

The waveform is a bit fuzzier too, which is drawn using multiple calls to drawVerticalLine at each horizontal pixel position (not sure if this is related to other Graphics changes but not a major issue like this one). The text is brighter too, look perhaps like everything is drawn twice or perhaps the transparency is working differently.

This test illustrates the drawHorizontalLine problem:

class TestDrawHorizontalLine  : public Component      
{
public:
	TestDrawHorizontalLine () { }
	~TestDrawHorizontalLine () { }
		
	void paint (Graphics& g) {
		g.fillAll(Colours::black);
		g.setColour(Colours::white);
		int height = getHeight();
		int width = getWidth();
		g.drawHorizontalLine(height/2, 0, width);
	}	
};

class TestDrawLine  : public Component      
{
public:
	TestDrawLine () { }
	~TestDrawLine () { }
	
	void paint (Graphics& g) {
		g.fillAll(Colours::black);
		g.setColour(Colours::white);
		int height = getHeight();
		int width = getWidth();
		g.drawLine(0, height/2, width, height/2);
	}
};

class MainComponent  : public Component      
{
private:
	TestDrawHorizontalLine *test1;
	TestDrawLine *test2;
	
public:
	MainComponent () {
		addAndMakeVisible(test1 = new TestDrawHorizontalLine());
		addAndMakeVisible(test2 = new TestDrawLine());
	}
	
	~MainComponent () {
		deleteAllChildren();
	}
	
	void resized () {
		test1->setBounds(20, 20, 200, 200);
		test2->setBounds(240, 20, 200, 200);
	}
};

Both components should look about the same but the first one doesn’t look right. The vertical psoition of the line seems to be dependent on the parent component size.


#2

Hey Martin

I think Jules is on this one…

Last two posts here.
http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=4663

I just replaced all my drawHorizontalLine stuff with fillRect.
HTH


#3

The fonts are drawn directly by CoreGraphics now, so the gamma is a bit different.

I’m a little surprised that the vertical lines aren’t anti-aliasing as I’d expect them to - I’ll take a look at that for you.


#4

Ah thanks. Sorry about the drawHorizontalLine stuff, I admit I looked at the recent topics but didn’t do a search…


#5

Regarding the non-antialising - I tried using drawLine() instead with the same results. But turning off USE_COREGRAPHICS_RENDERING does fix it. I tried explicitly turning on anti aliasing for the context on each call and that had no affect. Perhaps the parent has AA disabled? But then again the text is antialiased ok…


#6

I need to dig around a bit to see what’s going on with those vertical lines, it’s very odd - I’ve used the same CoreGraphics rectangle method to draw vertical lines with no problem, so not sure why it’s coming out like that for you.


#7

Hi Martin - I did some tests with drawVerticalLine, but it all seems to be working perfectly - I don’t understand why you’d be seeing the aliasing. You weren’t drawing the vertical lines with drawLine, were you?


#8

sorry this probably should move to the Mac forum but since we started it here…

ok.

  • fresh clone of the juce git
  • build juce debug/release libs (BTW need to remove the 10.3 setting from the release target as 10.3 now longer supported, I also change the arch in the debug build to native arch only)
  • build an app with the following component:

[code]class MainComponent : public Component
{
public:
MainComponent () { }
~MainComponent () { }

void paint(Graphics &g)
{
	int start = 10;
	int end = 50;
	int fall = 5;
	float step = float(fall) / (end-start);
	float top = 10;
	float length = 20.25;
	
	for(int i = start; i < end; i++, top += step)
	{
		g.drawVerticalLine(i, top, top+length);
	}
}

};[/code]

Produces this:

I thought it MIGHT be 10.4/10.5 sdks - I’ve tried setting everything to 10.5 (project, base, deployment) - same result.

I’m on an intel macbook, 10.5.8, Xcode 3.1.4.


#9

BTW reverting back to svn r780 (which I have archved):


#10

That’s bizarre - I tried almost exactly the same thing, but got a perfect result.

I wonder if it’s some setting on your mac that’s different - perhaps somehow CoreGraphics has anti-aliasing turned off by default…?

If so, then explicitly turning it on would probably fix things:

CoreGraphicsContext (CGContextRef context_, const float flipHeight_) : context (context_), flipHeight (flipHeight_) { CGContextRetain (context); CGContextSetShouldSmoothFonts (context, true); CGContextSetShouldAntialias (context, true);


#11

Grrrr… I was hopeful on that one but no… still the same.

BTW I did a clean build (not falling into the juce_NativeIncludes.mm not being touched after changing one of its included files… that got me a couple of times before!) both Juce lib and the app.

Very weird. I’ll keep thinking too.


#12

Well, all that I can think is that maybe it’s something that’s being done by the graphics card, and some cards don’t anti-alias that particular type of rectangle… If you use fillRect instead (the float version), does that get also get snapped to the nearest pixel?


#13

(actually, ignore that last question, fillRect uses paths internally so isn’t relevant)


#14

all these in that inner loop from a few posts back do the same:

g.drawVerticalLine(i, top, top+length); g.drawLine(float(i), top, float(i), top+length); g.fillRect(float(i), top, 1.f, length);


#15

Weird. Why would things not be anti-aliased for you… I’ll try restarting my mac with the other graphics card enabled, in case that makes a difference…


#16

Hello,

Any more throughts on this (just tried the tip). I’m still having to set USE_COREGRAPHICS_RENDERING to 0 to get antialiasing. Anyone else got this problem, again I’m on 10.5.8?


#17

No idea at all, unless it’s a 10.5 thing - I don’t have a 10.5 installation any more to try. (Seems unlikely though… CoreGraphics has always been anti-aliased)

What kind of mac have you got?


#18

It’s a MacBook Pro 2.4GHz


#19

Same as mine. Well, I’ve no idea!


#20

I suppose it could be my work’s slightly non-standard install of Leopard. I’ve been reading the GeForce 8600M GT can be a bit fussy. Though I’m assuming it’s not the fatal problem for which Apple have extended the warranty where these chips are installed (mine is in the potentially promblematic batch I think). I’d expect other problems too.