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 - |
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 - > > |
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 |
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 ======================================================================== === |
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 - |
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 - |
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. |
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 |
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 |
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 - |
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 |
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 - |
Free forum by Nabble | Edit this page |