[Vm-dev] Bigger cursors needed

[Bert Freudenberg]

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 -



-------------- next part --------------
A non-text attachment was scrubbed...
Name: bigCursor-bf.1.cs
Type: application/octet-stream
Size: 3894 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20070302/e813e4ef/bigCursor-bf.1.obj
-------------- next part --------------