You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The scenario is this; I implement pinch-zoom by creating an expanded layout ie; 2x 3x (or whatever) the actual
size of the window, then set the gc's transform x,y appropriately to make the desired part of the expanded window
visible. The underlying window just thinks it's drawing into a really big window. This works remarkably well,
for the most part, because actual drawing operations outside the visible window are clipped away and take
no resources. ... for the most part...
The exception to this is in elaborate image loading/unloading/scaling code, which is on the wrong side
of the graphics interface. For example, if I have a 1000x1000 pixel image, that I'm going to draw as a 100x100
image outside the clipping region, I shouldn't need to load and scale it. In extreme cases, zoomed up view
of can require the entire zoo of giant images to be loaded unnecessarily.
I'd like to have the equivalent of this as a graphics primitive.
''''java
if (gc.isVisible(x,y,w,h))
{ // load and scale an image
gc.drawImage(image,x,y,w,h);
}
''''
Now for the complaint portion. I tried to implement this using existing graphics primitives, and this
is the closest I've come.
''''java
private float from[] = new float[3];;
public float[] transform(Graphics gc,int x,int y)
{ float to[] = new float[3];
int tx = gc.getTranslateX();
int ty = gc.getTranslateY()+actualY;;
from[0] = x+tx;
from[1] = y+ty;
gc.getTransform().transformPoint(from,to);
return to;
}
''''
"actualY" is the top margin of the window, but is not found anywere except as the magical initial value of getTranslateY()
The above is almost correct, but still differs from a "gold standard" implementation based on the
code in openjdk in some edge cases.
The text was updated successfully, but these errors were encountered:
The scenario is this; I implement pinch-zoom by creating an expanded layout ie; 2x 3x (or whatever) the actual
size of the window, then set the gc's transform x,y appropriately to make the desired part of the expanded window
visible. The underlying window just thinks it's drawing into a really big window. This works remarkably well,
for the most part, because actual drawing operations outside the visible window are clipped away and take
no resources. ... for the most part...
The exception to this is in elaborate image loading/unloading/scaling code, which is on the wrong side
of the graphics interface. For example, if I have a 1000x1000 pixel image, that I'm going to draw as a 100x100
image outside the clipping region, I shouldn't need to load and scale it. In extreme cases, zoomed up view
of can require the entire zoo of giant images to be loaded unnecessarily.
I'd like to have the equivalent of this as a graphics primitive.
''''java
if (gc.isVisible(x,y,w,h))
{ // load and scale an image
gc.drawImage(image,x,y,w,h);
}
''''
Now for the complaint portion. I tried to implement this using existing graphics primitives, and this
is the closest I've come.
''''java
private float from[] = new float[3];;
public float[] transform(Graphics gc,int x,int y)
{ float to[] = new float[3];
int tx = gc.getTranslateX();
int ty = gc.getTranslateY()+actualY;;
from[0] = x+tx;
from[1] = y+ty;
gc.getTransform().transformPoint(from,to);
''''
"actualY" is the top margin of the window, but is not found anywere except as the magical initial value of getTranslateY()
The above is almost correct, but still differs from a "gold standard" implementation based on the
code in openjdk in some edge cases.
The text was updated successfully, but these errors were encountered: