Problem with antialiasing on scrolled text fields

[magicmouse]

I am building an app using FlashBuilder, and at present running on Mac OSX latest version, and testing my application in the ADL.  I am seeing the weirdest problem; i have a big window, and i use scrollrect to show various parts of the window. When I adjust the scrollrect, it works just fine, and the window scrolls up just like you expect. But bold text on the screen gets noticeably more ugly after i scroll.  I tried setting CacheAsBitmap on the containing sprite that is being scrolled, but that had no effect. It affects text that might have been in the middle of the window and just move up slightly; all the bold text has ruined sub-pixel antialiasing.

Is this a known weakness of using ScrollRect? How can i get around this problem?  I tried turning on cacheasbitmap for all my sprites but nothing changed. I tried setting the AntiAliasType of my TextField to ADVANCED but that also had no effect.

This is baffling to me, why the rendering is so bad after a scroll. Even when i go back to the original position (scroll down, then up), the text is lousy. It is almost as if it drew it twice on the screen, but probably it is just an inferior level of text rendering.

Any guidance would be greatly appreciated.

[Guest]

I've never had text do that before with scrolling, but I have also not ever used scrollRect. There are a couple of different scroll options for TextField's (assuming that is the object you are using to render text). You can create a mask for the TextField and scroll the TextField object by adjusting the .y property based on a custom thumb/track scrollbar you would also need to create. You can also set the height of the TextField to be less than the height of the actual text in the TextField and adjust the scrollV property. Been a long time since I used scrollV but if I remember correctly, using the that property does line by line scrolling and not pixel scrolling.

A few questions for you. What font are you using? What font size do you have set? Is it embedded?

[magicmouse]

I am not scrolling a text field by itself, but a whole window containing 20 text fields and graphics.  I programmed my own scrollbar control, and on the right side when i click the DOWN arrow in my scroll button, i scroll the viewport (sprite) up about 50 pixels. what is weird is that when i call scrollrect, there is a noticeable lag, it refreshes the screen (with lousy anti-aliasing), then does the scroll. I understand that scrollrect has a delayed action but the refresh before it then scrolls the window up is baffling. It as if it realized that it doesn't have the buffer on the GPU, so it decides to refresh into the GPU (with lousy antialiasing), and then does the scroll.  I have tried various fonts, but all the thicker truetype fonts I am using, about 20 pt (20 pixels high on my 27 inch monitor) in size, look lousy. Thinner stroke fonts don't seem to suffer as badly.

I strongly suspect that AIR runtime is doing fancy things behind the scenes, and that somehow the CPU can render more beautifully than the GPU. I am wondering if the native renderer is used at one point, and then the flash classic renderer is used elsewhere, with lesser results. The native OSX renderer is very high quality. I know that Adobe has access to the terrific Saffron renderer they licensed from Mitsubishi, which is one of the greatest renderers ever made, but i think i have to embed only certain kinds of fonts for that. Anyway i am starting to wonder if I shouldn't move to the Sparrow framework, as the quality of the rendering might be better over there.

[molotowitzz]

What component exactly are you using to display the texts? TextField? Some Flex FTE textfield etc.?  I use scrollrects heavily on desktop, iOS and Android and scrolling large containers with texts is fine. Event nested scrollrects in another scrollrects. Even with "bold" ones. Is your font embedded? If not, you should do it in a first place. Once font is embedded, it must work.

[magicmouse]

I am using plain old TextField, under AIR, latest version. I am scrolling a large container (basically the size of the window minus the scrollbar control i designed), which has many nested sprites.  One big outer scrollrect (but the inner sprites also have scrollrects to effect clipping to their bounds).  As for the fonts, i have been trying different fonts, and they are all just OSX standard built-in fonts, Truetype. I have not tried embedding the font, that would be a good experiment to see if the rendering is better with embedded fonts.

[kheftel]

I would not be surprised if embedding the fonts fixes your issue. Historically good antialiasing hasn't been available in Flash when using device fonts. Also, if you don't embed fonts, and the user's system doesn't have them, your text will display in a different font or disappear.

[magicmouse]

My system is rather clever, and i give users the ability to use whatever device fonts they have installed. This is a nice feature, that I will be sorry to lose. Many users have huge font collections, and in this case I am building a resume-generator, where they type into a whole bunch of text field blocks, and then I spit out a PDF of their nicely formatted resume. I can do the experiment, but what is baffling to me is how nice it looks on the screen when i first draw it, but the second I ask it to scroll it redraws in the unscrolled position a lousier version of the container, and then does the scroll. It is as if there were 2 different versions at work; one that drew nicely, and then a cruder one that is used when scrolling is in play.  Clearly the GPU is intruding here, and there must be some incredible complexity in the AIR runtime that i am stumbling into. I will try some experiments to see if I can isolate the cause of this rather ugly problem.

[magicmouse · Accepted solution]

I have identified the problem. It is caused by a bug in my code, which is double drawing text fields on top of each other. When you have a large size font that is antialised, when you draw a second copy on top, the aliasing blends in such a way as to ruin the smoothness of the font. It is the only clue that you have double drawn an object! Very interesting issue in vector graphics, once cannot easily tell when you have drawn something twice!