Text Costumes: Stop using pen in costume () with background block

Feature Requests Snap! Feature Requests
1

In the (costume [ V] with background RGBA (200) padding (2)::looks) block from the Text Costumes library, it relies on pen to create the costume, and to do that, it needs to take out whatever pen trails are already there and restore if afterward. By doing that, the pen trails end up blurry after it is used, because the hindrance of anti-aliasing is trying to do a "favor".

The only way to fix it is to avoid the method that causes anti-aliasing, by manipulating the costume instead.

I know that this has been suggested before, and I am certain that someone has already made such a block that does what I want it to do, but by modifying the library, future users will not have to suffer from the pesky anti-aliasing.

2

I think using overdraw in snap 12 beta would produce the same result, possibly easier.

3

Maybe there should be a “txt_cst(text, info)” where info is a dictionary for actual good text writing (Snap! is kind of missing out on that)

4

the hindrance of anti-aliasing is trying to do a “favor”.

I hate anti-aliasing. Among other things, it makes FILL not work properly. This thing about saving and restoring pen trails is another reason that I hadn’t realized before. The proper solution isn’t to make a workaround for this one library, but to make restoring pen trails work, period.

You’d think that with modern HD monitors jaggies wouldn’t be such a big problem in the first place.

5

I mean, you can actually stick a string like 500 12px monospace, based on the css font specifier (it uses CanvasRenderingContext2D.font ) into the font size input of the write block. The comma at the end is important because it basically says to ignore anything after it (it ignores what snap adds). Technically this is an oversight, but jens has shown that he approves of it (it’s not a security issue because you can’t put anything malicious into the value) because he added the writing and formatting library (originally created by @tethrarxitet ) and even added a new txt_width() extension function and block to the writing and formatting library that uses this oversight.

6

Yeah, but it still uses pen, which is the problem here :~)

7

as in an extension that would load pen trails or pen vectors onto the stage?

8

I guess that would work, but I worry that there could be a dozen things sabotaged by anti-aliasing that we haven’t thought of yet. What I really want is to anti-alias-proof all of Morphic. For example, we could have an internal stage with anti-aliasing turned off, and only at the last moment before putting it on the screen do we make an anti-aliased copy. We would never remember any anti-aliased image. (I dunno if this would actually work; it’s just an idea off the top of my head to illustrate the kind of solution I want.)

9

AA is a mode of operation (canvas context).
It can and should be set for every stamp of images/canvas with canvas.drawImage().
When drawing a shape, AA can’t be directly controlled. But kind of oversampling can be used.
Retina mode does the trick. Graphic objects are internally enlarged for processing that makes the screen look quite crisp.