Meshmoon - HttpAssetProvider improvements

realXtend / tundra

realXtend Tundra SDK, a 3D virtual world application platform.

www.realxtend.org

Apache License 2.0

84 stars 70 forks source link

Meshmoon - HttpAssetProvider improvements #709

Closed jonnenauha closed 11 years ago

jonnenauha commented 11 years ago

See previous details at https://github.com/realXtend/naali/pull/707

Added to above:

Queuing of completed transfers and serving them with max 16msec/frame to AssetAPI. Before N transfers could complete from Qt in the same Tundra main loop frame and be fed to AssetAPI. This ofc resulted in freezing Tundra for how ever long it took to load them. Note that the 16msec will take into account how long each transfer will spend in the AssetAPI and IAsset internals.
Static HttpAssetProvider::AsyncCacheWriteThreshold that is default set to 0. This means that everything is written to disk with the threaded operation. I left this variable there for easy debugging and profiling, when/if we want to find a sweet spot for disabling async writes below a particular file size.
Make HTTPASSETPROVIDER_NO_HTTP_IF_MODIFIED_SINCE logic use the same completedTransfer list. Can now remove ifdefs from the .h file.

cadaver commented 11 years ago

As expected, this retains the main loop fairly smooth. I'll likely briefly experiment with the write threshold.

Stinkfist0 commented 11 years ago

I suspect this might have broken zip assets on Win64 builds. Will begin investigating more now.

jonnenauha commented 11 years ago

I highly doubt it. There is no way that processing of the transfer is done before the cache write has successfully completed. If it does fail it will set empty disk source to the transfer. This will affect IAssetBundle loading if it requires a disk source to operate eg. ZipArchive does this.

I will also step in if the problem is actually in the disk write, but it does not look to me like it.

Please test with the old synchronous disk write code to see if the bug persists to rule this out. Comment out lines https://github.com/realXtend/naali/blob/tundra2/src/Core/AssetModule/HttpAssetProvider.cpp?source=c#L386-L399

Stinkfist0 commented 11 years ago

Yeah, my accusation might be a bit of a stretch but couldn't come up with a more viable suspect for now.

Stinkfist0 commented 11 years ago

OK, so I rebuilt ogredeps, Ogre (1.9), QtScriptBindings and Tundra and the problem seems to have been fixed by that.

jonnenauha commented 11 years ago

Hmm, that is weird. Only thing that might have affected it somehow was this https://github.com/realXtend/naali/commit/d9152f6b69b9337f52201d943a45af8141e89ae9

If your script plugins were not somehow loading properly, maybe it failed to register the metatype and fail all cache writes like it was before that commit. The commit should have fixed that in any case, but maybe it was a case of doing a full rebuild to Tundra too?

Weird weird bug, but good thing its resolved :)

Stinkfist0 commented 11 years ago

BTW I noticed a warning that x64 RelWithDebInfo build of ArchivePlugin linked to MSVCRTD, it might have something to do with this. Regardless of the warning, the new build seems to work fine though.

jonnenauha commented 11 years ago

There was problems of zlib or zziplib linking to incorrect VC runtime, but if I recall correctly I fixed those in the deps build script at some point. Must still have something off then.

jonnenauha commented 11 years ago

Ah here it is https://github.com/realXtend/naali/issues/598 I wonder if we didnt send this over or whats going on. I seem to have closed the issue a month from that commit so I would think it was sent over :P