I'm wondering if the BitBlt should be part of the main stream VM and integrated into VMMaker, versus being a separate over-riding plugin?
Begin forwarded message:
Thanks, Damien!
Note, on Mac, the VM "Squeak 4.1.1beta2U" does not contain the new BitBlt plugin and hence the fonts are rendered without subpixel antialiasing. To enable this, drop the attached file (this is from the prototype one-click-image that Marcus produced some time ago) in the Resources folder in the VM app.
John, could this be included by default in the VMs you ship?
Cheers, Adrian
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
I assume that would make sense, but I don't know the details. I've attached the cs that Andrew sent to the mailing list on September 12, 2008.
Adrian
On May 18, 2009, at 18:57 , John M McIntosh wrote:
I'm wondering if the BitBlt should be part of the main stream VM and integrated into VMMaker, versus being a separate over-riding plugin?
Begin forwarded message:
Thanks, Damien!
Note, on Mac, the VM "Squeak 4.1.1beta2U" does not contain the new BitBlt plugin and hence the fonts are rendered without subpixel antialiasing. To enable this, drop the attached file (this is from the prototype one-click-image that Marcus produced some time ago) in the Resources folder in the VM app.
John, could this be included by default in the VMs you ship?
Cheers, Adrian
-- = = = = = ====================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
On Mon, May 18, 2009 at 09:57:19AM -0700, John M McIntosh wrote:
I'm wondering if the BitBlt should be part of the main stream VM and integrated into VMMaker, versus being a separate over-riding plugin?
Begin forwarded message:
Thanks, Damien!
Note, on Mac, the VM "Squeak 4.1.1beta2U" does not contain the new BitBlt plugin and hence the fonts are rendered without subpixel antialiasing. To enable this, drop the attached file (this is from the prototype one-click-image that Marcus produced some time ago) in the Resources folder in the VM app.
John, could this be included by default in the VMs you ship?
Cheers, Adrian
I don't really know the background on this, but assuming that this is an incremental change to BitBltSimulation, and that the changes are MIT licensed, and also that they are in need of a home, then adding them to the VMMaker package would be the right thing to do.
Andreas should have veto rights, as I believe that he is the author of BitBltSimulation.
I did a quick smoke test on a 64-bit Linux. I get a working VM but also some compiler warnings associated with the new changes. I can't say if there are functional issues, but I note that warnings about cast from pointer to integer are usually associated with VM crashes on a 64-bit platform, so this might be a problem.
- Dave
Output from a compile on Linux 64 bit:
gcc -g -O2 -DLSB_FIRST=1 -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN -I/home/lewis/squeak/VMM/build32 -I/home/lewis/squeak/VMM/platforms/unix/vm -I/home/lewis/squeak/VMM/platforms/Cross/vm -I/home/lewis/squeak/VMM/src/vm -c -o BitBltPlugin.o /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘copyLoop’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:1556: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘copyLoopNoSource’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:1728: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘copyLoopPixMap’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:1840: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘loadSurfacePlugin’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3064: warning: assignment makes integer from pointer without a cast /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3065: warning: assignment makes integer from pointer without a cast /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3066: warning: assignment makes integer from pointer without a cast /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘lockSurfaces’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3123: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3159: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘mergewith’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3202: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘partitionedRgbComponentAlphadestnBitsnPartitions’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3595: warning: left shift count >= width of type /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘primitiveWarpBits’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:4304: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:4335: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘queryDestSurface’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:4411: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘querySourceSurface’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:4429: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘rgbComponentAlphawith’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5046: warning: left shift count >= width of type /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘unlockSurfaces’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5730: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘warpBits’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5788: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5819: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘warpLoop’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5931: warning: cast to pointer from integer of different size
David T. Lewis wrote:
I don't really know the background on this, but assuming that this is an incremental change to BitBltSimulation, and that the changes are MIT licensed, and also that they are in need of a home, then adding them to the VMMaker package would be the right thing to do.
Andreas should have veto rights, as I believe that he is the author of BitBltSimulation.
The original author of BBSim is of course Dan. My only question about these changes is that I'm not sure what they're actually doing - it looks like rgbMul:with: except that it's been unrolled for various cases. Does anyone know what these changes are supposed to be doing, where they are used, and why rgbMul:with: is not sufficient?
Cheers, - Andreas
I did a quick smoke test on a 64-bit Linux. I get a working VM but also some compiler warnings associated with the new changes. I can't say if there are functional issues, but I note that warnings about cast from pointer to integer are usually associated with VM crashes on a 64-bit platform, so this might be a problem.
- Dave
Output from a compile on Linux 64 bit:
gcc -g -O2 -DLSB_FIRST=1 -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN -I/home/lewis/squeak/VMM/build32 -I/home/lewis/squeak/VMM/platforms/unix/vm -I/home/lewis/squeak/VMM/platforms/Cross/vm -I/home/lewis/squeak/VMM/src/vm -c -o BitBltPlugin.o /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘copyLoop’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:1556: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘copyLoopNoSource’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:1728: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘copyLoopPixMap’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:1840: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘loadSurfacePlugin’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3064: warning: assignment makes integer from pointer without a cast /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3065: warning: assignment makes integer from pointer without a cast /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3066: warning: assignment makes integer from pointer without a cast /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘lockSurfaces’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3123: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3159: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘mergewith’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3202: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘partitionedRgbComponentAlphadestnBitsnPartitions’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3595: warning: left shift count >= width of type /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘primitiveWarpBits’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:4304: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:4335: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘queryDestSurface’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:4411: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘querySourceSurface’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:4429: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘rgbComponentAlphawith’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5046: warning: left shift count >= width of type /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘unlockSurfaces’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5730: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘warpBits’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5788: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5819: warning: cast to pointer from integer of different size /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘warpLoop’: /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5931: warning: cast to pointer from integer of different size
On Tue, 2009-05-19 at 23:29 -0700, Andreas Raab wrote:
David T. Lewis wrote:
I don't really know the background on this, but assuming that this is an incremental change to BitBltSimulation, and that the changes are MIT licensed, and also that they are in need of a home, then adding them to the VMMaker package would be the right thing to do.
Andreas should have veto rights, as I believe that he is the author of BitBltSimulation.
The original author of BBSim is of course Dan. My only question about these changes is that I'm not sure what they're actually doing - it looks like rgbMul:with: except that it's been unrolled for various cases. Does anyone know what these changes are supposed to be doing, where they are used, and why rgbMul:with: is not sufficient?
The changes are Andy Tweens extensions for subpixel anti-aliassing for freetype. I'm not sure why rgbMul:with: isn't sufficient.
Bryce
Bryce Kampjes wrote:
On Tue, 2009-05-19 at 23:29 -0700, Andreas Raab wrote:
David T. Lewis wrote:
I don't really know the background on this, but assuming that this is an incremental change to BitBltSimulation, and that the changes are MIT licensed, and also that they are in need of a home, then adding them to the VMMaker package would be the right thing to do.
Andreas should have veto rights, as I believe that he is the author of BitBltSimulation.
The original author of BBSim is of course Dan. My only question about these changes is that I'm not sure what they're actually doing - it looks like rgbMul:with: except that it's been unrolled for various cases. Does anyone know what these changes are supposed to be doing, where they are used, and why rgbMul:with: is not sufficient?
The changes are Andy Tweens extensions for subpixel anti-aliassing for freetype. I'm not sure why rgbMul:with: isn't sufficient.
Do you know if he's around to shed some light on it?
Cheers, - Andreas
I've sent Andrew a mail to his hotmail.com account this morning but haven't received a reply so far.
Adrian
On May 20, 2009, at 22:32 , Andreas Raab wrote:
Bryce Kampjes wrote:
On Tue, 2009-05-19 at 23:29 -0700, Andreas Raab wrote:
David T. Lewis wrote:
I don't really know the background on this, but assuming that this is an incremental change to BitBltSimulation, and that the changes are MIT licensed, and also that they are in need of a home, then adding them to the VMMaker package would be the right thing to do.
Andreas should have veto rights, as I believe that he is the author of BitBltSimulation.
The original author of BBSim is of course Dan. My only question about these changes is that I'm not sure what they're actually doing - it looks like rgbMul:with: except that it's been unrolled for various cases. Does anyone know what these changes are supposed to be doing, where they are used, and why rgbMul:with: is not sufficient?
The changes are Andy Tweens extensions for subpixel anti-aliassing for freetype. I'm not sure why rgbMul:with: isn't sufficient.
Do you know if he's around to shed some light on it?
Cheers,
- Andreas
Adrian Lienhard wrote:
I've sent Andrew a mail to his hotmail.com account this morning but haven't received a reply so far.
Thanks. BTW, the reason why I'm asking is that I've been using the Truetype stuff in the past and I don't recall the need for bitblt mods. Is there a possibility that once upon a time there was a need for this and now there no longer is? The date on the changeset is 2004...
Cheers, - Andreas
On May 20, 2009, at 22:32 , Andreas Raab wrote:
Bryce Kampjes wrote:
On Tue, 2009-05-19 at 23:29 -0700, Andreas Raab wrote:
David T. Lewis wrote:
I don't really know the background on this, but assuming that this is an incremental change to BitBltSimulation, and that the changes are MIT licensed, and also that they are in need of a home, then adding them to the VMMaker package would be the right thing to do.
Andreas should have veto rights, as I believe that he is the author of BitBltSimulation.
The original author of BBSim is of course Dan. My only question about these changes is that I'm not sure what they're actually doing
- it looks like rgbMul:with: except that it's been unrolled for
various cases. Does anyone know what these changes are supposed to be doing, where they are used, and why rgbMul:with: is not sufficient?
The changes are Andy Tweens extensions for subpixel anti-aliassing for freetype. I'm not sure why rgbMul:with: isn't sufficient.
Do you know if he's around to shed some light on it?
Cheers,
- Andreas
On 20.05.2009, at 14:19, Andreas Raab wrote:
Adrian Lienhard wrote:
I've sent Andrew a mail to his hotmail.com account this morning but haven't received a reply so far.
Thanks. BTW, the reason why I'm asking is that I've been using the Truetype stuff in the past and I don't recall the need for bitblt mods. Is there a possibility that once upon a time there was a need for this and now there no longer is? The date on the changeset is 2004...
IIRC this is for sub-pixel font rendering support and was never officially integrated. With current bitblt you do nit git sub-pixel AA.
- Bert -
On 20.05.2009, at 14:33, Bert Freudenberg wrote:
On 20.05.2009, at 14:19, Andreas Raab wrote:
Adrian Lienhard wrote:
I've sent Andrew a mail to his hotmail.com account this morning but haven't received a reply so far.
Thanks. BTW, the reason why I'm asking is that I've been using the Truetype stuff in the past and I don't recall the need for bitblt mods. Is there a possibility that once upon a time there was a need for this and now there no longer is? The date on the changeset is 2004...
IIRC this is for sub-pixel font rendering support and was never officially integrated. With current bitblt you do nit git sub-pixel AA.
Err ... that should have been "you do not get" of course.
- Bert -
On Wed, May 20, 2009 at 2:50 PM, Bert Freudenberg bert@freudenbergs.dewrote:
On 20.05.2009, at 14:33, Bert Freudenberg wrote:
On 20.05.2009, at 14:19, Andreas Raab wrote:
Adrian Lienhard wrote:
I've sent Andrew a mail to his hotmail.com account this morning but haven't received a reply so far.
Thanks. BTW, the reason why I'm asking is that I've been using the Truetype stuff in the past and I don't recall the need for bitblt mods. Is there a possibility that once upon a time there was a need for this and now there no longer is? The date on the changeset is 2004...
IIRC this is for sub-pixel font rendering support and was never officially integrated. With current bitblt you do nit git sub-pixel AA.
Err ... that should have been "you do not get" of course.
What I love about typoes (I commit them at a huge rate being a hunt-and-peck typist) is what they say about the brain. In "nit" it could be that "i" was an accuracy error because "o" is right next to it, but that the "i" in "git" was somehow repeating the mistake even though "e" is on the other side of the keyboard. Or, as Andreas thinks, "nit git" came from thinking "bitblt". Or...
- Bert -
On 20.05.2009, at 15:09, Eliot Miranda wrote:
On Wed, May 20, 2009 at 2:50 PM, Bert Freudenberg <bert@freudenbergs.de
wrote:
On 20.05.2009, at 14:33, Bert Freudenberg wrote:
On 20.05.2009, at 14:19, Andreas Raab wrote:
Adrian Lienhard wrote: I've sent Andrew a mail to his hotmail.com account this morning but haven't received a reply so far.
Thanks. BTW, the reason why I'm asking is that I've been using the Truetype stuff in the past and I don't recall the need for bitblt mods. Is there a possibility that once upon a time there was a need for this and now there no longer is? The date on the changeset is 2004...
IIRC this is for sub-pixel font rendering support and was never officially integrated. With current bitblt you do nit git sub-pixel AA.
Err ... that should have been "you do not get" of course.
What I love about typoes (I commit them at a huge rate being a hunt- and-peck typist) is what they say about the brain. In "nit" it could be that "i" was an accuracy error because "o" is right next to it, but that the "i" in "git" was somehow repeating the mistake even though "e" is on the other side of the keyboard. Or, as Andreas thinks, "nit git" came from thinking "bitblt". Or...
If I ever need a shrink remind me to visit vm-dev first ...
- Bert -
Bert Freudenberg wrote:
On 20.05.2009, at 14:33, Bert Freudenberg wrote:
On 20.05.2009, at 14:19, Andreas Raab wrote:
Adrian Lienhard wrote:
I've sent Andrew a mail to his hotmail.com account this morning but haven't received a reply so far.
Thanks. BTW, the reason why I'm asking is that I've been using the Truetype stuff in the past and I don't recall the need for bitblt mods. Is there a possibility that once upon a time there was a need for this and now there no longer is? The date on the changeset is 2004...
IIRC this is for sub-pixel font rendering support and was never officially integrated. With current bitblt you do nit git sub-pixel AA.
Err ... that should have been "you do not get" of course.
The nit-git-bit-blit. I love it :-)))
- A.
Hi ,
The way the new bitBlt mode works is as follows.
The source bitmap is treated as a mask that contains the alpha values for each sub-pixel ( Red, Green, and Blue) individually.
There are 8 bits per sub-pixel, i.e. 24 bits per pixel.
The text foreground color is specified separately.
The alpha blending then takes place individually for each red, green & blue sub-pixel.
The formula is this...
dst.A = colorAlpha + (1 - colorAlpha) * dst.A dst.R = color.R * mask.R * colorAlpha + (1 - (mask.R * colorAlpha)) * dst.R dst.G = color.G * mask.G * colorAlpha + (1 - (mask.G* colorAlpha)) * dst.G dst.B = color.B * mask.B * colorAlpha + (1 - (mask.B* colorAlpha)) * dst.B
(color and colorAlpha are the text color, and its translucency, and apply to all pixels)
Using this formula, when black text is rendered on a white background, some of the pixels become 'coloured'. Typically, this results in red fringes on the left edges if a glyph, and blue fringes on the right. It is this colour fringing that 'fools the eye' into seeing sharper text on an LCD screen.
It is possible to replicate this effect by storing these 'coloured' glyphs, and rendering them using the existing bitBlt rules, and, for black text on a white background, it will give the correct result.
But, when these same glyphs are rendered to a black background (i.e. black text on a black background), the colour fringes in the resulting output are still visible. This is of course wrong; black text on a black background should result in a completely black result with no glyphs visible at all.
It would be possible to use the existing bitBlt modes if the background colour was known in advance. In this case glyphs could be created and cached for each foreground/background combination.
But, this is usually not the case. The background might be a gradiant , or an image, or some other pattern.
Furthermore, the text colour may not be black - it can be any colour with any level of translucency.
I believe that the existing bitBlt rules are insufficient to cover all these circumstances, but I am happy to be proved wrong :)
All the code I have written for the bitBlt mode and Freetype is MIT licensed.
(In addition, the new bitBlt mode applies gamma correction and deals with destination depths of less than 32, but that is not really relevant to this discussion)
Cheers,
Andy
.
Date: Wed, 20 May 2009 13:32:11 -0700 From: andreas.raab@gmx.de To: vm-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts
Bryce Kampjes wrote:
On Tue, 2009-05-19 at 23:29 -0700, Andreas Raab wrote:
David T. Lewis wrote:
I don't really know the background on this, but assuming that this is an incremental change to BitBltSimulation, and that the changes are MIT licensed, and also that they are in need of a home, then adding them to the VMMaker package would be the right thing to do.
Andreas should have veto rights, as I believe that he is the author of BitBltSimulation.
The original author of BBSim is of course Dan. My only question about these changes is that I'm not sure what they're actually doing - it looks like rgbMul:with: except that it's been unrolled for various cases. Does anyone know what these changes are supposed to be doing, where they are used, and why rgbMul:with: is not sufficient?
The changes are Andy Tweens extensions for subpixel anti-aliassing for freetype. I'm not sure why rgbMul:with: isn't sufficient.
Do you know if he's around to shed some light on it?
Cheers,
- Andreas
_________________________________________________________________ Beyond Hotmail — see what else you can do with Windows Live. http://clk.atdmt.com/UKM/go/134665375/direct/01/
Hi Folks,
Andrew Tween wrote:
...
It is possible to replicate this effect by storing these 'coloured' glyphs, and rendering them using the existing bitBlt rules, and, for black text on a white background, it will give the correct result.
But, when these same glyphs are rendered to a black background (i.e. black text on a black background), the colour fringes in the resulting output are still visible. This is of course wrong; black text on a black background should result in a completely black result with no glyphs visible at all.
It would be possible to use the existing bitBlt modes if the background colour was known in advance. In this case glyphs could be created and cached for each foreground/background combination. But, this is usually not the case. The background might be a gradiant , or an image, or some other pattern.
Furthermore, the text colour may not be black - it can be any colour with any level of translucency.
I believe that the existing bitBlt rules are insufficient to cover all these circumstances, but I am happy to be proved wrong :)
Well, not all these circumstances, but all those with black text. You can see in the latest Cuis that rgbMul is enough for correct subpixel rendering of black text over any background. And yes, black on black shows all black. In fact, rgbMul is the same formula than rule 41 if text color is black (0;0;0).
In Cuis I disable subpixel rendering for colored text. I found that for colored text, the difference between doing or not subpixel rendering is much less visible.
As I write this, I realize that it could be possible to do subpixel rendering with smarter colormaps... I guess I'll play a bit with this idea.
BTW, I tried to use rule 41 in Cuis, but as r, g and b are alpha values (0 meaning transparent, 255 meaning opaque), the glyph form can not be the same as used for other rules (such as rgbMul and Paint). As I have a single glyph for each char/font/size, and I need to use different rules and colormaps to adapt to various display depths and text colors, I could not use rule 41. It would have made more sense to me to store transparency values (0 meaning opaque, 255 meaning transparent).
Finally, I wonder, what do you guys use for text rendering for your Squeak programming? Are you happy with just full pixel AA on LCD screens?
Cheers, Juan Vuletich
Juan Vuletich wrote:
Well, not all these circumstances, but all those with black text. You can see in the latest Cuis that rgbMul is enough for correct subpixel rendering of black text over any background. And yes, black on black shows all black. In fact, rgbMul is the same formula than rule 41 if text color is black (0;0;0).
Yeah, that's kind of what I thought.
In Cuis I disable subpixel rendering for colored text. I found that for colored text, the difference between doing or not subpixel rendering is much less visible.
Personally, I find there is very little difference between subpixel AA or not even with black text. What *really* makes the difference for font rendering is grid-fitting; which is why both native fonts (TTF hinting) as well as Freetype (excellent auto-hinter) look much better than Squeak fonts by default.
Cheers, - Andreas
Andreas Raab wrote:
In Cuis I disable subpixel rendering for colored text. I found that for colored text, the difference between doing or not subpixel rendering is much less visible.
Personally, I find there is very little difference between subpixel AA or not even with black text. What *really* makes the difference for font rendering is grid-fitting; which is why both native fonts (TTF hinting) as well as Freetype (excellent auto-hinter) look much better than Squeak fonts by default.
Cheers,
- Andreas
Really? I do like the hinting in the Mac and the Freetype auto-hinter, but for regular text. For code, I don't care. I could even use monospaced fonts. But not having subpixel AA on the code really hurts my eyes.
It seems there's not a best-for-all approach here. Well, people not agreeing on what looks better, Mac text (correctly hinted, correct AA, blurry) or Windows text (pixel aligned, character shapes and sizes not preserved), already showed that...
Cheers, Juan Vuletich
Juan Vuletich wrote:
Hi Folks,
Andrew Tween wrote:
...
It is possible to replicate this effect by storing these 'coloured' glyphs, and rendering them using the existing bitBlt rules, and, for black text on a white background, it will give the correct result.
But, when these same glyphs are rendered to a black background (i.e. black text on a black background), the colour fringes in the resulting output are still visible. This is of course wrong; black text on a black background should result in a completely black result with no glyphs visible at all.
It would be possible to use the existing bitBlt modes if the background colour was known in advance. In this case glyphs could be created and cached for each foreground/background combination. But, this is usually not the case. The background might be a gradiant , or an image, or some other pattern.
Furthermore, the text colour may not be black - it can be any colour with any level of translucency.
I believe that the existing bitBlt rules are insufficient to cover all these circumstances, but I am happy to be proved wrong :)
Well, not all these circumstances, but all those with black text. You can see in the latest Cuis that rgbMul is enough for correct subpixel rendering of black text over any background. And yes, black on black shows all black. In fact, rgbMul is the same formula than rule 41 if text color is black (0;0;0).
In Cuis I disable subpixel rendering for colored text. I found that for colored text, the difference between doing or not subpixel rendering is much less visible.
As I write this, I realize that it could be possible to do subpixel rendering with smarter colormaps... I guess I'll play a bit with this idea.
I was not clear here. I meant that it came to me that it is possible to do _colored_ subpixel rendered text over any background with smarter colormaps. I played a bit with it. It can be done. But it requires two BitBlts, one after the other. The glyph is "natural", i.e. black on white with subpixel AA, like a screen capture from redered text. The first pass does rgbMul. This is the first half of AA at each subpixel. It is also all what's needed for black text. If we have colored text, we do a second path, using a colormap done by multiplying each component of the intended text color by (1.0 - each component of the index colors). This second pass does rgbAdd. Both passes do the full sub pixel AA.
In the end, I guess we can say that the existing rules are enough to cover all these circumstances. The only problem is requiring 2 BitBlts is some cases.
BTW, I tried to use rule 41 in Cuis, but as r, g and b are alpha values (0 meaning transparent, 255 meaning opaque), the glyph form can not be the same as used for other rules (such as rgbMul and Paint). As I have a single glyph for each char/font/size, and I need to use different rules and colormaps to adapt to various display depths and text colors, I could not use rule 41. It would have made more sense to me to store transparency values (0 meaning opaque, 255 meaning transparent).
Finally, I wonder, what do you guys use for text rendering for your Squeak programming? Are you happy with just full pixel AA on LCD screens?
Cheers, Juan Vuletich
Juan Vuletich wrote:
Juan Vuletich wrote:
Andrew Tween wrote:
...
It is possible to replicate this effect by storing these 'coloured' glyphs, and rendering them using the existing bitBlt rules, and, for black text on a white background, it will give the correct result.
But, when these same glyphs are rendered to a black background (i.e. black text on a black background), the colour fringes in the resulting output are still visible. This is of course wrong; black text on a black background should result in a completely black result with no glyphs visible at all.
It would be possible to use the existing bitBlt modes if the background colour was known in advance. In this case glyphs could be created and cached for each foreground/background combination. But, this is usually not the case. The background might be a gradiant , or an image, or some other pattern.
Furthermore, the text colour may not be black - it can be any colour with any level of translucency.
I believe that the existing bitBlt rules are insufficient to cover all these circumstances, but I am happy to be proved wrong :)
...
I was not clear here. I meant that it came to me that it is possible to do _colored_ subpixel rendered text over any background with smarter colormaps. I played a bit with it. It can be done. But it requires two BitBlts, one after the other. The glyph is "natural", i.e. black on white with subpixel AA, like a screen capture from redered text. The first pass does rgbMul. This is the first half of AA at each subpixel. It is also all what's needed for black text. If we have colored text, we do a second path, using a colormap done by multiplying each component of the intended text color by (1.0 - each component of the index colors). This second pass does rgbAdd. Both passes do the full sub pixel AA.
In the end, I guess we can say that the existing rules are enough to cover all these circumstances. The only problem is requiring 2 BitBlts is some cases.
Done. You can see how well this works by going to http://www.jvuletich.org/Cuis/ and downloading the new Cuis #0204. See how well it does subpixel AA with black and colored text. Change display depth, and see how it adapts to lower display depths. Also play with preferences #subpixelRenderText and #subpixelRenderColorText. All this is done with just one 16bpp glyph for each char/font/size! No extra caches. Just standard rules, colormaps, and thought.
Cheers, Juan Vuletich
You can see how well this works by going to http://www.jvuletich.org/Cuis/ and downloading the new Cuis #0204. See how well it does subpixel AA with black and colored text. Change display depth, and see how it adapts to lower display depths. Also play with preferences #subpixelRenderText and #subpixelRenderColorText. All this is done with just one 16bpp glyph for each char/font/size! No extra caches. Just standard rules, colormaps, and thought.
Some screen shots...
Sub pixel AA: http://www.jvuletich.org/Cuis/32BitDisplay-SubPixAA.png . That is the best look. Display at 32 bpp, sub pixel AA. http://www.jvuletich.org/Cuis/16BitDisplay-SubPixAA.png http://www.jvuletich.org/Cuis/08BitDisplay-SubPixAA.png
Whole pixel AA: http://www.jvuletich.org/Cuis/32BitDisplay-WholePixAA.png http://www.jvuletich.org/Cuis/16BitDisplay-WholePixAA.png http://www.jvuletich.org/Cuis/08BitDisplay-WholePixAA.png
For less than 8bpp, no subpixel AA is available: http://www.jvuletich.org/Cuis/04BitDisplay.png http://www.jvuletich.org/Cuis/01BitDisplay.png
I did not include subpixel black and whole pixel color, but it is possible too.
Anyway, people really interested on this should check the code. Besides, playing 5 minutes with Cuis should be good for any squeaker, to realize that Squeak can be nice, simple and fast.
Cheers, Juan Vuletich
On Thu, May 21, 2009 at 12:46 PM, Juan Vuletich juan@jvuletich.org wrote:
You can see how well this works by going to
http://www.jvuletich.org/Cuis/ and downloading the new Cuis #0204. See how well it does subpixel AA with black and colored text. Change display depth, and see how it adapts to lower display depths. Also play with preferences #subpixelRenderText and #subpixelRenderColorText. All this is done with just one 16bpp glyph for each char/font/size! No extra caches. Just standard rules, colormaps, and thought.
Some screen shots...
Thanks Juan!
Sub pixel AA: http://www.jvuletich.org/Cuis/32BitDisplay-SubPixAA.png . That is the best look. Display at 32 bpp, sub pixel AA. http://www.jvuletich.org/Cuis/16BitDisplay-SubPixAA.png http://www.jvuletich.org/Cuis/08BitDisplay-SubPixAA.png
Whole pixel AA: http://www.jvuletich.org/Cuis/32BitDisplay-WholePixAA.png http://www.jvuletich.org/Cuis/16BitDisplay-WholePixAA.png http://www.jvuletich.org/Cuis/08BitDisplay-WholePixAA.png
For less than 8bpp, no subpixel AA is available: http://www.jvuletich.org/Cuis/04BitDisplay.png http://www.jvuletich.org/Cuis/01BitDisplay.png
I did not include subpixel black and whole pixel color, but it is possible too.
Anyway, people really interested on this should check the code. Besides, playing 5 minutes with Cuis should be good for any squeaker, to realize that Squeak can be nice, simple and fast.
Cheers, Juan Vuletich
Hi Juan,
That's cool.
Congratulations on finding the 'magic' combination of bitBlt rules.
I'm not sure where that leaves my bitBlt rule 41. Possibly rendundant.
But unfortunately I don't have much free time to change the FreeType stuff to use your technique.
Maybe one of the Pharo developers can make the necessary changes.
Of course I also added the gamma correction, and the handling of translucent text foreground colours.
So, it may be worth keeping both techniques around for a while.
Cheers, Andy
.
Date: Thu, 21 May 2009 16:46:28 -0300 From: juan@jvuletich.org To: vm-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts
You can see how well this works by going to http://www.jvuletich.org/Cuis/ and downloading the new Cuis #0204. See how well it does subpixel AA with black and colored text. Change display depth, and see how it adapts to lower display depths. Also play with preferences #subpixelRenderText and #subpixelRenderColorText. All this is done with just one 16bpp glyph for each char/font/size! No extra caches. Just standard rules, colormaps, and thought.
Some screen shots...
Sub pixel AA: http://www.jvuletich.org/Cuis/32BitDisplay-SubPixAA.png . That is the best look. Display at 32 bpp, sub pixel AA. http://www.jvuletich.org/Cuis/16BitDisplay-SubPixAA.png http://www.jvuletich.org/Cuis/08BitDisplay-SubPixAA.png
Whole pixel AA: http://www.jvuletich.org/Cuis/32BitDisplay-WholePixAA.png http://www.jvuletich.org/Cuis/16BitDisplay-WholePixAA.png http://www.jvuletich.org/Cuis/08BitDisplay-WholePixAA.png
For less than 8bpp, no subpixel AA is available: http://www.jvuletich.org/Cuis/04BitDisplay.png http://www.jvuletich.org/Cuis/01BitDisplay.png
I did not include subpixel black and whole pixel color, but it is possible too.
Anyway, people really interested on this should check the code. Besides, playing 5 minutes with Cuis should be good for any squeaker, to realize that Squeak can be nice, simple and fast.
Cheers, Juan Vuletich
_________________________________________________________________ View your Twitter and Flickr updates from one place – Learn more! http://clk.atdmt.com/UKM/go/137984870/direct/01/
Hi Andy,
Andrew Tween wrote:
Hi Juan, That's cool. Congratulations on finding the 'magic' combination of bitBlt rules.
Thanks :)
I'm not sure where that leaves my bitBlt rule 41. Possibly rendundant.
But unfortunately I don't have much free time to change the FreeType stuff to use your technique. Maybe one of the Pharo developers can make the necessary changes.
I don't know. I don't know if there is a compelling enough reason for people to make the changes. What this perhaps means is that the use of rule 41 will be limited to FreeType. This could mean that it only makes sense to add rule 41 to the VM if FreeType is also added. But I'm not sure of this.
Of course I also added the gamma correction, and the handling of translucent text foreground colours. So, it may be worth keeping both techniques around for a while.
The rgbMul / rgbAdd sequence does not support translucent text (nor gamma correction). The only way I see to support it is by cloning the glyphs for each needed alpha value. I would not advice doing this. I would perhaps do a TranslucentStringMorph that renders to an intermediate Form that is later blended in the canvas... But I guess people wanting these features should better stick with rule 41.
Cheers, Andy
Cheers, Juan Vuletich
vm-dev@lists.squeakfoundation.org
-
Adrian Lienhard -
Andreas Raab -
Andrew Tween -
Bert Freudenberg -
Bryce Kampjes -
David T. Lewis -
Eliot Miranda -
John M McIntosh -
Juan Vuletich