A modest (?) 2D graphics proposal

Lawson English english at primenet.com
Sat Jun 19 21:10:35 UTC 1999


Someone jokingly mentioned QuickDraw GX in response to something I wrote.
Rather than wax eloquent about something that is not available
cross-platform and is going away on the Mac anyway, I'd like to throw an 
idea out to see if anyone thinks it workable.

Background:

Squeak 2D graphics uses the standard alpha channel transparency strategy
and standard Porter-Duff composite modes. The modes are encoded in a set of
5 bits (decimal 0-29) as described in the BitBlit documentation. This
leaves a LOT of room for enhancements...

My Proposal:

Create a new set of primitives that tests  the high-order bit of the
combinationRule and uses a new set of rules based lossely on the GX color
capabilities. These would  include flags to specify which color space to
manipulate an object in plus flags to specify which Porter-Duff composite
mode would be use for each color channel. Another flags would invert the
role of the source and destination pixels and other options.
See


<http://developer.apple.com/techpubs/quicktime/qtdevdocs/REF/refVectors.20.htm#refVec21>

<http://developer.apple.com/techpubs/quicktime/qtdevdocs/REF/refVectors.23.htm#pgfId=8543>

and so on for more details of GX's color handling.



There are 18 defined GX color transfer modes, which would require 5 bits 
to specify which mode for which color channel. Assuming that we want to
keep Alpha channel info intact in all color spaces, that would require up
to 5x5 bits of info (e.g. for manipulations with CYMKA).

That leaves 1 bit for reversing the destination and source pixels (in
effect drawing a shape *under* the destination image) and up to 16 possible
color spaces. I suggest that some rational subset of CMYKA, RGBA, HSVA,
HLSA, XYZA, YXYA, LUVA, LABA, YIQA, & GrayA color spaces be handled.

At the least, RGBA, CMYKA, HSVA, and GrayA should be included.


All of the above can be encoded in the "combinationRule" instance variable
without modifying any current source code or changing the default behavior
of Squeak 2D graphics in any way. The more high-level GX color options
would require changes that may or may not be acceptable, but the
"primitive" capabilities that I've described above should [mostly -some GX
modes require extra info that couldn't be encoded without extra variables]
be doable and provide far higher-level 2D color-graphics than what Squeak
has right now. 


While such options would make the Squeak drawing  a bit slower, the
overhead shouldn't be that noticeable when they are implemented in C,
especially when implemented with MMX/AltVec/equivalent optimizations. One
obvious universal optimization is to "unroll" the BitBlit primitive with a
"BitBlit4" call that draws 4 pixels at a time and similar calls. I didn't
see any such optimization when looking at the Squeak graphics primitives,
but I may well have missed it.

Comments? Criticisms? Advice?

Thanks in advance.

----------------------------------------------------------------------
Lawson English, immortalized in Web Literature:
<http://www.aaskolnick.com/junkyarddog/dictionary.htm>
----------------------------------------------------------------------





More information about the Squeak-dev mailing list