Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

StretchBlt corruption

248 views
Skip to first unread message

Dan Ritchie

unread,
May 10, 2003, 10:13:26 PM5/10/03
to
Hi all. I'm using the StretchBlt function and when I
scale my bitmap down, I see corruption in the image such
as black blocks, color banding, and odd patterns. All is
well when scaling up. This also only happens when under
NT based OS's and not 98.
Is there a patch for Windows somewhere that fixes this
problem or another API call that could be used?

Mike D Sutton

unread,
May 11, 2003, 11:51:03 AM5/11/03
to

On NT based OS', the default StretchBlt() mode is BLACKONWHITE whereas on
Win 98, the default StretchBlt() mode is COLORONCOLOR. To make both
operating systems draw the same, make a call to SetStretchBltMode() and pass
either COLORONCOLOR or HALFTONE. (The latter is higher quality but slower
and more computationally expensive.)
Hope this helps,

Mike


-- EDais --

- Microsoft Visual Basic MVP -
WWW: Http://www20.brinkster.com/EDais/
Work E-Mail: ED...@btclick.com
Other E-Mail: Mike....@btclick.com


Dan Ritchie

unread,
May 11, 2003, 2:04:01 PM5/11/03
to
Thanks. That got it. Now I wonder about this?
"SetBrushOrgEx must be called after setting the HALFTONE
mode to avoid brush misalignment."
What dose that do?
I'm using stretchblt in a paint program to blit the
modified pixels on to the screen as their being painted.
When the image is zoomed in or out, I get wiggling.

>.
>

Tomaz Koritnik

unread,
May 11, 2003, 5:46:07 PM5/11/03
to
Hi

What does brush has to do with StretchBlt? What do you mean by
"wiggling", tearing maybe?

Tomaz


"Dan Ritchie" <Dan_R...@Hotmail.com> wrote in message
news:001201c317e7$b378f9c0$a601...@phx.gbl...

Mike D Sutton

unread,
May 11, 2003, 5:52:17 PM5/11/03
to
> Thanks. That got it. Now I wonder about this?
> "SetBrushOrgEx must be called after setting the HALFTONE
> mode to avoid brush misalignment."
> What dose that do?
> I'm using stretchblt in a paint program to blit the
> modified pixels on to the screen as their being painted.
> When the image is zoomed in or out, I get wiggling.

Personally I've never experienced any brush alignment problems using
HALFTONE StretchBlt() mode but if you need to then you can re-set the brush
alignment with this:

***
POINT BrushOrg;
GetBrushOrgEx(hdc, &BrushOrg);
SetStretchBltMode(hdc, HALFTONE);
SetBrushOrgEx(hdc, BrushOrg.x, BrushOrg.y, NULL);
***

dan ritchie

unread,
May 11, 2003, 7:55:00 PM5/11/03
to
> What does brush has to do with StretchBlt?
It's in the StretchBlt docs. Says you MUST do this...
Frankly I don't know what it dose.

What do you mean by
>"wiggling", tearing maybe?
>

I mean wiggling. The areas that are being blitted to
don't quite match up with the original. It's like there
half a pixel off or something.

vipin

unread,
May 12, 2003, 1:59:31 AM5/12/03
to
Best way something can be answered tentatively is post
your source snippet and the image(Is it a dib on disk or
is it something created at runtime?).I as well as others
can compile and see for ourselves.Might be setting the
brush org could have solved your problem if your rop code
involves brushes.
thank you
vipin

>.
>

Mike D Sutton

unread,
May 12, 2003, 11:18:53 AM5/12/03
to
> It's in the StretchBlt docs. Says you MUST do this...
> Frankly I don't know what it does.

Unless you're using a pattern brush in the ternary ROP passed to
StretchBlt() there's little chance you'll experience any problems - To be
perfectly honest even after _trying_ to break the brush alignment by setting
the halftone stretch mode it wouldn't here at least under Win2K.

> I mean wiggling. The areas that are being blitted to
> don't quite match up with the original. It's like there
> half a pixel off or something.

I'd look into the way you're calculating the zoom area, you may have to
slightly overdraw to get the edges to match up properly.

Dan Ritchie

unread,
May 14, 2003, 8:41:02 PM5/14/03
to

Actually, the wiggling is caused because the scale seems
to be more of a hack than an accuage scale algorithm. It
dosen't help that the input can only be integer.

>.
>

0 new messages