L
Loren Pechtel
3x 1280x1024 @ 32bit.
3x 1280x1024 @ 32bit.
L
Loren Pechtel
Confirmed--it's drawn right, rendered wrong. It doesn't take blowing
it up to find, either.
Ok, I've been barking up the wrong tree. What could be causing the
errant display?
P
Peter Duniho
Loren said:
Lots of things. With a concise-but-complete code example, we could at
least examine how you're using .NET and see whether there's 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'll 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're 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's really nothing
more we can offer here in terms of specifics. And even with one, it's
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've never seen any analog output that doesn't
have at least a little blurring.
If you're using an analog signal to an LCD, you _might_ be able to
adjust the synchronization settings (most LCD monitors have an
"auto-adjust", but at the very least there should be manual
image-registration controls) that allows you to get the image as clear
as possible. That still won't 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've 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, youcan get on with the rest of the program rather than worrying about this
thing.
Pete
V
vanderghast
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
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
J
Jeff Johnson
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?
V
vanderghast
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
suggest to take a look at using a textured brush.
Vanderghast, Access MVP
L
Loren Pechtel
My monitors are at their native resolution.
L
Loren Pechtel
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.
Of course, if it _is_ a configuration issue -- that is, you've 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.
can get on with the rest of the program rather than worrying about this
thing.
I am getting on with the rest of it while trying to solve this.
V
vanderghast
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
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
L
Loren Pechtel
It's native and when I save the image and load it with the Windows
picture viewer it works. Thus it's not the monitor but something
that's happening between the bitmap and the screen.
What good would that do? (Not that it would work anyway--the stripes
aren't always the same length as each other.)
V
vanderghast
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
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
L
Loren Pechtel
But when I save the bitmap and load it with another program *ON THE
SAME MONITOR* it works.
Thus the system is messing with it (probably scaling it on the x-axis)
somewhere between the bitmap and the screen.
I have a panel on the form, in the panel a picturebox and the image is
put in the picturebox. This is because there is a minimum size the
image must be in order to convey needed information, if I have more
space available than that I try to fill it with optional information
rather than let it go to waste.
I'll have a look, although all the texture work is done so I probably
won't touch it.
P
Peter Duniho
Loren said:
Sure. And that could be somewhere in your program, or somewhere later
down the line.
Until you post a concise-but-complete code example that reliably
reproduces the problem, there's no way anyone here can tell you for sure
whether it's your program that has a bug, or some configuration issue
external to your own code.
Pete
V
vanderghast
indeed, if there is even one pixel of difference in size between the two
bitmaps sizes, a "BitBlt" (tile zoom to fit the space, GDI+ may have another
name for that function) may screw the whole one-to-one representation and
that is where a blur or other inconsistencies could easily show up.
A textured brush would take your available bit map and would not try to
resize it in any way, but rather repeat it (tile it) or crop it as required,
*if* the problem is one linked to the area size. If it is a problem linked
to a poor driver or of monitor resolution, though, it *may* not help,
indeed.
Vanderghast, Access MVP
bitmaps sizes, a "BitBlt" (tile zoom to fit the space, GDI+ may have another
name for that function) may screw the whole one-to-one representation and
that is where a blur or other inconsistencies could easily show up.
A textured brush would take your available bit map and would not try to
resize it in any way, but rather repeat it (tile it) or crop it as required,
*if* the problem is one linked to the area size. If it is a problem linked
to a poor driver or of monitor resolution, though, it *may* not help,
indeed.
Vanderghast, Access MVP