[Cuis-dev] QuickDraw Regions and Morphic 3.

[LawsonEnglish]

> In Cuis, with anti aliased Vector Graphics, their application is more restricted, as in the pixels that lie in the anti aliased boundary between shapes, we use alpha blending between background and foreground. That means that those pixels actually belong to both of them.

That’s an interesting issue. How does one handle dirty region clipping if that is is done with windowing, or does alpha blending apply only to graphics within a window?

Regions originally were developed to handle clipping for overlapping windows and then people found myriad uses for them such as hit-testing in menus, or games, and speeding up drawing in layers in limited memory where you really didn’t have the memory to maintain separate drawing layers in their own bitmaps waiting for compositing.

But as I said, or hinted at, they could be used anywhere that quadtrees (and by extension octrees and higher dimensions) are used as a way of partitioning discrete elements of a scene or set of arbitrary objects. The also have use as another way of dealing with sparse matrices.
 
I haven’t worked out all the details, but the hierarch of flags for end of scanline and end of 2D region should be extensible to N dimensions:

0x7fff, 0x7fff7fff, 0x7fff7fff7fff, etc and if you don’t need to worry about speed, literally any arbitrarily large number (including a VeryLargeInteger) could be used as the flag.

Whether or not this would extend them in a way useful for blending purposes with vector graphics, I can’t see, although you could, in principle,  define the “pixels” described in such a region to be the same width as the  ULP of the floating point system you use to calculate the vectors in the first place, and clip overlapping vectors at the theoretical limts of your floating point implementation.

Not suggesting that this is practical or useful, just pointing out that there’s no resolution limit to regions once you do away with the requirement that that the flags fit within a register.

Regions’ compression and boolean operations were optimized for scanline orientation, and while boolean operations would be problematic (you only have 50% (25%?) chance that two optimally stored regions are both oriented properly for efficient boolean operations if you allow  90 degree rotations for storage optimization), there may be other uses for them if stored that way (I’m still trying to wrap my head around many kilobytes of highly optimized 68000 assembler). 


The other thing I advocate is the implementation of QuickDraw GX’s Ink Object. Why are we still using the per-pixel porter-duff compositing 25 years after GX showed that there was a much more interesting graphical color space blending system available?

L


> On Jul 30, 2020, at 8:18 AM, Juan Vuletich <juan at jvuletich.org> wrote:
> 
> Hi Lawson,
> 
> Welcome to the Cuis community!
> 
> 
   […]
> I think Lisa Regions are a great idea. I'm sure they would have been extremely useful in a 1bpp system like the original Smalltalk-80. They are also useful for specifying areas to repair, or to react to events. If a single color is used for paint, they can fully specify a shape to be drawn, even if full color systems.
> 
> In Cuis, with anti aliased Vector Graphics, their application is more restricted, as in the pixels that lie in the anti aliased boundary between shapes, we use alpha blending between background and foreground. That means that those pixels actually belong to both of them.
> 
> But I'm sure we'll find good use for them.
> 
> Thanks!
> 
> -- 
> Juan Vuletich
> www.cuis-smalltalk.org
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> https://github.com/jvuletich
> https://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>