--- In [email protected], "swzoh" <[EMAIL PROTECTED]> wrote: > > --- In [email protected], "mockey_a" <mockey@> wrote: > > OK. I thought this over a bit and here is my approach: > > I'd try to avoid any dividing to avoid rounding mistakes and to get > > an exactly enlarged picture. > > So starting from the smallest I define a radius of pixels > > surrounding the pixel that the mouse is over: > > local nRadius=10 > > Then I define a zoom factor, e.g.: > > local nZoom=5 > > The width and height of the scanned square is then: nRadius*2+1 (+1 > > is the pixel that the mouse is over) > > I get the width and height of the zoomed square as: > > local nRect=(nRadius*2+1)*nZoom > > where every original pixel is 5x5 pixel big. > > > > Now the centered cursor is over the left top pixel of the enlarged > > pixel. Why? I think the problem is that the reference point of the > > scaling of the image is not its center but its left top. So I shift > > the zoomed picture half the zoom-factor up and left (OK, in case of > > a zoom factor of 5, I take 3), to get over the center of the zoomed > > pixel. This is my offset: > > local nOff=nZoom/2+1 > > which I also subtract from the width and height of the window to > > avoid a margin. So basically I get: > > > > hWnd.size(nRect-nOff,nRect-nOff) > > for(!mouseleft) > > hWnd.move(xmouse-nRadius*nZoom,ymouse-nRadius*nZoom) > > dll.call("StretchBlt|ui i i i i ui i i i i ui",;;+ > > hDC_TT,nOff*-1,nOff*-1,nRect,nRect,;;+ > > hDC_SC,xmouse-nRadius,ymouse-nRadius,;;+ > > nRadius*2+1,nRadius*2+1,0xCC0020) > > endfor > > > > Maybe still not 100 percent, but looks pretty right to me. > > Hmm... Interesting. I'll think about it.
It seems that there is a discrepancy in view of pixel: suppose we have (0,0) ~ (10,10) square 1) my point of view: it's 10x10 pixel (squares) 2) your point of view: it's 11x11 pixel (squares) I think it arose from the difference of view toward the representing coordinates (x,y) 1) I think it's a mathematical point 2) You seems to think it as a physical 1x1 pixel squre OK, then may object that the coordinate system should be discrete in my view as x/y always have integer values, so most points on the screen wouldn't have a coordinate. I think some 'floor' operation is applied here: the points inside (0,0) ~ (1,1) represented approximately as (0,0). Then, it looks like not much different from the second point of view. Yes, when mapping a point on the screen to the integer-based representing coordinate system. However, there is a big difference when mapping the representing coordinate (x,y) to a point on the screen: (0,0) goes to exactly 1 point in the first point of view, whereas to a fuzzy square in the second point of view. So, with 800x600 resolution: 1) my point of view: it consists of 801 (0 ~ 800) points and 800 rods, 601(0~601) points and 600 rods, along x/y axis respectively. 2) your point of view: it has a coordinate ranges (0,0) ~ (799,599) Both have the same number of pixel (squres) 800x600, OTOH. What do you think? Did I correctly represent your view? Sean Attention: PowerPro's Web site has moved: http://www.ppro.org Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/power-pro/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
