[ wxwindows-Patches-1333356 ] wxBitmap::Rescale() caused assertion

[SourceForge.net]

Patches item #1333356, was opened at 2005-10-20 17:44
Message generated for change (Comment added) made by vadz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=309863&aid=1333356&group_id=9863

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GTK specific
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Chris Borgolte (chrisborgolte)
Assigned to: Robert Roebling (roebling)
Summary: wxBitmap::Rescale() caused assertion

Initial Comment:
Nasty assertion "Gdk-CRITICAL **: file gdkimage-x11.c:
line 685 (gdk_image_get_pixel): assertion `x >= 0 && x
< image->width' failed" was caused under certain
circumstances.

The only really change is at lines 439 and 440. The
calculated scaling was too high, so that tablex and
tabley could contain values == image->width (or
height), wich caused the assertion.

Sorry for the static_casts!



----------------------------------------------------------------------

>Comment By: Vadim Zeitlin (vadz)
Date: 2007-04-01 16:46

Message:
Logged In: YES 
user_id=71618
Originator: NO

There seems to be a bug in this code but I can't believe this is the
correct fix: if we want to rescale the bitmap to have twice the size surely
scx should be 2 and not 1.99xxx... 

It would be really useful to have a test case reproducing the bug, thanks.

----------------------------------------------------------------------

Comment By: Julian Smart (juliansmart)
Date: 2006-01-19 10:02

Message:
Logged In: YES 
user_id=59495

OK, thanks; I'll cheekily reassign this to Robert since I'm
not entirely sure about the scaling calculation.

----------------------------------------------------------------------

Comment By: Chris Borgolte (chrisborgolte)
Date: 2006-01-18 13:37

Message:
Logged In: YES 
user_id=860591

It's a while ago so i hope to remember right:

If you increment the width you will be sure that the scaling
you get as a result will (hopefully) never cause the value,
which means the result of scalingx*iterator_of_width or
scalingy*iterator_of_height, that is used in
gdk_image_get_pixel() to be image->width or greater.
The calculation that was done before had these results in
certain circumstances.

the casts:
When i submitted the patch i did remember that i wanted to
change the static_casts to the "old style" casts, because i
had the impression that wxWidgets mostly uses these type of
cast and i didnt want to break any style guidelines. That
was the reason for my excuse.

I hope these explanation is enough. I have no chance to take
a look at my changes in the code right now, cause I'm at
home in the moment.
Its really a while ago that i did this stuff. I use "my own"
bitmap handling right now, cause i have to draw really huge
compressed b/w tiffs and have to be able to print them with
transparent background for linux and windows, so i never did
more investigation in the wxWidgets bitmap handling for a while.

If you have further question, i will take a look at my code,
when i'm back at work.

hth
chris

----------------------------------------------------------------------

Comment By: Julian Smart (juliansmart)
Date: 2006-01-18 11:46

Message:
Logged In: YES 
user_id=59495

Hi,

Am i right in thinking that the only relevant changes in the
patch are:
+        float scx =
static_cast<float>(M_BMPDATA->m_width-1)/newx;
+        float scy =
static_cast<float>(M_BMPDATA->m_height-1)/newy;

? I don't understand the purpose of the changes of increment
operator (postfix to prefix) or the casts.

Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=309863&aid=1333356&group_id=9863