Known problem with LinearGradientBrush?

  • Thread starter Thread starter _DD
  • Start date Start date
D

_DD

It seems that there is some odd interaction with LinearGradientBrush
that depends on positioning. A simple test:

---------

Rectangle Square = new Rectangle(.....);

in Paint:

LinearGradientBrush ShadeBrush = new LinearGradientBrush(
Square, Color.White, Color.Black, 90.0F, true);

g.FillRectangle(ShadeBrush, Square);

---------

This should draw a rectangle with White at the top, blending into
Black at the bottom.

This sometimes works as expected, but sometimes draws a one-
pixel BLACK line across the top edge.

Since the same rect is used for the gradient and for the Fill, you'd
think that nothing could go wrong here. Any ideas?

PS: To top it off, It seems position-sensitive. Changing the Y
position of the Square can cause this wto work correctly.
Also changing the vertical size of the Square object can make thiis
display correctly.
 
It seems that there is some odd interaction with LinearGradientBrush
that depends on positioning.
Click to expand...

Try turning on the antialiasing. Are you using a rectangle represented
in float? How about a transform on the Graphics object in float? Those
could easily have a rounding/truncation issue, especially without
antialiasing enabled.
 
This is a known problem. A workaround is to make the brush area slightly
larger than the area to be filled. (1 pixel bigger)
--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
 
Try turning on the antialiasing. Are you using a rectangle represented
in float? How about a transform on the Graphics object in float? Those
could easily have a rounding/truncation issue, especially without
antialiasing enabled.
Click to expand...

I've tried float and int versions of the same. Same result. You'd
think that the int version should work.
 
On Thu, 11 Jan 2007 20:40:24 +0100, "Bob Powell [MVP]"
This is a known problem
Click to expand...

It's a Microsoft bug? Well, at least I only wasted a day and a half on
it (damn, damn, damn). Has anyone filed the bug with Microsoft? (They
don't seem to take those very seriously)

Having assumed that the MS library would have been debugged by now, I
ended up writing lots of test code, converting back and forth from
float to int, etc. Pretty tough debugging, given that the app uses
animation, and it was turning up seemingly at random.

From one test, I found that moving a drawn object from Y=249 to Y=250
introduced the black line. That magic number also changed when the
object's size was changed. Since the graphics in this case require
smooth animation of object position and size, the lines were popping
in an out all over the screen as the objects crossed these magical
borders (what determines that?). It looked horrible, of course.

I didn't turn up any mention of this artifact in google searches. (I
even checked your FAQ, Bob. You may want to add this)
. A workaround is to make the brush area slightly
larger than the area to be filled. (1 pixel bigger)
Click to expand...

I had tried inflating the brush, and it seemed to eliminate the random
line. But it introduced its own problems:

Some of the shaded areas get as narrow as 3 pixels (perspective-shrink
during animation). That means that a 1-pixel miss results in a very
visible 33% change in the outer color. This is not as ugly as the
black lines, but still a noticeable glitch.

And with the inflated brush, there's now no way to get a pure white or
pure black row of pixels on the outer edge of a 3 pixel wide object,
as the crossfade is already at 20% (1 pixel out of 5) when the brush
hits the object edge. But then the bug will pop in and randomly draw a
pure white or black edge.

--

Bob, have you worked with this enough to know:

Does this occur with other, nonlinear, gradient types? That could be
a workaround.

Does antialiasing fix this?

Is this a deeper problem than just two MS guys who didn't round in the
same direction? Early on, I tried writing my own gradient using a
series of Pens, but that seemed to do the same thing. That would
indicate a bug inherent to the internal coordinate mechanism.
 
Try turning on the antialiasing. Are you using a rectangle represented
in float? How about a transform on the Graphics object in float? Those
could easily have a rounding/truncation issue, especially without
antialiasing enabled.
Click to expand...

I simplified the test to just one integer rectangle and a gradient
brush that used that rectangle. The same integer rectangle is handed
to the gradient brush and to the FillRect. Pretty much what I quoted
in the original post. That's about as simple as you can get. No
transforms. No floats in the test.

I hooked up NumericUpDowns to change the position of the rectangle.
As the rectangle's position changes by one pixel, the black lines (or
bright white lines, depending) pop in an out of existence.

It's like quantum physics or something! Heisenberg's LinearGradient
theory. <g>

It does look like an odd bug in GDI+ internals. I'm surprised that
this is not documented somewhere. I'll check into antialiasing, but it
doesn't seem like it will help, given the simplicity of the test case.

Does anyone know if this happened in earlier GDI (non +)?
 
Hi,

_DD said:
It's a Microsoft bug? Well, at least I only wasted a day and a half on
it (damn, damn, damn). Has anyone filed the bug with Microsoft? (They
don't seem to take those very seriously)
Click to expand...

In the contrary, there is an excellent response from the Microsoft team
to these inputs from users. Please remember that WPF is a brand new
technology, released in November 2006, and that you must count with
childhood problems.

For bug reports, please refer to the MSDN WPF forum here:
http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=119&SiteID=1&PageID=0

Also of value, the WPF community site:
http://wpf.netfx3.com/

You may also want to contact people at Microsoft through their blog, for
example Karsten
http://blogs.msdn.com/karstenj/default.aspx

Greetings,
Laurent
 
Hi,



In the contrary, there is an excellent response from the Microsoft team
to these inputs from users. Please remember that WPF is a brand new
technology, released in November 2006, and that you must count with
childhood problems.
Click to expand...

Hi Laurent,

Thanks for your reply. I am glad to hear that the WPF team is on top
of things. However I have filed about 10 bug reports in the past,
mostly about VS2005. I have not yet seen a single one resolved. They
are usually dismissed as 'won't fix' or 'by design' (It's not a bug,
it's a feature?).

Some of the reported bugs were easy to reproduce, and were
subsequently reported by others--with similar dismissals.

So it probably depends on which team is handling fixes. I do hope MS
changes their policy though. After the frustration, I have stopped
filing bug reports. I just try to avoid the trouble spots. I suspect
that other developers have arrived at the same conclusion. I can't see
how that helps Microsoft in the long run.
 
Hi,

_DD said:
Hi Laurent,

Thanks for your reply. I am glad to hear that the WPF team is on top
of things. However I have filed about 10 bug reports in the past,
mostly about VS2005. I have not yet seen a single one resolved. They
are usually dismissed as 'won't fix' or 'by design' (It's not a bug,
it's a feature?).

Some of the reported bugs were easy to reproduce, and were
subsequently reported by others--with similar dismissals.

So it probably depends on which team is handling fixes. I do hope MS
changes their policy though. After the frustration, I have stopped
filing bug reports. I just try to avoid the trouble spots. I suspect
that other developers have arrived at the same conclusion. I can't see
how that helps Microsoft in the long run.
Click to expand...

Totally understand your frustration. I must say, we were lucky to have
rather good results with bug submissions (not WPF, in this case it was
IE). What we did was going through our regional Microsoft representative
(I work in german Switzerland, we went through Germany). We got a bug
fix a few weeks later. That was pretty good. Of course, working for
Siemens is an advantage.

That said, the WPF team is very very enthusiastic about their work
(well, they should ;-) so the response is excellent. I first contacted
them privately, and got answers to all my queries. If you follow the WPF
developers' blogs, and see what they work on, it's a great way to post
questions and follow-up.

Courage!
Laurent
 
Back
Top