Makes sense. I have attached a first go at the extended beCursorPrimitive. This new support code function must return 0 on failure:
ioSetCursorARGB(cursorBitsIndex, extentX, extentY, offsetX, offsetY)
I renamed it to ARGB because that's the Squeak Form layout. Alpha should be pre-multiplied, or does any platform need something else?
- Bert -
On Mar 1, 2007, at 23:01 , Andreas Raab wrote:
This sounds good to me. About the 128x128 restriction: Don't. If platforms do not support a particular size, then just fail the primitive and leave it to the image to sort out the problem. There is no reason to make such artificial restrictions these days.
Cheers,
- Andreas
Bert Freudenberg wrote:
Hi folks, for the OLPC XO with its 200 dpi screen we really need larger cursors than are currently supported in the VM. AFAIK, all major systems now support arbitrary 32 bit RGBA bitmaps as cursors. I'd suggest to simply extend primitiveBeCursor to allow 32 bit forms. An older VM would fail the primitive so action could be taken on the image side. The primitive would then call a new function, say ioSetCursorRGBA(cursorBitsIndex, width, height, offsetX, offsetY) IMHO, we don't really need to support other depths than 32, so we do not have to give that as parameter to ioSetCursorRGBA(). Not sure if we want to restrict cursor size to, say 128x128. What do the platforms support?
- Bert -