Recent

Author Topic: a stretched timage returns -1 on canvas.pixels  (Read 9645 times)

jw

  • Full Member
  • ***
  • Posts: 120
a stretched timage returns -1 on canvas.pixels
« on: January 19, 2011, 11:05:35 pm »
the image.png is 640x480
my screen reslution is 1024x768

//the form is the screen width and height
     self.top:=0;
     self.left:=0;
     self.Height:=screen.height;
     self.width:=screen.width;
                              

background is a timage
//stretch my brackground across the form width like so
     background.top:=0;
     background.Left:=0;
     background.height:=self.height;
     background.width:=self.width;
     background.stretch:=true;
     background.picture.loadfromfile('image.png');
                      
now I want to position sprites across the form according to colored points on the background
the problem is any point beyond 640x480 returns a -1 rather then the pixel color!!! Even though the image stretches properly.
edit1.text:=inttostr(background.Canvas.Pixels[641,anything]); =-1
or
edit1.text:=inttostr(background.Canvas.Pixels[nything,481]); =-1

so is this a bug?

Can I make a tcustombitmap and do a stretchdraw and get the same thing without useing a timage and return the proper pixel info or will that suffer from the same problems??
« Last Edit: January 19, 2011, 11:10:43 pm by jw »

jw

  • Full Member
  • ***
  • Posts: 120
Re: a stretched timage returns -1 on canvas.pixels
« Reply #1 on: January 20, 2011, 12:46:31 am »
windows xp
freepascal 09.28.2 beta


ok the stretchdraw does work so there's a bug when asking the compiler to let the timage.stretch:=true; and grabbing pixel color from it.


background is a timage
backgroundimg is a tcustombitmap

     background.top:=0;
     background.Left:=0;
     background.height:=self.height;
     background.width:=self.width;

     //have to do a stretchdraw rather then saying
     //background.stretch:=true because even thoug it stretches
     //properly there's a bug so the pixel return -1 when we try to grab
     //pixel info greater then the loaded pucture size
     BackgroundImg.LoadFromFile(SetDirSeparators('util\tree.png'));
     background.Canvas.StretchDraw(Rect(0,0,Width,Height),backgroundimg);
                           

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2496
Re: a stretched timage returns -1 on canvas.pixels
« Reply #2 on: January 20, 2011, 12:07:18 pm »
The graphic in a TImage isn't stretched. It stays at the same size. By setting stretch:=true; you only tell the TImage component to draw the image stretched. The source graphic is untouched.
Since you loaded a 640x480 graphic, accessing pixels outside that range will result in illegal values.
If you want to access the stretched pixels data, you have to stretch the image yourself.
//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

jw

  • Full Member
  • ***
  • Posts: 120
Re: a stretched timage returns -1 on canvas.pixels
« Reply #3 on: January 20, 2011, 07:45:21 pm »
hello mark,

I figured that the timage isn't stretched,
but how does lazarus stretch the image in a timage without doing a stretchdraw??

Is it a copyrec? 

How does the image stretch accross the timage canvas without being drawn stretched??

I guess I want to see some code that will stretch an image like the timage.stretched:=true does so I can see the difference in how that code works verses a stretchdraw..


Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2496
Re: a stretched timage returns -1 on canvas.pixels
« Reply #4 on: January 21, 2011, 01:00:05 am »
TImage consists of 2 things
1: the graphic
2: the image component

The image is placed on a form and this component knows how to (stretch)draw the graphic. So the graphic itself isn't stretched. It is (stretch)drawn each time the Image needs to be painted.
//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

jw

  • Full Member
  • ***
  • Posts: 120
Re: a stretched timage returns -1 on canvas.pixels
« Reply #5 on: January 27, 2011, 05:03:05 pm »
ya there's a few oddities like useing the command
self.windowstate:=wsmaximied;

this sets the form to take the whole screen but when you ask for top left height width you get what it is at design time I should think it would retuen the actual size and position of the form which should be

top=0
left=0
width:screen width
height=screen height

but it doesn't

messing with the border style doesn't help either.  The timge does the same thig when stretched the image stretches but it's not really that big really hard to get a handle on it's that big but the values say it's not so as a programmer you end up codeing and stretching everything manually with draw / stretchdraw commands.

fabienwang

  • Sr. Member
  • ****
  • Posts: 449
  • Lazarus is the best
    • My blog
Re: a stretched timage returns -1 on canvas.pixels
« Reply #6 on: January 27, 2011, 05:29:48 pm »
jw, the top, left, width, and height values are not changed when you maximize a window, because it has to remember where it was when you demaximize it.
This is how the windows widgetset works (and maybe some other).
I'm using Arch Linux.
Known for: CPickSniff, OpenGrabby
Contributed to: LazPaint

jw

  • Full Member
  • ***
  • Posts: 120
Re: a stretched timage returns -1 on canvas.pixels
« Reply #7 on: January 28, 2011, 05:14:47 pm »
well that's very interesing FabienWang but I disagree the reason is due to windows wideget sets and others.  Did microsoft think it was effecient to not update the form variables if it's maximized and leave the original values for demaximize in a temp variable so I could get real values for my form? the test proves not.


I just tested this in VB6 and the VB form when maximized does return updated values so I think it's the way Lazarus is doing things.  It would be very tempting to do as you say FabienWang because on a maximized form you know the top and left =0 and the length and height = screen.length screen.height so why waist temp variable any good programmer should know this.  The problem is if I know this and emplement it in code I'm at war with the LCL itelf when the minimize maximize buttons are used or a screen resize takes place and I'm resizeing my sprites.


the original point of this thread is why is a stretched timage not returning pixel values for pixels I know are lit.  The answer is my original image wasn't that size that the lcl know how to stretch something but keeps all the data after the stretch to itself.  It does the same thing when it stretches the form for it's designed state to a maximized state.  If find it hard gto uderstand why it does this I wnat to work with the lcl not against it.
 
 

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2496
Re: a stretched timage returns -1 on canvas.pixels
« Reply #8 on: January 28, 2011, 06:30:01 pm »
well that's very interesing FabienWang but I disagree the reason is due to windows wideget sets and others.  Did microsoft think it was effecient to not update the form variables if it's maximized and leave the original values for demaximize in a temp variable so I could get real values for my form? the test proves not.
Microsoft doesn't update form variables. It only reports the top,left,right,bottom when you query for it. It is up to the LCL to decide if the top,left,width,heigt of a component (==form) is updated.
IMO the LCL should do this since you need to know the size for various reason

Quote
I just tested this in VB6 and the VB form when maximized does return updated values so I think it's the way Lazarus is doing things. 
the LCL is not VB. So the way the LCL handle things could be different than how VB handles this.

Quote
the original point of this thread is why is a stretched timage not returning pixel values for pixels I know are lit.  The answer is my original image wasn't that size that the lcl know how to stretch something but keeps all the data after the stretch to itself.
Then you still don't get what the TImage.Stretched property means.

Quote
It does the same thing when it stretches the form for it's designed state to a maximized state.  If find it hard gto uderstand why it does this I wnat to work with the lcl not against it.

I don't know why you think it does, since the LCL doesn't

if I read the top,left,widht,heigt of a miximized window, I get the updated values.
//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker