Bigger cursors needed

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Bigger cursors needed

Bert Freudenberg
 
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 -


Reply | Threaded
Open this post in threaded view
|

Re: Bigger cursors needed

Andreas.Raab
 
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 -
>
>
Reply | Threaded
Open this post in threaded view
|

Re: 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 -





bigCursor-bf.1.cs (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bigger cursors needed

johnmci
 
10.2 has a restriction of 16x16, but that is lifted in 10.3
I'll need to convert to the new NSCursor model. so will do that soon  
in  3.8.16 mac carbon vm.

If you can point to a image that enables the large cursor  
functionality so I can do testing that would be good.

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===


Reply | Threaded
Open this post in threaded view
|

Re: Bigger cursors needed

Bert Freudenberg
 

On Mar 3, 2007, at 22:31 , John M McIntosh wrote:

> 10.2 has a restriction of 16x16, but that is lifted in 10.3
> I'll need to convert to the new NSCursor model. so will do that  
> soon in  3.8.16 mac carbon vm.
>
> If you can point to a image that enables the large cursor  
> functionality so I can do testing that would be good.

Well, I can't test it without a real implementation. But this should  
work if the primitive works:

| form cursor |
form := Cursor normal asCursorForm as8BitColorForm.
form replaceColor: Color white with: (Color green alpha: 0.25).
form replaceColor: Color black with: (Color blue alpha: 0.5).
form := form asFormOfDepth: 32.
form := form magnify: (0@0 extent: 9@16) by: 3.
cursor := Cursor extent: form extent depth: 32.
form displayOn: cursor at: 0@0 rule: Form blend. "pre-multiply alpha"
form asMorph openInHand.
cursor show

The cursor rendering should match the morph (provided your world is  
set to 32 bpp). In particular, the green border should not appear  
grayish, if it is, your system does not use pre-multiplied alpha. We  
can still change the spec if this is the case.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: Bigger cursors needed

Bert Freudenberg
 

On Mar 4, 2007, at 13:18 , Bert Freudenberg wrote:

>
> On Mar 3, 2007, at 22:31 , John M McIntosh wrote:
>
>> 10.2 has a restriction of 16x16, but that is lifted in 10.3
>> I'll need to convert to the new NSCursor model. so will do that  
>> soon in  3.8.16 mac carbon vm.
>>
>> If you can point to a image that enables the large cursor  
>> functionality so I can do testing that would be good.
>
> Well, I can't test it without a real implementation. But this  
> should work if the primitive works:
>
> | form cursor |
> form := Cursor normal asCursorForm as8BitColorForm.
> form replaceColor: Color white with: (Color green alpha: 0.25).
> form replaceColor: Color black with: (Color blue alpha: 0.5).
> form := form asFormOfDepth: 32.
> form := form magnify: (0@0 extent: 9@16) by: 3.
> cursor := Cursor extent: form extent depth: 32.
> form displayOn: cursor at: 0@0 rule: Form blend. "pre-multiply alpha"
> form asMorph openInHand.
> cursor show
>
> The cursor rendering should match the morph (provided your world is  
> set to 32 bpp). In particular, the green border should not appear  
> grayish, if it is, your system does not use pre-multiplied alpha.  
> We can still change the spec if this is the case.

Err, forgot the offset. Also, much more configurable. Special! Only  
today! Choose your own source, scale, and colors! ;-)

| source scale colors form cursor |
source := Cursor read.
scale := 3.
colors := {Color blue alpha: 0.5. Color green alpha: 0.25}.
form := source asCursorForm as8BitColorForm.
form replaceColor: Color black with: colors first.
form replaceColor: Color white with: colors second.
form := form asFormOfDepth: 32.
form := form magnify: (source innerPixelRectFor: 0 orNot: false) by:  
scale.
form asMorph openInHand.
cursor := Cursor extent: form extent depth: 32.
form displayOn: cursor at: 0@0 rule: Form blend. "pre-multiply alpha"
cursor offset: (source offset - 0.5 * scale min: 0@0 max: cursor  
extent negated) asIntegerPoint.
cursor show

For testing the offset, "Cursor crossHair" might work best.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: Bigger cursors needed

Bert Freudenberg
 
Hi Ian,

I implemented ioSetCursorARGB() on X11 using the XRender extension,  
see attachment. It's a stand-alone test program that uses  
ioSetCursorARGB() to show a nicely colored cursor. This is not hooked  
up to the new primitive yet - can you do this soonish or should I  
work on a more complete patch?

- Bert -

On Mar 4, 2007, at 16:54 , Bert Freudenberg wrote:

> On Mar 4, 2007, at 13:18 , Bert Freudenberg wrote:
>
>> On Mar 3, 2007, at 22:31 , John M McIntosh wrote:
>>
>>> 10.2 has a restriction of 16x16, but that is lifted in 10.3
>>> I'll need to convert to the new NSCursor model. so will do that  
>>> soon in  3.8.16 mac carbon vm.
>>>
>>> If you can point to a image that enables the large cursor  
>>> functionality so I can do testing that would be good.
>>
>> Well, I can't test it without a real implementation. But this  
>> should work if the primitive works:
>>
>> | form cursor |
>> form := Cursor normal asCursorForm as8BitColorForm.
>> form replaceColor: Color white with: (Color green alpha: 0.25).
>> form replaceColor: Color black with: (Color blue alpha: 0.5).
>> form := form asFormOfDepth: 32.
>> form := form magnify: (0@0 extent: 9@16) by: 3.
>> cursor := Cursor extent: form extent depth: 32.
>> form displayOn: cursor at: 0@0 rule: Form blend. "pre-multiply alpha"
>> form asMorph openInHand.
>> cursor show
>>
>> The cursor rendering should match the morph (provided your world  
>> is set to 32 bpp). In particular, the green border should not  
>> appear grayish, if it is, your system does not use pre-multiplied  
>> alpha. We can still change the spec if this is the case.
>
> Err, forgot the offset. Also, much more configurable. Special! Only  
> today! Choose your own source, scale, and colors! ;-)
>
> | source scale colors form cursor |
> source := Cursor read.
> scale := 3.
> colors := {Color blue alpha: 0.5. Color green alpha: 0.25}.
> form := source asCursorForm as8BitColorForm.
> form replaceColor: Color black with: colors first.
> form replaceColor: Color white with: colors second.
> form := form asFormOfDepth: 32.
> form := form magnify: (source innerPixelRectFor: 0 orNot: false)  
> by: scale.
> form asMorph openInHand.
> cursor := Cursor extent: form extent depth: 32.
> form displayOn: cursor at: 0@0 rule: Form blend. "pre-multiply alpha"
> cursor offset: (source offset - 0.5 * scale min: 0@0 max: cursor  
> extent negated) asIntegerPoint.
> cursor show
>
> For testing the offset, "Cursor crossHair" might work best.




ioSetCursorARGB.c (2K) Download Attachment
bigCursor-bf.1.cs (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bigger cursors needed

Bert Freudenberg
 
So I actually did it the whole way and am enjoying large colored  
hardware cursors here :) Works even with huge cursors filling the  
whole screen - any 32 bit form could be cursor, at least under X11  
with the Xrender extension.

I'm attaching my files:

* bigCursor-bf changeset for VMMaker which extends the beCursor  
primitive. Support code needs to implement
        ioSetCursorARGB(cursorBitsIndex, extentX, extentY, offsetX, offsetY)

* biggerCursor-bf changeset is a quick hack to enlarge the normal  
cursors by two, enable #biggerCursors to test (safe on older VMs, too)

* argbCursors.diff patch for platforms/unix relative to SVN trunk.  
You have to run "make" in platforms/unix/config yourself, the  
generated configure and aclocal are not in the patch.

The test code below works for me, too. Would be cool to get support  
for this into the other VMs :)

- Bert -

On Mar 20, 2007, at 18:48 , Bert Freudenberg wrote:

> Hi Ian,
>
> I implemented ioSetCursorARGB() on X11 using the XRender extension,  
> see attachment. It's a stand-alone test program that uses  
> ioSetCursorARGB() to show a nicely colored cursor. This is not  
> hooked up to the new primitive yet - can you do this soonish or  
> should I work on a more complete patch?
>
> - Bert -
>
> On Mar 4, 2007, at 16:54 , Bert Freudenberg wrote:
>
>> On Mar 4, 2007, at 13:18 , Bert Freudenberg wrote:
>> | source scale colors form cursor |
>> source := Cursor read.
>> scale := 3.
>> colors := {Color blue alpha: 0.5. Color green alpha: 0.25}.
>> form := source asCursorForm as8BitColorForm.
>> form replaceColor: Color black with: colors first.
>> form replaceColor: Color white with: colors second.
>> form := form asFormOfDepth: 32.
>> form := form magnify: (source innerPixelRectFor: 0 orNot: false)  
>> by: scale.
>> "form asMorph openInHand."
>> cursor := Cursor extent: form extent depth: 32.
>> form displayOn: cursor at: 0@0 rule: Form blend. "pre-multiply alpha"
>> cursor offset: (source offset - 0.5 * scale min: 0@0 max: cursor  
>> extent negated) asIntegerPoint.
>> cursor show
>>
>> For testing the offset, "Cursor crossHair" might work best.





bigCursor-bf.1.cs.gz (1K) Download Attachment
argbCursors.diff.gz (3K) Download Attachment
biggerCursors-bf.1.cs.gz (942 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bigger cursors needed

Ian Piumarta
In reply to this post by Bert Freudenberg
 
Hi Bert,

> I implemented ioSetCursorARGB() on X11 using the XRender extension,  
> see attachment. It's a stand-alone test program that uses  
> ioSetCursorARGB() to show a nicely colored cursor. This is not  
> hooked up to the new primitive yet - can you do this soonish or  
> should I work on a more complete patch?

I'm a little concerned that this will cause the entire vm-display-X11  
plugin to fail to load on any machine that doesn't have libXrender.  
Is there any way to implement this stuff without depending on  
Xrender?  Alternatively, are you absolutely sure every machine bigger  
than a wristwatch is guaranteed to have the Xrender extension?  
Alternatively, how about I add a 'configure' option that turns on  
this support explicitly?

Remember that (1) the OLPC isn't the only machine that uses an X11  
window and (2) most people download binaries with all of the  
dependencies screwed in as absolute requirements on their local  
machine for the VM to run properly.  Anything that we fix  
specifically for (1) must not degrade the experience or complicate  
life for (2).

Cheers,
Ian



Reply | Threaded
Open this post in threaded view
|

Re: Bigger cursors needed

Bert Freudenberg
 

On Mar 25, 2007, at 19:00 , Ian Piumarta wrote:

> Hi Bert,
>
>> I implemented ioSetCursorARGB() on X11 using the XRender  
>> extension, see attachment. It's a stand-alone test program that  
>> uses ioSetCursorARGB() to show a nicely colored cursor. This is  
>> not hooked up to the new primitive yet - can you do this soonish  
>> or should I work on a more complete patch?
>
> I'm a little concerned that this will cause the entire vm-display-
> X11 plugin to fail to load on any machine that doesn't have  
> libXrender.  Is there any way to implement this stuff without  
> depending on Xrender?  Alternatively, are you absolutely sure every  
> machine bigger than a wristwatch is guaranteed to have the Xrender  
> extension?  Alternatively, how about I add a 'configure' option  
> that turns on this support explicitly?
>
> Remember that (1) the OLPC isn't the only machine that uses an X11  
> window and (2) most people download binaries with all of the  
> dependencies screwed in as absolute requirements on their local  
> machine for the VM to run properly.  Anything that we fix  
> specifically for (1) must not degrade the experience or complicate  
> life for (2).

Good point. But I'm pretty sure Xrender is supported on any Linux  
nowadays - it is in the X server for close to 7 years now (since  
XFree86 4.0.1).


- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: Bigger cursors needed

Ian Piumarta
 
On Mar 25, 2007, at 10:30 AM, Bert Freudenberg wrote:

> Good point. But I'm pretty sure Xrender is supported on any Linux  
> nowadays

Darwin/Mac OS X?
{Free,Net,Open}BSD?
Solaris?
IRIX?
OSF/1?
HP/UX?
AIX?
Maemo?

> - it is in the X server for close to 7 years now (since XFree86  
> 4.0.1).

Which means it's probably a safe bet for Desktops, but what about  
tiny/embedded devices?

Maybe the command-line option to turn on detection/use is what's  
needed.  (I'm assuming your automated build can run configure with  
any options it wants.)

Cheers,
Ian



Reply | Threaded
Open this post in threaded view
|

Re: Bigger cursors needed

Bert Freudenberg
 
On Mar 25, 2007, at 19:52 , Ian Piumarta wrote:

> On Mar 25, 2007, at 10:30 AM, Bert Freudenberg wrote:
>
>> Good point. But I'm pretty sure Xrender is supported on any Linux  
>> nowadays
>
> Darwin/Mac OS X?
> {Free,Net,Open}BSD?
> Solaris?
> IRIX?
> OSF/1?
> HP/UX?
> AIX?
> Maemo?

Well, that's what autoconf is for, isn't it? But I don't know on what  
systems people run the stock VM so perhaps we do need to be more  
cautious. If you think autoconf is insufficient to cover this, we  
could rewrite the code using dlopen() to remove the static dependency.

>> - it is in the X server for close to 7 years now (since XFree86  
>> 4.0.1).
>
> Which means it's probably a safe bet for Desktops, but what about  
> tiny/embedded devices?
>
> Maybe the command-line option to turn on detection/use is what's  
> needed.  (I'm assuming your automated build can run configure with  
> any options it wants.)

Sure, that would be no problem. OTOH, I think we should support this  
by default if the system supports it, and not only for folks who  
compile their VM themselves.

- Bert -