How to draw a one-pixel line??

I am having trouble with what seems to be a simple task:

I am trying to draw some vector images on a field of tiles.  The tiles
are always of integer sizes and can zoom over any reasonable range of
values.

The images themselves are vector images but they do not simply scale
up, as the tile gets bigger more detail is added.  (Yeah, I know I will
have to handle printing a bit differently.)

The problem I am having is with images composed entirely of vertical
and horizontal lines, black on a gray field.

The horizontal lines are fine, I get exactly what I want.  Vertical
lines are not working too well, though.  A lone vertical line is good
enough--two pixels of dark gray instead of one of black but it looks
close enough I did not even realize it was wrong until I got digging
into the case that is awful:

I have some stripes, some are black/background/background and others
are black/background.

With antialiasing on the ones with the black every three look fuzzy
and the closer ones just look like a blurry blob.

With it turned off I am getting a very clear image, albeit very wrong:
The three-step one produces dark gray/dark gray/background and the
two-step one simply produces a box of dark gray.

Everything is being drawn on a bitmap that is then put in a
picturebox.  The picturebox is in a panel that fills the form other
than a few controls on the right for manipulating the view.

The behavior would make sense if somehow I was drawing between pixels
on the y axis but all the DrawLines are being fed integer coordinates.

Loren Pechtel wrote:With no scaling/transformation whatsoever?

With no scaling/transformation whatsoever?  And you are displaying the
images also without any scaling or transformation of any sort?  How are
you determining what the exact pixel values are?

Your description sounds as though you are drawing on fractional
coordinates, in spite of your statement that you are not.  But it is also
possible you are simply not gathering your data correctly and that the
pixels in the bitmap are not what you think.

Without a concise-but-complete code example that reliably demonstrates
the problem, it is practically impossible to understand for sure what
problem you are seeing, never mind know what the fix would be.

For what it is worth, I tried to reproduce the issue you seem to be
describing, and could not.  When I start with an all-gray bitmap and draw
vertical lines into it spaced at various intervals, I always get pixels
exactly the color I drew where the lines are, with the original
background color where no lines were drawn.  See below for a
concise(ish)-but-complete code example demonstrating my test.

Pete


using System;
using System.Windows.Forms;
using System.Text;
using System.Drawing;

namespace TestVerticalLineDrawingSingleFile
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
}

public class Form1 : Form
{
private Image _img;
private Timer _timerBitmap = new Timer();
private Timer _timerRGB = new Timer();

public Form1()
{
InitializeComponent();

_UpdateImage();
_UpdatePixelRGB();

_timerBitmap.Interval = 1000;
_timerBitmap.Tick += (sender, e) =>
{
_timerBitmap.Enabled = false;
_UpdateImage();
};

_timerRGB.Interval = 1500;
_timerRGB.Tick += (sender, e) =>
{
_timerRGB.Enabled = false;
_UpdatePixelRGB();
};

textBox1.TextChanged += (sender, obj) =>
_ResetTimer(_timerBitmap);
textBox2.TextChanged += (sender, obj) =>
_ResetTimer(_timerBitmap);
textBox3.TextChanged += (sender, obj) =>
_ResetTimer(_timerRGB);
}

private void _UpdateImage()
{
Image imgNew = new Bitmap(128, 128);

using (Graphics gfx = Graphics.FromImage(imgNew))
{
int dx;

if (!int.TryParse(textBox1.Text, out dx))
{
dx = 1;
textBox1.Text = dx.ToString();
}

//gfx.PixelOffsetMode =
System.Drawing.Drawing2D.PixelOffsetMode.None;

When you create the Pen you are using to draw your line are you passing avalue

When you create the Pen you are using to draw your line are you passing a
value of -1 for the width? If not, do so.

wrote:My psychic powers must be off today, everything is blurry.

My psychic powers must be off today, everything is blurry. Can't see
the code, the size of the bitmap, the size of the picturebox,
properties
of the picturebox, the comments in the code, in fact, even the code!

On a guess, try making the window 1 pixel wider, see if anything
changes.

--
Geoff

You may get that kind of problem with some LCD monitors while being not inthe

You may get that kind of problem with some LCD monitors while being not in
the recommended resolution and, in those cases, that is a problem related to
hardware and your choice of resolution. As usual, your problem may be
something else, though.

Vanderghast, Access MVP

I agree it sounds exactly like fractional coordinates.

I agree it sounds exactly like fractional coordinates.  How do you
draw on fractional coordinates with integer variables, though?  There
is no float variable in any routine in the file that actually draws
anything.

I was hoping someone could point me in the right direction withouthaving to

I was hoping someone could point me in the right direction without
having to distill down an example.  While I have been programming a long
time I am new to C# so I figure I am probably making an elementary
mistake.


No effect.

wrote:Google kicked that one up already. Width = -1.

Google kicked that one up already.  Width = -1.

wrote:Native 1280x1024.

Native 1280x1024.

Loren Pechtel wrote:By drawing in an environment where coordinates given as

By drawing in an environment where coordinates given as integers are
scaling somehow.

I posted a code example that shows that in general, the problem you
describe does not occur.  Either your own code does something different,
or you are simply not observing the results correctly (i.e. you think
there is a problem when there is not).

In the latter case, obviously there is nothing to fix.  In the former
case, until you post a concise-but-complete code example that reliably
demonstrates the issue, there is no way to tell you how to fix your code.

Pete

I have to ask: are you absolutely positive you are actually

I have to ask: are you absolutely positive you are actually getting
different-colored pixels, or does it just LOOK that way. In other words,
have you saved your bitmap to disk and then loaded it into a graphics
application and increased the zoom so that you can see the individual
pixels?

Jeff Johnson wrote:To elaborate on this point: the code example I posted last

To elaborate on this point: the code example I posted last evening is
specifically designed to illustrate this point.  It provides for scaling
the image during presentation, as well as inspecting RGB values for any
specific pixel.

With the example, you can see that scaling the image by (for example)
200%, you get the aliasing behavior described by the OP, but the pixel
values are still exactly as he wants (i.e. 0,0,0 RGB where a black line
is drawn, 128,128,128 on the gray background where it was not).

Pete

I managed to reproduce it very easily:A form containing a panel that contains

I managed to reproduce it very easily:

A form containing a panel that contains a picture box.  Drawing:

Bitmap Image = new Bitmap(Box.ClientSize.Width
,Box.ClientSize.Height);
Pen Ink = new Pen(Color.Black, -1);
using (Graphics Paper = Graphics.FromImage(Image))
{
Paper.Clear(Color.LightGray);
for (int x = 2; x < Image.Width / 2; x += 2)
Paper.DrawLine(Ink, x, 0, x, Image.Height - 1);
for (int y = 2; y < Image.Height; y += 2)
Paper.DrawLine(Ink, Image.Width / 2, y, Image.Width -
1, y);
}
Box.Image = Image;

Obviously the panel in this case is useless but I simply copied the
layout from the main code--in the main code there are some controls
off to the side and I use the panel to make the picture box take up
the whole form.

This code *SHOULD* draw one half of the screen with vertical lines and
one half with horizontal.  I am getting a gray mass on the left and the
expected behavior on the right.

wrote:When stripes turn into a blob instead it is quite obvious.

When stripes turn into a blob instead it is quite obvious.  While I was
working on features other than stripes I did not realize anything was
wrong, it was close enough.

There should be no scaling in my case--I want to add more detail asthe image

There should be no scaling in my case--I want to add more detail as
the image gets bigger and thus I am drawing it at the exact size I want
(or using scroll bars if the minimum acceptable size is bigger than
the window size.)

Loren Pechtel wrote:For what it is worth, I see what you say it *SHOULD* draw

For what it is worth, I see what you say it *SHOULD* draw when I execute
your routine.

--
Mike

What in the world is the difference then?

What in the world is the difference then?  How do I get it to draw
what you are seeing?

Loren Pechtel wrote:I suspect screen settings.

I suspect screen settings.  When I set my display settings really
poorly, then I see what you observe.  My normal settings are 1680x1050
32 bit color.

--
Mike

Loren Pechtel wrote:You've yet to establish it is _not_ drawing what Mike is

You've yet to establish it is _not_ drawing what Mike is seeing.

Visual inspection is not good enough.  Just because you have drawn a bitmap
a certain way, that is no guarantee it will be presented on the screen
that way.

Pete

Loren Pechtel wrote:So you say.

So you say.  But until you post a concise-but-complete code example,
it is not possible to know for sure there is not.  If I had a nickel for
every time someone asked a question, 100% certain that their description
of the situation was accurate, only to find it out was not...

And even if we establish there is no scaling in the _drawing_ of the
bitmap, there is still some possibility you have got some non-standard
system configuration that is meddling with the display on-screen.

Pete

3x 1280x1024 @ 32bit.

3x 1280x1024 @ 32bit.

Confirmed--it is drawn right, rendered wrong.

Confirmed--it is drawn right, rendered wrong.  It does not take blowing
it up to find, either.

Ok, I have been barking up the wrong tree.  What could be causing the
errant display?

Loren Pechtel wrote:Lots of things.

Lots of things.  With a concise-but-complete code example, we could at
least examine how you are using .NET and see whether there is anything
there that would cause the problem.  My guess is that it will turn out
to be a system configuration issue, with nothing at all to do with C# or
.NET (in which case, you will want to try to reproduce similar behavior
with a delivered application -- e.g. WordPad, Paint, etc. -- so that you
can repost your question in a different context, in a different forum).

Obviously, the first thing should be to review everything you are doing
in terms of presenting the bitmap on the screen, to see if you can find
any code or Designer settings you might have enabled that cause some
scaling to occur.

But without a concise-but-complete code example, there is really nothing
more we can offer here in terms of specifics.  And even with one, it is
entirely possible the answer will be "works fine on my machine...you
have a configuration problem".

One thing that does come to mind, along the "configuration" lines, is to
verify that your display is using digital input and is a discrete
display technology.  Specifically, LCD or plasma, using a DVI or HDMI
input.  If the signal is analog at any point, whether in transmission to
the display or in the display itself (e.g. CRT), then that could explain
the results right there.  I have never seen any analog output that does not
have at least a little blurring.

If you are using an analog signal to an LCD, you _might_ be able to
adjust the synchronization settings (most LCD monitors have an
image-registration controls) that allows you to get the image as clear
as possible.  That still will not provide the perfect image an all-digital
presentation would, but it could be good enough for your purposes.

Of course, if it _is_ a configuration issue -- that is, you have posted a
concise-but-complete code example and several people have confirmed it
works fine on other computers -- then one option is to just forget about
it, at least for the moment.  :)  After all, if the code is fine, you
can get on with the rest of the program rather than worrying about this
thing.  :)

Pete

I can see fine alternated lines on both on both 1280x1024 on a old

I can see fine alternated lines on both on both 1280x1024 on a old Dell
monitor, and 1920x1200 on a little newer Samsung SyncMaster. BUT if I change
the SyncMaster to 1280 x 1024, then I obtain ugly thick horizontal dark bars
alternating with fine light ones BECAUSE 1280x1024 IS NOT a recommended
resolution for it. Nothing to do with C#, DotNet, the driver, the video
card.  In fact, capturing the screen in 1280x1024, saving the file, changing
back the resolution to the recommended one by Samsung for that monitor, and
then displaying the captured bitmap in that new resolution... it shows ok,
the ugly pattern has disappear! Or sliding the image from the Samsung at
1280x1024 onto the Dell also at 1280x1024 (which is the recommended one for
that particular Dell), and the image is drawn as intended!

So my recommendation, try to set the resolution to the recommended one by
the MONITOR maker, and if you have lost the doc, try different resolutions
and keep the one which look best. No code involved.


Vanderghast, Access MVP

So then that would be a No.

So then that would be a No.

And from the other branch in this thread, it turns out that the bitmap WAS
being created correctly and simply LOOKED wrong on your screen. See how much
trouble you could have saved had you gone this route first?

If someone wish to get a fine pattern independent of the visible size,

If someone wish to get a fine pattern independent of the visible size, I
suggest to take a look at using a textured brush.


Vanderghast, Access MVP

wrote:My monitors are at their native resolution.

My monitors are at their native resolution.

I posted a very simple version albeit only describing how to make theform.

I posted a very simple version albeit only describing how to make the
form.  It misbehaved.

I saved the bitmap out of it and called it up with the Windows Picture
and Fax viewer, same monitor, everything was fine.


I made a new project.  I threw a panel on the main form, dragged it to
the edges.  I threw a picture box in it and dragged it to the edges. I
put the previously posted code into it.


I am getting on with the rest of it while trying to solve this.

This is a multi-part message in MIME format.------=_NextPart_000_0271_01CA5E20.

This is a multi-part message in MIME format.

------=_NextPart_000_0271_01CA5E20.AB452400
Content-Type: text/plain;
format=flowed;
charset="iso-8859-1";
reply-type=original
Content-Transfer-Encoding: 7bit

Try to change the resolution then.

Or use a texture brush.


Included, for those who would have a hard time to see what it is all about,
photos (from a digital camera) giving an idea of what happen with a
non-native
resolution. I need to capture the result with a camera, since a standard
'screen capture' captures what is in the video card, NOT what is rendered on
the monitor. The optical zoom of the camera I used was at about 100 mm of
the monitor, macro capture, no flash (Canon SD 790 IS).


Vanderghast, Access MVP



(...)

------=_NextPart_000_0271_01CA5E20.AB452400
Content-Type: image/jpeg;
name="Native.JPG"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="Native.JPG"

/9j/4AAQSkZJRgABAQEAYABgAAD/4QxoRXhpZgAASUkqAAgAAAAHAA8BAgAGAAAAYgAAABABAgAZ
AAAAaAAAADIBAgAUAAAAggAAABMCAwABAAAAAQALAAEQAwABAAAAQA4PAAIQAwABAAAAsAoMAGmH
BAABAAAAlgAAAAAAAABDYW5vbgBDYW5vbiBQb3dlclNob3QgU0Q3OTAgSVMA/zIwMDk6MTE6MDUg
MTQ6NDk6MDMAHwCaggUAAQAAABACAACdggUAAQAAABgCAAAniAMAAQAAAEAGQAAAkAcABAAAADAy
MjADkAIAFAAAACACAAAEkAIAFAAAADQCAAABkQcABAAAAAECAwACkQUAAQAAAEgCAAABkgoAAQAA
AFACAAACkgUAAQAAAFgCAAAEkgoAAQAAAGACAAAFkgUAAQAAAGgCAAAHkgMAAQAAAAIAQAAJkgMA
AQAAABAARVMKkgUAAQAAAHACAAB8kgcAyAgAAHgCAACGkgcACAEAAEALAAAAoAcABAAAADAxMDAB
oAMAAQAAAAEAASwCoAMAAQAAAEAOAAADoAMAAQAAALAKAAAOogUAAQAAAEgMAAAPogUAAQAAAFAM
AAAQogMAAQAAAAIAgD8XogMAAQAAAAIAgD8AowcAAQAAAAMAAAABpAMAAQAAAAAAAAACpAMAAQAA
AAAACAADpAMAAQAAAAAAAAAEpAUAAQAAAFgMAAAGpAMAAQAAAAAAABkAAAAAAQAAAKAAAAAcAAAA
CgAAADIwMDk6MTE6MDUgMTQ6NDk6MDMAMjAwOToxMTowNSAxNDo0OTowMwADAAAAAQAAAOoAAAAg
AAAAXwAAACAAAAAAAAAAAwAAAF8AAAAgAAAAOBgAAOgDAAAaAAEAAwAwAAAA8AMAAAIAAwAEAAAA
UAQAAAMAAwAEAAAAWAQAAAQAAwAiAAAAYAQAAAAAAwAGAAAApAQAAAYAAgAcAAAAsAQAAAcAAgAW
AAAA0AQAAAgABAABAAAAxEMPAAkAAgAgAAAA6AQAAA0ABACcAAAACAUAABAABAABAAAAAAA2AgAA
AwAUAAAAeAcAACYAAwAwAAAAoAcAABMAAwAEAAAAAAgAABgAAQAAAQAACAgAABkAAwABAAAAAQAA
ABwAAwABAAAAAAAAAB0AAwAQAAAACAkAAB4ABAABAAAAAAUAAR8AAwBFAAAAKAkAACIAAwDQAAAA
sgkAACMABAACAAAAUgsAACcAAwAIAAAAWgsAACgAAQAQAAAAYgsAANAABAABAAAAAAAAAC0ABAAB
AAAAAAAAAAAAAABgAAEAAAADAAAAAAAAAAQA//8BAAAAGgAAAAAAAAAAAEBGBQADAAUgAAD/f///
qEg4GOgDXwDAAP//AAAAAAAAAAAAAAEAAABADkAOAAAAAP//AAD/f/9/AAAAAP//ZAACADgY9wC5
AAAAAAAAAAAARAAAACABRwBfAOoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAIAAAAYQDvAAAA
AAAAAPoAAAAAAAAAAAAAAAAAAAABAAAAAACgAAAAAQBJTUc6UG93ZXJTaG90IFNENzkwIElTIEpQ
RUcAAAAAAEZpcm13YXJlIFZlcnNpb24gMS4wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAgAAABsDAACbAQAAIAEAAGAAAAAAAAAAJAEAAM4CAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACQBAADpAQAApf///wAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAAKAAAA
1wAAANcAAADXAAAAJAEAAEACAAD6////AAAAAAAAAADXAAAA1wAAAAAAAAAAAAAAAQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAQA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6AAAAWgIAAE0AAACFAQAAVQAA
AIf///8NAQAAAAAAAAAAAACH////DQEAADwAAACLAwAAswAAAPoAAAAAAAAAAAAAAAMAAAABAAAA
AAAAAAAAAAAHBAAACAQAAAAIAAAACgAAAAAAALMAAAD9AAAA+f///zIHAAC/CwAA2w0AADIHAAAA
AAAAAAAAAAAAAAABAAAAQAIAACQBAADXAAAAkwIAAPr///8DAAAAwAAAAAEAAAAAAAAAAAAAAAAA
AAAAAAAAxwIAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAEAAABvAgAAxwIAACgDAADAAAAAAQAA
AAAAAACo1v//AwAAAAEAAAC2AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABVAAAA
wAQAAOQAAADyAQAAXQAAANsAAAApAAAA+w8AAPsPAAABAAAAAQAAAAAAAAAAAAAAGgAAAA4AAAA/
MfK4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAgAJAAEAQA6wCmQA
ZAASAAAAAAAAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAACAAAQAAAAIAAgACAAIAAAAeAB4AMgCgAAAAAAAAAAAAigABAAAABAAIAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAoAEAAAAAEAAIAAEAAQCAAuABAAAAAAAAAAAAAAgAgAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAgAAQAAAAAA+4pQPNjaHRs70YmQ2Ha+YklJKgCy
AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKo3APEAAACAvykAtQAAAEAO
AABADgAA/9sAQwACAgICAgECAgICAwICAwMGBAMDAwMHBQUEBggHCQgIBwgICQoNCwkKDAoICAsP
CwwNDg4PDgkLEBEQDhENDg4O/9sAQwECAwMDAwMHBAQHDgkICQ4ODg4ODg4ODg4ODg4ODg4ODg4O
Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O/8AAEQgAoAAYAwEiAAIRAQMRAf/EAB8AAAEF
AQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFB

Last note, the include pictures have been compressed to be acceptable in ang

Last note, the include pictures have been compressed to be acceptable in a
ng message, and are not as 'evident' as the real pictures, but  while the
real pictures clearly show the space between the actual point of colors (and
are more uniform in the patterns), they are far too large to be included
here (around 4Meg each).

Vanderghast, Access MVP

Loren Pechtel wrote:You may find these links useful:http://www.yoda.arachsys.

You may find these links useful:
http://www.yoda.arachsys.com/csharp/complete.html
http://www.yoda.arachsys.com/csharp/incomplete.html
http://sscce.org/

In other words: you have yet to post a proper, useful
concise-but-complete code example.

wrote:it is native and when I save the image and load it with the

it is native and when I save the image and load it with the Windows
picture viewer it works.  Thus it is not the monitor but something
that is happening between the bitmap and the screen.


What good would that do?  (Not that it would work anyway--the stripes
are not always the same length as each other.)

Since this is graphical code how can I post something that wouldactually

Since this is graphical code how can I post something that would
actually compile?  The form itself is not going to be in the file.

wrote:For the purposes of a postable example, of course it could be.

For the purposes of a postable example, of course it could be.  Even
if it does not bear an resemblence to your application, it is often
helpful to go through this excercise even just to help you debug a
problem.  Here is a simple self contained form that compiles and draws
a bunch of vertical lines.  If this demostrated a bug, anyone else
here could run it and see the bug for themselves.

using System;
using System.Windows.Forms;
using System.Drawing;

namespace Example
{
public partial class ExampleForm : Form
{
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new ExampleForm());
}

public ExampleForm()
{
Paint +=3D new PaintEventHandler(ExampleForm_Paint);
}

void ExampleForm_Paint(object sender, PaintEventArgs e)
{
e.Graphics.Clear(Color.White);

for (int x =3D 0; x < ClientSize.Width; x +=3D 2)
{
e.Graphics.DrawLine(Pens.Black, x, 0, x,
ClientSize.Height);
}
}
}
}

Loren Pechtel wrote:You can do it the exact same way I did.

You can do it the exact same way I did.


It will if you put it there.

Pete

As you said, it is between the bitmap, which is ok, and the screen.

As you said, it is between the bitmap, which is ok, and the screen. That
betweeness includes the video card and the monitor driver. If you captured
the image, you read what is in the video card (I assume the monitor  memory
is write only in most cases), and it seems to prove that the image is ok
there too. So even if you are in native resolution, maybe you use generic
driver for the monitor, rather than the manufacturer one?  Furthermore, as
proven by the image I posted (which was captured by an external camera),
your code ***works*** fine. Can you try on another PC?


A texture can repeats itself  (wrap mode) to fill variable size area, rather
than being limited to enlarge its original 'pixels' to fit the area, and
will even fill convex area with matching the pattern (example, painting a
T, the texture in the steam is aligned with the texture in the flanges,
automatically... if you use the same brush to paint). See "Pro .Net 2.0
Graphics Programming", by Eric White, at Apress, pp49+



Vanderghast, Access MVP