Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

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

Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

johnmci
 
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 <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================




Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Adrian Lienhard
 
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 <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>


FreeTypeBitBltSimulation.1.cs (38K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Andreas.Raab
In reply to this post by johnmci
 
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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Bryce Kampjes
 
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

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

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

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Adrian Lienhard
 
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

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

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

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Bert Freudenberg
 

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 -


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Bert Freudenberg
 

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 -


Reply | Threaded
Open this post in threaded view
|

RE: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Andrew Tween
In reply to this post by Andreas.Raab
 
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: [hidden email]
> To: [hidden email]
> 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


Get the New Internet Explore 8 Optimised for MSN. Download Now
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Eliot Miranda-2
In reply to this post by Bert Freudenberg
 


On Wed, May 20, 2009 at 2:50 PM, Bert Freudenberg <[hidden email]> 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...


- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Andreas.Raab
In reply to this post by Bert Freudenberg
 
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.
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Bert Freudenberg
In reply to this post by Eliot Miranda-2
 

On 20.05.2009, at 15:09, Eliot Miranda wrote:



On Wed, May 20, 2009 at 2:50 PM, Bert Freudenberg <[hidden email]> 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 -


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Juan Vuletich-4
In reply to this post by Andrew Tween
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

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

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Juan Vuletich-4
In reply to this post by Juan Vuletich-4
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Juan Vuletich-4
In reply to this post by Andreas.Raab
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Juan Vuletich-4
In reply to this post by Juan Vuletich-4
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Juan Vuletich-4
 
>  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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Eliot Miranda-2
 


On Thu, May 21, 2009 at 12:46 PM, Juan Vuletich <[hidden email]> 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

12