[sldev] Possible SVR bug in relation to problematic JPEGs (VWR-1815 and friends)

[Robin Cornelius]

Hi Everyone,

Can someone confirm exactly how the "RequestImage" message works:-

>From the discussions on #sldev open the openjpeg issues, it appears
that a RequestImage message is sent with a requested discard the
server then fires a bunch of messages back with the image data. It
appears that the server is making the same discard factor assumptions
as the viewer eg that dreaded 0.125 factor so the server decides how
much data to fire for a given discard level then stops when it thinks
it has sent enough.

If the viewer is hacked so it knows not to try to run a decode when
clearly not all the packets have arrived it only fetches one
additional packet every 15 seconds (LAZY_FLUSH_TIMEOUT) which is why
maps etc can take 20 minutes to download.

There are some additional observations here:- The production viewer
has a LAZY_FLUSH_TIMEOUT of 10 seconds not 15 as the released source
code shows.(there is a 10 in the comments).

Secondly KDU we know behaves differently to OpenJPEG, BUT it appears
that if KDU gets an incomplete data for discard **i think** it deletes
the LLRawImage and thus causes the texture fetch to continue gathering
packets. This also takes ages as its only pulling in packages at 10
second intervals (LAZY_FLUSH_TIMEOUT again). But no one really notices
this as the map just displays at the next best discard of 128x128
until all the packets have arrived. But if you sit and watch the
texture console I can observe this behavior and it still takes about
20 minutes for some maps to get to 256x256.

I'm not quite sure what happens in the kdu decode (thats why i said i
think above, not watched the code return paths there yet) but we know
that somehow the texture fetcher keeps running. Carjay's patch makes
the openjpeg decoder not barf at incomplete streams when you request
discard of 0 (Woot!) but we also need to keep the texture fetcher
running somehow to get the full image downloaded and it would be
really cool if this remaining download was not on a fallback code
path.


Regards

Robin