Home » Eclipse Projects » GEF » Need help with ZOOM implementation
| Need help with ZOOM implementation [message #51905] |
Thu, 02 January 2003 19:47  |
Eclipse User |
|
|
|
Originally posted by: hudsonr.us.eye-bee-em.com
There are some issues with implementing zoom. Imagine a figure located at
Rectangle (0, 0, 10, 10). This figure fills itself yellow, and has a single
pixel black border around it.
The border must be painted using: graphics.drawRectangle (0, 0, 9, 9)
At normal resolution, this rectangle completely fills the bounding box (and
also clip rectangle) of the figure. The rectangle occupies 10 pixels in
each direction. Now lets zoom to 400%. The figures bounding box grows to:
(0, 0, 40, 40),
but the border only grows to:
(0, 0, 36, 36),
so the rectangle occupies 37 pixels, not 40. This means that there are 3
pixels along the right and bottom edge that the figure "owns", but does not
paint on. Or even worse, the figure thinks it is not painting there because
it thinks it is safe to paint outside of its clip rectangle.
One solution is to add 1 to the width and height, perform the zoom, and then
subtract 1, leaving (0, 0, 39, 39), or exactly 40 pixels. But, there are
problems with this workaround. What if there is a line dividing the figure
into 2 parts:
graphics.drawLine(5, 0, 5, 9)
This line would be scaled to (20, 0, 20, 36), and therefore would no longer
touch the rectangle.
|
|
|
| Re: Need help with ZOOM implementation [message #51932 is a reply to message #51905] |
Thu, 02 January 2003 23:01  |
| Eclipse User |
|
|
|
Originally posted by: venku.boss.dreamsoft.com
On Thu, 02 Jan 2003 14:47:18 +0000, Randy Hudson wrote:
> There are some issues with implementing zoom. Imagine a figure located
> at Rectangle (0, 0, 10, 10). This figure fills itself yellow, and has a
> single pixel black border around it.
> The border must be painted using: graphics.drawRectangle (0, 0, 9, 9)
> At normal resolution, this rectangle completely fills the bounding box
> (and also clip rectangle) of the figure. The rectangle occupies 10
> pixels in each direction. Now lets zoom to 400%. The figures bounding
> box grows to:
> (0, 0, 40, 40),
> but the border only grows to:
> (0, 0, 36, 36),
> so the rectangle occupies 37 pixels, not 40. This means that there are
> 3 pixels along the right and bottom edge that the figure "owns", but
> does not paint on. Or even worse, the figure thinks it is not painting
> there because it thinks it is safe to paint outside of its clip
> rectangle.
>
I guess this arises from the fact that the zero end of the axes are
inclusive and the non-zero end of the axes are exclusive when considering
the border, but is inclusive in the case of the bounding box. So, I guess
using one scheme for both would solve the problem.
>
> One solution is to add 1 to the width and height, perform the zoom, and
> then subtract 1, leaving (0, 0, 39, 39), or exactly 40 pixels. But,
> there are problems with this workaround. What if there is a line
> dividing the figure into 2 parts:
> graphics.drawLine(5, 0, 5, 9)
> This line would be scaled to (20, 0, 20, 36), and therefore would no
> longer touch the rectangle.
|
|
|
| Re: Need help with ZOOM implementation [message #51958 is a reply to message #51905] |
Thu, 02 January 2003 23:06 |
| Eclipse User |
|
|
|
Originally posted by: venku.boss.dreamsoft.com
On Thu, 02 Jan 2003 14:47:18 +0000, Randy Hudson wrote:
> There are some issues with implementing zoom. Imagine a figure located at
> Rectangle (0, 0, 10, 10). This figure fills itself yellow, and has a single
> pixel black border around it.
>
> The border must be painted using: graphics.drawRectangle (0, 0, 9, 9)
>
> At normal resolution, this rectangle completely fills the bounding box (and
> also clip rectangle) of the figure. The rectangle occupies 10 pixels in
> each direction. Now lets zoom to 400%. The figures bounding box grows to:
> (0, 0, 40, 40),
> but the border only grows to:
> (0, 0, 36, 36),
> so the rectangle occupies 37 pixels, not 40. This means that there are 3
> pixels along the right and bottom edge that the figure "owns", but does not
> paint on. Or even worse, the figure thinks it is not painting there because
> it thinks it is safe to paint outside of its clip rectangle.
>
Correct me if I am wrong. My understanding is the that the pixels are
inclusive at the zero-end of the axes but are exclusive at the non-zero
end of the axes for figure, but the pixels are inclusive at both the ends
for the bounding box. This causes an offset on zooming. However, if the
same scheme is used in both the cases the offset would not arise, but then
it should be said that "figure occupies rectangle (0,0,9,9) and the border
of the figure is drawn as (0,0,9,9)" or "figure occupies rectangle
(1,1,10,10) and the border is drawn at (0,0,11,11)".
>
> One solution is to add 1 to the width and height, perform the zoom, and then
> subtract 1, leaving (0, 0, 39, 39), or exactly 40 pixels. But, there are
> problems with this workaround. What if there is a line dividing the figure
> into 2 parts:
> graphics.drawLine(5, 0, 5, 9)
> This line would be scaled to (20, 0, 20, 36), and therefore would no longer
> touch the rectangle.
|
|
|
| Re: Need help with ZOOM implementation [message #51983 is a reply to message #51958] |
Thu, 02 January 2003 23:13 |
| Eclipse User |
|
|
|
Originally posted by: hudsonr.us.eye-bee-em.com
"Venkatesh Prasad Ranganath" <venku@boss.dreamsoft.com> wrote in message
news:pan.2003.01.02.23.06.40.347778@boss.dreamsoft.com...
> On Thu, 02 Jan 2003 14:47:18 +0000, Randy Hudson wrote:
>
> > There are some issues with implementing zoom. Imagine a figure located
at
> > Rectangle (0, 0, 10, 10). This figure fills itself yellow, and has a
single
> > pixel black border around it.
> >
> > The border must be painted using: graphics.drawRectangle (0, 0, 9, 9)
> >
> > At normal resolution, this rectangle completely fills the bounding box
(and
> > also clip rectangle) of the figure. The rectangle occupies 10 pixels in
> > each direction. Now lets zoom to 400%. The figures bounding box grows
to:
> > (0, 0, 40, 40),
> > but the border only grows to:
> > (0, 0, 36, 36),
> > so the rectangle occupies 37 pixels, not 40. This means that there are
3
> > pixels along the right and bottom edge that the figure "owns", but does
not
> > paint on. Or even worse, the figure thinks it is not painting there
because
> > it thinks it is safe to paint outside of its clip rectangle.
> >
>
> Correct me if I am wrong. My understanding is the that the pixels are
> inclusive at the zero-end of the axes but are exclusive at the non-zero
> end of the axes for figure, but the pixels are inclusive at both the ends
No, the bounding box also excludes the non-zero end, so it is [0,10), where
"[" == inclusive.
The mismatch is with GC.drawRectangle, which is inclusive, hence [0, 9] ==
[0, 10) at 100%, but not at 200%, etc.
If you just do a fillRect() with the figure's bounds, there is not a problem
because fillRect is also [0, 10). The problem is only when using drawXxx().
> for the bounding box. This causes an offset on zooming. However, if the
> same scheme is used in both the cases the offset would not arise, but then
Right, I mention this below, the difference could be avoided, but there are
side-effects to this as well.
> it should be said that "figure occupies rectangle (0,0,9,9) and the border
> of the figure is drawn as (0,0,9,9)" or "figure occupies rectangle
> (1,1,10,10) and the border is drawn at (0,0,11,11)".
>
> >
> > One solution is to add 1 to the width and height, perform the zoom, and
then
> > subtract 1, leaving (0, 0, 39, 39), or exactly 40 pixels. But, there
are
> > problems with this workaround. What if there is a line dividing the
figure
> > into 2 parts:
> > graphics.drawLine(5, 0, 5, 9)
> > This line would be scaled to (20, 0, 20, 36), and therefore would no
longer
> > touch the rectangle.
>
|
|
|
| Re: Need help with ZOOM implementation [message #52061 is a reply to message #51905] |
Fri, 03 January 2003 16:25 |
| Eclipse User |
|
|
|
Originally posted by: hudsonr.us.eye-bee-em.com
Here is a picture that shows the problem. Notice that the "lighted" pixels
shown on the right side (at 200% zoom) do not touch the bounding box of the
figure.
Attachment: zoom.jpg
(Size: 24.39KB, Downloaded 93 times)
|
|
| | |
| Re: Need help with ZOOM implementation [message #52329 is a reply to message #52275] |
Sun, 05 January 2003 18:41 |
 Bram Stieperaere
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Randy,
I think the algorithm should be something like (*both* for lines and boxes):
for both dimensions (hor/ver):
- get minimum and maximum
- scale minimum by simple multiplication with the zoom ratio
- scale maximum using the "add 1, multiply, then substract 1" procedure
the basic idea is to scale sizes, not coordinates:
e.g. the horizontal line (0,0)-(9,0) has a size (S) of 10
S = max - min + 1
after scaling with a ratio of e.g. 4 the size should be 40. more
general, if we scale with a ratio R, and denote the transform with T,
we expect T to satisfy
R*S = T(max)-T(min)+1
say
T(min) = R * min
then
T(max) = ?
after substitution we find that
R*(max - min + 1) = T(max) - R*min + 1
or
T(max) = R*(max +1) - 1
HTH
Bram
|
|
|
| Re: Need help with ZOOM implementation [message #52355 is a reply to message #52329] |
Sun, 05 January 2003 19:39 |
Bram Stieperaere
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
There is one problem with this: when min = max, we expect that T(min) =
T(max), otherwise horizontal or vertical lines could scale to diagonal
ones. It would be better then to use T(max) only.
Bram
Bram Stieperaere wrote:
> Randy,
>
> I think the algorithm should be something like (*both* for lines and
> boxes):
>
> for both dimensions (hor/ver):
> - get minimum and maximum
> - scale minimum by simple multiplication with the zoom ratio
> - scale maximum using the "add 1, multiply, then substract 1" procedure
>
> the basic idea is to scale sizes, not coordinates:
>
> e.g. the horizontal line (0,0)-(9,0) has a size (S) of 10
>
> S = max - min + 1
>
> after scaling with a ratio of e.g. 4 the size should be 40. more
> general, if we scale with a ratio R, and denote the transform with T,
> we expect T to satisfy
> R*S = T(max)-T(min)+1
>
> say
> T(min) = R * min
>
> then
> T(max) = ?
>
> after substitution we find that
>
> R*(max - min + 1) = T(max) - R*min + 1
> or
> T(max) = R*(max +1) - 1
>
>
> HTH
>
> Bram
>
|
|
|
| Re: Need help with ZOOM implementation [message #52383 is a reply to message #52329] |
Mon, 06 January 2003 01:34 |
| Eclipse User |
|
|
|
Originally posted by: hudsonr.us.eye-bee-em.com
"Bram Stieperaere" <bram.stieperaere@skynet.be> wrote in message
news:3E187C47.7050100@skynet.be...
> Randy,
>
> I think the algorithm should be something like (*both* for lines and
boxes):
>
> for both dimensions (hor/ver):
> - get minimum and maximum
> - scale minimum by simple multiplication with the zoom ratio
> - scale maximum using the "add 1, multiply, then substract 1"
procedure
This doesn't work for the case when I am trying to draw a "V":
drawLine(0,0,5,5);
drawLine(5,5,10,0);
using your zoom approach, then end of the first line and the beginning of
the second line would no longer touch when zooming in.
> the basic idea is to scale sizes, not coordinates:
>
> e.g. the horizontal line (0,0)-(9,0) has a size (S) of 10
Are we sure about that assumption? A horizontal line (0,0,0,0) looks like
it has no length to me, but it appears as 1 pixel on the screen. I think
"line width" needs to be interpreted as "pen diameter". If I set linewidth
to 5, and draw a zero-length line of width 5, I get a 5x5 dot. Therefore,
the last pixel in a line (and also the bottom and right edge of drawRect)
are really caused by the linewidth.
>
> S = max - min + 1
>
> after scaling with a ratio of e.g. 4 the size should be 40. more
> general, if we scale with a ratio R, and denote the transform with T,
> we expect T to satisfy
> R*S = T(max)-T(min)+1
>
> say
> T(min) = R * min
>
> then
> T(max) = ?
>
> after substitution we find that
>
> R*(max - min + 1) = T(max) - R*min + 1
> or
> T(max) = R*(max +1) - 1
>
>
> HTH
>
> Bram
>
|
|
|
| Re: Need help with ZOOM implementation [message #52443 is a reply to message #52383] |
Mon, 06 January 2003 12:12 |
| Eclipse User |
|
|
|
Originally posted by: Bram.Stieperaere.REMOVEskynet.be
seems you'll have to base the algorithm on topological information then (if
you want to avoid scaling line thickness)
e.g. for each Figure determine whether one of its end points
is "on" or "touching" another Figure, then take in account the transform
should preserve this topology.
this could get tricky IMO.
Bram
"Randy Hudson" <hudsonr@us.eye-bee-em.com> wrote in message
news:avalsa$ola$1@rogue.oti.com...
> "Bram Stieperaere" <bram.stieperaere@skynet.be> wrote in message
> news:3E187C47.7050100@skynet.be...
> > Randy,
> >
> > I think the algorithm should be something like (*both* for lines and
> boxes):
> >
> > for both dimensions (hor/ver):
> > - get minimum and maximum
> > - scale minimum by simple multiplication with the zoom ratio
> > - scale maximum using the "add 1, multiply, then substract 1"
> procedure
>
> This doesn't work for the case when I am trying to draw a "V":
> drawLine(0,0,5,5);
> drawLine(5,5,10,0);
>
> using your zoom approach, then end of the first line and the beginning of
> the second line would no longer touch when zooming in.
>
> > the basic idea is to scale sizes, not coordinates:
> >
> > e.g. the horizontal line (0,0)-(9,0) has a size (S) of 10
>
> Are we sure about that assumption? A horizontal line (0,0,0,0) looks like
> it has no length to me, but it appears as 1 pixel on the screen. I think
> "line width" needs to be interpreted as "pen diameter". If I set
linewidth
> to 5, and draw a zero-length line of width 5, I get a 5x5 dot. Therefore,
> the last pixel in a line (and also the bottom and right edge of drawRect)
> are really caused by the linewidth.
>
> >
> > S = max - min + 1
> >
> > after scaling with a ratio of e.g. 4 the size should be 40. more
> > general, if we scale with a ratio R, and denote the transform with T,
> > we expect T to satisfy
> > R*S = T(max)-T(min)+1
> >
> > say
> > T(min) = R * min
> >
> > then
> > T(max) = ?
> >
> > after substitution we find that
> >
> > R*(max - min + 1) = T(max) - R*min + 1
> > or
> > T(max) = R*(max +1) - 1
> >
> >
> > HTH
> >
> > Bram
> >
>
>
|
|
|
Goto Forum:
Current Time: Mon Dec 30 16:38:11 GMT 2024
Powered by FUDForum. Page generated in 0.04046 seconds |
] 
Search
Help
Register
Login
Home
