[sldev] What color should I paint the bike shed?

[John Hurliman]

This is historical. The old upload system had no way of handling 
multiple simultaneous uploads. We hacked support for it in to libsl but 
it is really ugly, and if you start two uploads at the same time there 
is a race condition in the protocol. When the old system is completely 
deprecated out in favor of the new CAPS uploading this could be changed.

John Hurliman

SL - Farallon Greyskin wrote:
> There are a couple of places that SL is strangely non-async :( 
> Uploading files also halts the viewer and causes some funny artifacts 
> when is starts up again. WHY? Start a new thread for the file dialog...
>
> One of those things that /should/ be fixed but is unromantic and not 
> really "problematic" and so will stay that way forever I would guess ;)
>
> Farallon
>
> ----- Original Message ----- From: "Lawson English" <lenglish5 at cox.net>
> Cc: <sldev at lists.secondlife.com>
> Sent: Sunday, September 23, 2007 10:06 PM
> Subject: Re: [sldev] What color should I paint the bike shed?
>
>
>> Tateru Nino wrote:
>>> Jason Giglio wrote:
>>>
>>>> http://jira.secondlife.com/browse/VWR-2491
>>>>
>>>> VWR-2491 has been kinda bumping around a while, I'd really like to get
>>>> some consensus before writing the patch.
>>>>
>>>> My proposal is to simply get rid of BMP snapshots and make PNG the
>>>> default format for saving snapshots.
>>>>
>>>> So far I've gotten about 50/50 feedback saying "go for it" and "keep
>>>> BMP as an option".
>>>>
>>>> Due to SL's cross platform nature, keeping BMP will likely require new
>>>> UI on the snapshot floater.    That's not a huge deal, but I'm not
>>>> sure it's necessary since I still haven't heard any compelling
>>>> arguments for keeping BMP other than "it's already in there".
>>>>
>>>> Does anyone have any compelling reason to keep BMP as an option,
>>>> including new UI to select the format to save as?
>>>>
>>> I've got very little in the way of qualms about giving BMP the boot -
>>> except one.
>>> Writing the snapshot involves (correct me if I'm wrong) two basic
>>> phases. Encoding the image, and writing it to disk.
>>> During the encoding stage, the viewer essentially becomes 
>>> non-responsive
>>> to the network (okay, this can happen during the write-to-disk phase as
>>> well, and BMP's are pathetically overweight). All that time taken
>>> multiplies the odds that the circuit to the primary simulator will 
>>> break.
>>>
>>> That said, if this reduces the overall time that the viewer spends in
>>> fairyland while packets pile up on the floor, then hooray!
>>>
>>>
>>
>> Why should this be the case? Asynchronous file i/o has been around a 
>> long time on home computers. I patched the MacOS's version in the 
>> mid-80's because SCSI-I wasn't properly defined back then and Apple's 
>> non-standard implementation depended on timing loops (which our Mac+ 
>> 68020 accelerator card broke) to fake it, but that was 20+ years ago. 
>> Surely Second Life can save a file to disk without blocking? And why 
>> should encoding block either? That's just lame.
>>
>>
>> L.
>>
>>
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html 
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html