Home » Eclipse Projects » GEF » setLineWidth in pixel units instead of model units ?
| setLineWidth in pixel units instead of model units ? [message #151732] |
Wed, 22 September 2004 18:27  |
Eclipse User |
|
|
|
Originally posted by: kvdijken.tiscali.nl
Is it possible to use some modus of setLineWidth() for PolyLine as 'width in
pixels' instead of 'width in modelunits' ?
I noticed that when I zoom a diagram, the width of my PolyLine get broader
and narrower. What I actually want, is to keep them allways 2 screen pixels
wide, regardless of zoom level. That is also closer to the (my) idea of
linestrings having infinite small width, at any zoom level.
Koen
|
|
|
| Re: setLineWidth in pixel units instead of model units ? [message #151750 is a reply to message #151732] |
Wed, 22 September 2004 22:18  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Open a feature request. We could set a flag on ScaledGraphics.
"Koen van Dijken" <kvdijken@tiscali.nl> wrote in message
news:cisftt$k17$1@eclipse.org...
> Is it possible to use some modus of setLineWidth() for PolyLine as 'width
in
> pixels' instead of 'width in modelunits' ?
>
> I noticed that when I zoom a diagram, the width of my PolyLine get broader
> and narrower. What I actually want, is to keep them allways 2 screen
pixels
> wide, regardless of zoom level. That is also closer to the (my) idea of
> linestrings having infinite small width, at any zoom level.
>
> Koen
>
>
>
>
|
|
|
| Re: setLineWidth in pixel units instead of model units ? [message #151806 is a reply to message #151750] |
Thu, 23 September 2004 08:47 |
| Eclipse User |
|
|
|
Originally posted by: kvdijken.tiscali.nl
I opened a feature request, number 74750.
Koen
Randy Hudson wrote:
> Open a feature request. We could set a flag on ScaledGraphics.
> "Koen van Dijken" <kvdijken@tiscali.nl> wrote in message
> news:cisftt$k17$1@eclipse.org...
> > Is it possible to use some modus of setLineWidth() for PolyLine as 'width
> in
> > pixels' instead of 'width in modelunits' ?
> >
> > I noticed that when I zoom a diagram, the width of my PolyLine get broader
> > and narrower. What I actually want, is to keep them allways 2 screen
> pixels
> > wide, regardless of zoom level. That is also closer to the (my) idea of
> > linestrings having infinite small width, at any zoom level.
> >
> > Koen
> >
> >
> >
> >
|
|
|
| Re: setLineWidth in pixel units instead of model units ? [message #152913 is a reply to message #151750] |
Tue, 05 October 2004 21:07 |
| Eclipse User |
|
|
|
Originally posted by: kvdijken.tiscali.nl
I put some time in it again to try your suggestion of setting a flag on
ScaledGraphics. I found out that my problem is caused by the zooming of an
image in which I draw my polygon. In the paint method of my Polygon class I
draw the polygon in an image, which I draw on the Graphics object supplied
as a parameter to the Paint method. I do this to introduce transparency.
Zooming increases the linewidth of the border of the polygon which is only
an (raster) image by now. When I dont draw the polygon in an image, but
directly on the Graphics object supplied to the paint method, the linewidth
of the border of the polygon stays the same, no matter what the zoom level
is.
It is understandable that zooming an image zooms everything in the image,
also the border of polygons, it is just a raster, not vectors.
My conclusion at this point is that constant linewidths when zooming,
combined with transparent polygons implemented by drawing the polygons in an
image, is an impossibility. Is this right? Is there no other way to get
transparent figures? Besides this issue, implementing transparence by
drawing in images takes a lot of cpu cycles.
Koen van Dijken
"Randy Hudson" <none@us.ibm.com> wrote in message
news:cistfj$cm3$1@eclipse.org...
> Open a feature request. We could set a flag on ScaledGraphics.
>
> "Koen van Dijken" <kvdijken@tiscali.nl> wrote in message
> news:cisftt$k17$1@eclipse.org...
>> Is it possible to use some modus of setLineWidth() for PolyLine as 'width
> in
>> pixels' instead of 'width in modelunits' ?
>>
>> I noticed that when I zoom a diagram, the width of my PolyLine get
>> broader
>> and narrower. What I actually want, is to keep them allways 2 screen
> pixels
>> wide, regardless of zoom level. That is also closer to the (my) idea of
>> linestrings having infinite small width, at any zoom level.
>>
>> Koen
>>
>>
>>
>>
>
>
|
|
|
| Re: setLineWidth in pixel units instead of model units ? [message #152938 is a reply to message #152913] |
Tue, 05 October 2004 21:37 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> I put some time in it again to try your suggestion of setting a flag on
> ScaledGraphics. I found out that my problem is caused by the zooming of an
> image in which I draw my polygon. In the paint method of my Polygon class
I
> draw the polygon in an image, which I draw on the Graphics object supplied
> as a parameter to the Paint method. I do this to introduce transparency.
>
> Zooming increases the linewidth of the border of the polygon which is only
> an (raster) image by now. When I dont draw the polygon in an image, but
> directly on the Graphics object supplied to the paint method, the
linewidth
> of the border of the polygon stays the same, no matter what the zoom level
> is.
>
> It is understandable that zooming an image zooms everything in the image,
> also the border of polygons, it is just a raster, not vectors.
>
> My conclusion at this point is that constant linewidths when zooming,
> combined with transparent polygons implemented by drawing the polygons in
an
> image, is an impossibility. Is this right? Is there no other way to get
It's impossible. Can you use XOR instead for transparency? It's always
fun to open an SWT bugzilla asking for transparency, etc. Maybe opengl will
be supported one day or GDI+.
> transparent figures? Besides this issue, implementing transparence by
> drawing in images takes a lot of cpu cycles.
>
> Koen van Dijken
>
>
>
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:cistfj$cm3$1@eclipse.org...
> > Open a feature request. We could set a flag on ScaledGraphics.
> >
> > "Koen van Dijken" <kvdijken@tiscali.nl> wrote in message
> > news:cisftt$k17$1@eclipse.org...
> >> Is it possible to use some modus of setLineWidth() for PolyLine as
'width
> > in
> >> pixels' instead of 'width in modelunits' ?
> >>
> >> I noticed that when I zoom a diagram, the width of my PolyLine get
> >> broader
> >> and narrower. What I actually want, is to keep them allways 2 screen
> > pixels
> >> wide, regardless of zoom level. That is also closer to the (my) idea of
> >> linestrings having infinite small width, at any zoom level.
> >>
> >> Koen
> >>
> >>
> >>
> >>
> >
> >
>
>
|
|
|
| Re: setLineWidth in pixel units instead of model units ? [message #152997 is a reply to message #152938] |
Wed, 06 October 2004 12:08 |
| Eclipse User |
|
|
|
Originally posted by: kvdijken.tiscali.nl
Well, when you know what is causing the trouble, the solution is closeby. I
managed to reach my goal (apart from optimizing to get is faster). I copied
ScaledGraphics (could not subclass because private zoom and no getZoom() in
ScaledGraphics), and added a few methods, most important method is
public void fillTransparentPolygon(PointList pointList, int alpha) {
PointList points = pointList.getCopy();
Rectangle size = points.getBounds().getCopy();
size.resize(-1, -1);
size.x *= zoom;
size.y *= zoom;
size.width *= zoom;
size.height *= zoom;
points.translate(-points.getBounds().x, -points.getBounds().y);
int[] pointArray = points.toIntArray();
for (int i = 0; i < pointArray.length; i++)
pointArray[i] *= zoom;
// Calculate the alpha mask. Draw the figure with a 1-bit
// color depth. This results in a mask for the image which
// we use as a source for our alpha mask. Remember that
// this is an expensive step. It might be usefull to
// experiment with a 8-bit colordepth and use an indirect
// palette. Draw in a color which result in a pixelvalue
// equal to alpha. Use the resulting image data as an alpha
// mask.
byte[] alphaData = new byte[size.width * size.height];
PaletteData paletteTemp = new PaletteData(new RGB[] {
new RGB(255, 255, 255), new RGB(0, 0, 0) });
ImageData dataTemp = new ImageData(size.width, size.height, 1,
paletteTemp);
Image imageTemp = new Image(Display.getCurrent(), dataTemp);
try {
GC gcTemp = new GC(imageTemp);
try {
gcTemp.setBackground(ColorConstants.black);
gcTemp.fillPolygon(pointArray);
ImageData data = imageTemp.getImageData();
int i = 0;
for (int y = 0; y < size.height; y++) {
for (int x = 0; x < size.width; x++) {
if (data.getPixel(x, y) == 1)
alphaData[i] = (byte) alpha;
else
alphaData[i] = 0;
i++;
}
}
} finally {
gcTemp.dispose();
}
} finally {
imageTemp.dispose();
}
// Now draw the polygon in full color with the
// alpha mask calculated in the previous step.
PaletteData paletteFinal = new PaletteData(0xFF, 0xFF00, 0xFF0000);
ImageData dataFinal = new ImageData(size.width, size.height, 24,
paletteFinal);
dataFinal.alphaData = alphaData;
Image imageFinal = new Image(Display.getCurrent(), dataFinal);
try {
GC gc = new GC(imageFinal);
try {
gc.setBackground(this.getBackgroundColor());
gc.fillPolygon(pointArray);
graphics.drawImage(imageFinal, size.x, size.y);
} finally {
gc.dispose();
}
} finally {
imageFinal.dispose();
}
}
This zooms the polygon to draw on the image before it is actually drawn. In
the overriden fillShape of the IFigure is the following code:
protected void fillShape(Graphics g) {
if (g instanceof SpatialGraphics && alpha != 255)
((SpatialGraphics) g).fillTransparentPolygon(getPoints(),alpha);
else
g.fillPolygon(getPoints());
}
I still might need to take the fractionalX and fractionalY into account.
Similar code is necessary for the border of the polygons, as well as for
polylines.
Next, to be able to use this subclassed Graphics class, I had to subclass
ScalableFreeformRootEditPart, ScalableFreeformLayeredPane and let them use
each other at the appropriate places.
In the attached files you can see the effect:
- 100.jpg is the original unzoomed display, three polygons in two layers,
each layer with a alpha of 128. The linewidth of the border of the polygons
is 1. Also there are three linestrings.
- old.jpg is the situation, but zoomed in. The image is drawn before it is
zoomed which gives ugly borderlines.
- new.jpg is with the above code.
The code is not very fast yet. To build the above scene takes about two
seconds on a 3 GHz machine. To draw one polygon, two similar actions to
initialize the alphaData array has to be done: once for the fill, one for
the border. Also, it might be possible to use a smart colorPalette which
result in an image which can be used right away as an alphaData array.
Koen van Dijken
"Randy Hudson" <none@us.ibm.com> wrote in message
news:cjv3sm$ol$1@eclipse.org...
>> I put some time in it again to try your suggestion of setting a flag on
>> ScaledGraphics. I found out that my problem is caused by the zooming of
>> an
>> image in which I draw my polygon. In the paint method of my Polygon class
> I
>> draw the polygon in an image, which I draw on the Graphics object
>> supplied
>> as a parameter to the Paint method. I do this to introduce transparency.
>>
>> Zooming increases the linewidth of the border of the polygon which is
>> only
>> an (raster) image by now. When I dont draw the polygon in an image, but
>> directly on the Graphics object supplied to the paint method, the
> linewidth
>> of the border of the polygon stays the same, no matter what the zoom
>> level
>> is.
>>
>> It is understandable that zooming an image zooms everything in the image,
>> also the border of polygons, it is just a raster, not vectors.
>>
>> My conclusion at this point is that constant linewidths when zooming,
>> combined with transparent polygons implemented by drawing the polygons in
> an
>> image, is an impossibility. Is this right? Is there no other way to get
>
> It's impossible. Can you use XOR instead for transparency? It's always
> fun to open an SWT bugzilla asking for transparency, etc. Maybe opengl
> will
> be supported one day or GDI+.
>
>> transparent figures? Besides this issue, implementing transparence by
>> drawing in images takes a lot of cpu cycles.
>>
>> Koen van Dijken
>>
>>
>>
>>
>> "Randy Hudson" <none@us.ibm.com> wrote in message
>> news:cistfj$cm3$1@eclipse.org...
>> > Open a feature request. We could set a flag on ScaledGraphics.
>> >
>> > "Koen van Dijken" <kvdijken@tiscali.nl> wrote in message
>> > news:cisftt$k17$1@eclipse.org...
>> >> Is it possible to use some modus of setLineWidth() for PolyLine as
> 'width
>> > in
>> >> pixels' instead of 'width in modelunits' ?
>> >>
>> >> I noticed that when I zoom a diagram, the width of my PolyLine get
>> >> broader
>> >> and narrower. What I actually want, is to keep them allways 2 screen
>> > pixels
>> >> wide, regardless of zoom level. That is also closer to the (my) idea
>> >> of
>> >> linestrings having infinite small width, at any zoom level.
>> >>
>> >> Koen
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Attachment: 100.JPG
(Size: 23.91KB, Downloaded 93 times)-
Attachment: new.JPG
(Size: 50.85KB, Downloaded 122 times) -
Attachment: old.JPG
(Size: 52.97KB, Downloaded 91 times)
|
|
|
| Re: setLineWidth in pixel units instead of model units ? [message #153007 is a reply to message #152997] |
Wed, 06 October 2004 12:15 |
| Eclipse User |
|
|
|
Originally posted by: kvdijken.tiscali.nl
Also when zoomed to very small sizes, it still looks good, see attached
small.jpg.
"Koen van Dijken" <kvdijken@tiscali.nl> wrote in message
news:ck0mu1$i06$1@eclipse.org...
> Well, when you know what is causing the trouble, the solution is closeby.
> I
> managed to reach my goal (apart from optimizing to get is faster). I
> copied
> ScaledGraphics (could not subclass because private zoom and no getZoom()
> in
> ScaledGraphics), and added a few methods, most important method is
>
>
> public void fillTransparentPolygon(PointList pointList, int alpha) {
> PointList points = pointList.getCopy();
>
> Rectangle size = points.getBounds().getCopy();
> size.resize(-1, -1);
>
> size.x *= zoom;
> size.y *= zoom;
> size.width *= zoom;
> size.height *= zoom;
>
> points.translate(-points.getBounds().x, -points.getBounds().y);
> int[] pointArray = points.toIntArray();
>
> for (int i = 0; i < pointArray.length; i++)
> pointArray[i] *= zoom;
>
> // Calculate the alpha mask. Draw the figure with a 1-bit
> // color depth. This results in a mask for the image which
> // we use as a source for our alpha mask. Remember that
> // this is an expensive step. It might be usefull to
> // experiment with a 8-bit colordepth and use an indirect
> // palette. Draw in a color which result in a pixelvalue
> // equal to alpha. Use the resulting image data as an alpha
> // mask.
> byte[] alphaData = new byte[size.width * size.height];
>
> PaletteData paletteTemp = new PaletteData(new RGB[] {
> new RGB(255, 255, 255), new RGB(0, 0, 0) });
> ImageData dataTemp = new ImageData(size.width, size.height, 1,
> paletteTemp);
> Image imageTemp = new Image(Display.getCurrent(), dataTemp);
> try {
> GC gcTemp = new GC(imageTemp);
> try {
> gcTemp.setBackground(ColorConstants.black);
> gcTemp.fillPolygon(pointArray);
>
> ImageData data = imageTemp.getImageData();
> int i = 0;
> for (int y = 0; y < size.height; y++) {
> for (int x = 0; x < size.width; x++) {
> if (data.getPixel(x, y) == 1)
> alphaData[i] = (byte) alpha;
> else
> alphaData[i] = 0;
> i++;
> }
> }
> } finally {
> gcTemp.dispose();
> }
> } finally {
> imageTemp.dispose();
> }
>
> // Now draw the polygon in full color with the
> // alpha mask calculated in the previous step.
> PaletteData paletteFinal = new PaletteData(0xFF, 0xFF00, 0xFF0000);
> ImageData dataFinal = new ImageData(size.width, size.height, 24,
> paletteFinal);
> dataFinal.alphaData = alphaData;
> Image imageFinal = new Image(Display.getCurrent(), dataFinal);
> try {
> GC gc = new GC(imageFinal);
> try {
> gc.setBackground(this.getBackgroundColor());
> gc.fillPolygon(pointArray);
> graphics.drawImage(imageFinal, size.x, size.y);
> } finally {
> gc.dispose();
> }
> } finally {
> imageFinal.dispose();
> }
> }
>
>
> This zooms the polygon to draw on the image before it is actually drawn.
> In
> the overriden fillShape of the IFigure is the following code:
>
>
> protected void fillShape(Graphics g) {
> if (g instanceof SpatialGraphics && alpha != 255)
> ((SpatialGraphics)
> g).fillTransparentPolygon(getPoints(),alpha);
> else
> g.fillPolygon(getPoints());
> }
>
> I still might need to take the fractionalX and fractionalY into account.
>
> Similar code is necessary for the border of the polygons, as well as for
> polylines.
>
> Next, to be able to use this subclassed Graphics class, I had to subclass
> ScalableFreeformRootEditPart, ScalableFreeformLayeredPane and let them use
> each other at the appropriate places.
>
> In the attached files you can see the effect:
>
> - 100.jpg is the original unzoomed display, three polygons in two layers,
> each layer with a alpha of 128. The linewidth of the border of the
> polygons
> is 1. Also there are three linestrings.
> - old.jpg is the situation, but zoomed in. The image is drawn before it is
> zoomed which gives ugly borderlines.
> - new.jpg is with the above code.
>
> The code is not very fast yet. To build the above scene takes about two
> seconds on a 3 GHz machine. To draw one polygon, two similar actions to
> initialize the alphaData array has to be done: once for the fill, one for
> the border. Also, it might be possible to use a smart colorPalette which
> result in an image which can be used right away as an alphaData array.
>
> Koen van Dijken
>
>
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:cjv3sm$ol$1@eclipse.org...
>>> I put some time in it again to try your suggestion of setting a flag on
>>> ScaledGraphics. I found out that my problem is caused by the zooming of
>>> an
>>> image in which I draw my polygon. In the paint method of my Polygon
>>> class
>> I
>>> draw the polygon in an image, which I draw on the Graphics object
>>> supplied
>>> as a parameter to the Paint method. I do this to introduce transparency.
>>>
>>> Zooming increases the linewidth of the border of the polygon which is
>>> only
>>> an (raster) image by now. When I dont draw the polygon in an image, but
>>> directly on the Graphics object supplied to the paint method, the
>> linewidth
>>> of the border of the polygon stays the same, no matter what the zoom
>>> level
>>> is.
>>>
>>> It is understandable that zooming an image zooms everything in the
>>> image,
>>> also the border of polygons, it is just a raster, not vectors.
>>>
>>> My conclusion at this point is that constant linewidths when zooming,
>>> combined with transparent polygons implemented by drawing the polygons
>>> in
>> an
>>> image, is an impossibility. Is this right? Is there no other way to get
>>
>> It's impossible. Can you use XOR instead for transparency? It's always
>> fun to open an SWT bugzilla asking for transparency, etc. Maybe opengl
>> will
>> be supported one day or GDI+.
>>
>>> transparent figures? Besides this issue, implementing transparence by
>>> drawing in images takes a lot of cpu cycles.
>>>
>>> Koen van Dijken
>>>
>>>
>>>
>>>
>>> "Randy Hudson" <none@us.ibm.com> wrote in message
>>> news:cistfj$cm3$1@eclipse.org...
>>> > Open a feature request. We could set a flag on ScaledGraphics.
>>> >
>>> > "Koen van Dijken" <kvdijken@tiscali.nl> wrote in message
>>> > news:cisftt$k17$1@eclipse.org...
>>> >> Is it possible to use some modus of setLineWidth() for PolyLine as
>> 'width
>>> > in
>>> >> pixels' instead of 'width in modelunits' ?
>>> >>
>>> >> I noticed that when I zoom a diagram, the width of my PolyLine get
>>> >> broader
>>> >> and narrower. What I actually want, is to keep them allways 2 screen
>>> > pixels
>>> >> wide, regardless of zoom level. That is also closer to the (my) idea
>>> >> of
>>> >> linestrings having infinite small width, at any zoom level.
>>> >>
>>> >> Koen
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>>
>
>
>
-
Attachment: small.JPG
(Size: 6.53KB, Downloaded 100 times)
|
|
| |
| Re: setLineWidth in pixel units instead of model units ? [message #153087 is a reply to message #153048] |
Wed, 06 October 2004 16:41 |
| Eclipse User |
|
|
|
Originally posted by: kvdijken.tiscali.nl
I have not done any measurements on that yet, but I guess the slowest part
must be the calculation of the alphaData array. It's a nested loop over the
width and height of the image. Especially for narrow and long polygons
(diagonally) with a square bounding box a lot of unnecessary work is done.
Koen
"Randy Hudson" <none@us.ibm.com> wrote in message
news:ck10dd$8el$1@eclipse.org...
> It's a workaround, but the performance is pretty unacceptible for most.
> Which part is taking the most time? Is it new Image(..), or
> drawImage(..)?
>
> "Koen van Dijken" <kvdijken@tiscali.nl> wrote in message
> news:ck0nbs$it2$1@eclipse.org...
>> Also when zoomed to very small sizes, it still looks good, see attached
>> small.jpg.
>>
>
>
|
|
|
| Re: setLineWidth in pixel units instead of model units ? [message #153095 is a reply to message #153087] |
Wed, 06 October 2004 17:24 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
I think there is a bug in your code. When creating the alpha data, you need
to consider the scanline pad for the current platform. So it may work on
windows, but not Motif.
It seems like it should be possible to render the polygon to an image, get
the imagedata, and use the rendered polygon's bytes to become the alpha
channel directly. You just have to setup the Image the right way.
"Koen van Dijken" <kvdijken@tiscali.nl> wrote in message
news:ck16us$mvf$1@eclipse.org...
> I have not done any measurements on that yet, but I guess the slowest part
> must be the calculation of the alphaData array. It's a nested loop over
the
> width and height of the image. Especially for narrow and long polygons
> (diagonally) with a square bounding box a lot of unnecessary work is done.
>
> Koen
>
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:ck10dd$8el$1@eclipse.org...
> > It's a workaround, but the performance is pretty unacceptible for most.
> > Which part is taking the most time? Is it new Image(..), or
> > drawImage(..)?
> >
> > "Koen van Dijken" <kvdijken@tiscali.nl> wrote in message
> > news:ck0nbs$it2$1@eclipse.org...
> >> Also when zoomed to very small sizes, it still looks good, see attached
> >> small.jpg.
> >>
> >
> >
>
>
|
|
|
Goto Forum:
Current Time: Sat Nov 09 23:11:46 GMT 2024
Powered by FUDForum. Page generated in 0.04029 seconds |
] 
Search
Help
Register
Login
Home
