[sldev] PATCH for SNOW-203 (162)

[Thickbrick Sleaford]

On Wednesday 16 September 2009 08:56:10 Philippe (Merov) Bossut wrote:
> Looking into this, I noted there are a number of issues that seem to be all
> related to partially fetched textures right now (SNOW-162, SNOW-203,
> SNOW-59, SNOW-207, SNOW-48). All of them point to the LLViewerImage code.
> The number of flags and members is hard to grok and, as a result, the state
> of the object is unclear.
> 

SNOW-48, SNOW-207 and SNOW-181 seem like degraded content that is the result 
of the design decisions in http-texture/texture-pipeline.

SNOW-59, SNOW-162/SNOW-203 and also SNOW-112 are about various bugs in the 
implementation.

It would really helpful to have the sort of documentation Merov did for http 
texture fetching, for other parts of the texture pipeline. Failing that (I 
understand that's not an easy task) can we get some sort of high-level 
documentation from the Lindens who are working on texture-pipeline, about:

- What they changed (say compared to 1.23), or are planning to change.
- What were the reasons for these changes.
- What compromises did they have in mind between degraded content vs. 
optimizations (not downloading texture details that aren't "interesting.")
- Other stuff?

Specifically, some examples of content that is degraded in Snowglobe, which I 
think is caused by texture interestingness optimizations, and would benefit 
from information from texture-pipeline developers:
- Megaprims (SNOW-48),
- Sculpts with high texture repeats, e.g. 1 prim billboard-style plants 
(SNOW-207),
- Texture "preloaders" for particle effects and sculpts,
- "Brightness" and "Darkness" bump maps (SNOW-181)

Note, before cries of "Lindens break content" start, that I think those are 
corner cases that simply weren't considered, and can mostly be fixed pretty 
easily.

-- 
Thickbrick