Tinct and NetSurf

The latest development builds of NetSurf (#5301 or later) have been changed to detect alpha channel support in the OS, and use the OS for rendering. You still need to have “Use OS” selected in the Image choices, but now it will bypass Tinct entirely.

This should enable PNGs with alpha channels to be rendered on modern hardware. However, we still don’t get the error diffusion and the tiled rendering optimisation is lost.

I’ve updated the Tinct page to be more forthcoming about the status of the project.

Tinct did a bunch of useful things:

1. Rendering of sprites with alpha channels (which old versions of the OS did not support).
2. Error diffusion when rendering in 256 colour modes or less (drastically improved image quality).
3. Optimised tiled bitmap plotting for tiny images. (e.g. a 2×1 px background image to makes stripes)

However, it’s broken on modern hardware and unsupported.

People have been working around the problem in NetSurf by configuring it to Use OS in the Image choices. However, because of the way Tinct worked, this meant that the alpha channels were not preserved. This resulted in poor rendering e.g. on the RISC OS Open logo or around the NetSurf download box.

Tinct did a bunch of useful things:
3. Optimised tiled bitmap plotting for tiny images. (e.g. a 2×1 px background image to makes stripes)

I notice in your nearby commit the OS rendering code path will use the tiled sprite op instead.

However, it’s worth mentioning that that SpriteOp reason is a relatively recent innovation too. As the RMEnsures in !Run imply support of older OS versions (even back to RISC OS 3) their SpriteExtend definitely don’t do tiled sprites. The OS StrongHelp reckons SpriteExtend 1.74 is the earliest point that op exists, and indeed a quick check of CI#5301 on RISC OS 4.02 the repeating background in this test page has redraw/rubout issues when ‘Use OS’ is on.

The safest thing to do would be check the error from OS_SpriteOp and fall back to a FOR…NEXT loop which tiles using the normal op. I suppose another option would be to ignore the user’s rendering option and force Tinct to be used for tiling if an old SpriteExtend is in use, but that feels spiritually wrong.

Oh, OK, thanks. Hmmm, there’s no real point in using the “Use OS” image options unless forced by hardware incompatibility.

The OS StrongHelp reckons SpriteExtend 1.74 is the earliest point that op exists

I’m not sure how recent that is. Was that before or after alpha channel support?

It might be best to remove the user choice and just select the best option for the OS on startup.

The OS StrongHelp reckons SpriteExtend 1.74 is the earliest point that op exists

I’m not sure how recent that is. Was that before or after alpha channel support?

SpriteExtend 1.62 is the first mention of SpriteOp 65. Around that time I think the only platforms that are ARMv7 (and hence Tinct would fail) are BeagleBoard and Pandaboard for whom it first appears in RISC OS 5.22, so in theory at least there could be RISC OS 5.18 and 5.20 users without tiled ops and who also can’t use Tinct.

It might be best to remove the user choice and just select the best option for the OS on startup.

I guess it’s a choice whether you want to attempt to detect availability on a per-call basis or keying off the OS. If the selection logic is UseOS = HaveAlpha() AND HaveTiling() AND NOT(AbleToUseTinct()) my point is there are some systems whose Venn diagram wouldn’t match, though hopefully there’s not too many people still on OS 5.18 or 5.20.

The Wimp doesn’t bother checking for tiled sprite support; it just tries it and then falls back to manual tiling if it gets a “bad sprite reason code” error (&709).

However, it’s broken on modern hardware and unsupported.

Is it written in impenetrable assembler or something?

SpriteExtend 1.62 is the first mention of SpriteOp 65.

It’s a surprise it took that long, given the Wimp has needed to tile, for the background textures, for ages.