Hi.

>[0.  For horizontal and vertical lines, use rectangle fills.  These work 
right and are fast.]

I'm drawing the "area" between the graph of a function and the X axis... I 
hope I could do rectangle filling to speed it up. Nevertheless, it looks nice 
to draw a line of alpha fill under each point of the graph as it gets drawn.

>1.  A straightforward fix would be to modify the existing failure code for 
line drawing so that it will operate with the new alpha protocol.  However, 
even fixing this will not necessrily make translucent lines work right. If 
the pen size or shape is anything other than a 1x1 square, there will be 
overlap in the line, and the points of overlap will thus be drawn with an 
effectively greater alpha.

Some times this behavior can be desirable... for instance, suppose you 
trace the trajectory of a particle. When it moves slower, then the plot will get 
more opaque.

>2.  A simpler approach which also handles this problem correctly, is to 
draw the line into an off-screen buffer, and then copy that onto the screen 
with alpha, and this can also be done right now without a fix.

Oh, like a bitmap of what to draw with the proper color in each point and 
then alpha + copy it. Sometimes this is not fast enough (although it provides 
the ability to make more graph manipulation before alpha + copy and the 
result can be better)... for instance, suppose you're updating a big form... ouch!

>3.  Finally, we are gradually integrating Balloon into Morphic, and this 
should provide an even better solution with anti-aliasing and translucency in 
32, 16, and even 8 bits.  I'm inclined to wait for this integration before 
spending a lot of time on the old approach.

I've been looking at Balloon... I especially liked to see a method to draw 
polygonals!

>>I browsed the C code for the primitive.
>You can browse it even easier in BitBltSimulation, from which it was 
generated.

Ouch.

>>I don't know if translucency should be expected to work after all.
>YES, you should expect it to work! Put your display in 16-bit mode and 
play with it!

I expressed myself wrong... the colors were drawn ok on a 16 bit display, 
but they were shifted sometimes. As I didn't know why was the primitive 
failing, I thought that maybe it wasn't supposed to work but sometimes it managed 
to draw correctly.

>The one thing that doesn't work right is curve and polygon borders.  That 
I will fix very soon (using solution 2), and this may well solve your problem 
anyway, as you can then use an open polygon for lines.

You know, FormCanvas has just line:to:width:color but it really was missing 
line:to:width:color:withFirstPoint:... the ability to skip the first point 
was already there with drawFrom:to:withFirstPoint:, and that's all that's 
needed to draw polygons without writing the vertices twice. You can do it writing 
backwards. Suppose you have a collection of points, then all you have to do 
is

2 to: aCollection size do: [:each | aFormCanvas drawFrom: (aCollection at: 
each) to: (aCollection at: each - 1) withFirstPoint: each = aCollection size]

I added line:to:width:color:withFirstPoint: to FormCanvas for the function 
plotters I've been working on recently, to fix this very same problem for 
drawing polygons. 

And I've also recently shifted from Squeak 2.0 to 2.3. I'm so glad I can 
get surprised with Squeak all the time!!!

Andres.