Arcs drawing problem on Windows

Hi all,

We use Graphics-Support for drawing basic shapes such as rounded rectangles and ellipses.

On linux, everything looks fine. However on Windows some curved parts of rounded rectangle seem to be slightly shifted.
Ellipses with outline > 2 pixels look even worse (see screenshots).

We believe a bug may be in Windows primitive 990 or 991 (see ScreenGraphicsContext>>primDisplayArcBBoxOrigin: originPoint extent: extentPoint startAngle: startAngle sweepAngle: sweepAngle)

Did anyone ever tried to draw an ellipse or rounded rectangle in HotDraw on Windows? Were you ever satisfied with the results?

Thanks for your comments.

Filip

There is a problem with the curves as well.  and the problem is more
visible when the line width more the 1. Try to build any Line graph in
the BGOK with the line width set to 2.  Chances are then some part of
the curve will look thinner then others

Steven Kelly wrote:

They probably told you that since it does not affect POLLOCK or the
BottomFeeder it is going to be fixed in the next century or so...

Sorry,

Could not resist

--Mark

OK, thanks for comments. We'll try to investigate the problem further.

F.

Hi list,

again on this problem... I've spent several hours with Filip (who posted the
first mail of this thread) investigating what's wrong with the ellipse drawing
algorithm.

Looking briefly through the VM sources we've found that VW uses GDI functions
Ellipse() and RoundRect() for drawing (in primitives 990 and 991). First we
tried calling Ellipse() (and its GDI+ DrawEllipse() counterpart) from .NET to
see whether this problem is a "native Windows" one. It is not, as expected.
Then we created a simple GDI interface in VW that calls DLLCC-connected
gdi32.dll Ellipse() function directly to make sure there is no trick in
between. Still smooth - see the attachment.

We also tried Steven's workaround but it seems to address a different issue.

The only thing we need is a device context handle (HDC) and we do the rest of
the job ourselves. This would impose an easy workaround but the #windowHandle
method (primitive 941) implemented in ApplicationWindow (returning window
handle from which HDC can be obtained) seems to have nothing to do with the
value returned by #key (in DisplaySurface), which is the default
implementation. The last actor here is #GetHDC: in Win95SystemSupport, which
returns a HDC for a given window handle (known as HWND).

Everything works fine but only with windows. There is apparently no way to
obtain a Pixmap HDC to draw into Pixmaps, which we use extensively. The only
solution seems to be a custom primitive which would be able to access the VM
internal HDC caches and play with Pixmaps directly. However, a custom VM in not
exactly what we want (but can live with).

We may give a try to drawing algorithms (like Bresenham's) written in Smalltalk
but we expect a big slowdown here. Maybe in the future we'll switch to Jun and
its OpenGL graphics but OpenGL may not be installed (especially on X11 boxes)
which limits a bit (and we would also have to reimplement a big part of GF/ST
which we use now).

We are creating a tool that allows the user to display and draw diagrams of
various kinds and it's targeted mainly on the Windows platform - this visual
bug discourages our users. Is please anyone out there having some smart idea
before we start hacking the VM?

Thanks for any help,
Martin

> We also tried Steven's workaround but it seems to address a
> different issue.

Yes, that workaround addresses ellipse fills, and has no effect on the outlines (arcs).

> We may give a try to drawing algorithms (like Bresenham's) written
> in Smalltalk but we expect a big slowdown here.

We switched to using our own algorithm for rounded rectangles, because of the same problem you saw: the rounded corners were not lining up with the straight edges. There was a performance hit with doing it in Smalltalk, but not a bad one.

> we would also have to reimplement a big part of GF/ST which we use now

Good to see some more GF/ST users!

> We are creating a tool that allows the user to display and draw
> diagrams of various kinds and it's targeted mainly on the Windows
> platform - this visual bug discourages our users.

Yes, we're in the same boat with our product, MetaEdit+. Too much of our time goes on fighting against bugs in graphics support in VW and GF/ST, and too much is missing (like anti-aliased lines, alpha channel support...). We need the power of Smalltalk, but it's frustrating to see our productivity in major areas pulled back down to the level of Java by problems like these, which have been known for years.

Steve