Re: [opensource-dev] New HTTP Library & Project Viewer
On Sun, 29 Jul 2012 05:23:15 +0200, Carlo Wood wrote: > On Fri, 27 Jul 2012 16:59:18 -0400 > holydoughnuts wrote: > > The implementation that I wrote for Singularity (not yet in the > the official release) is more on the side of "blazing fast" :p. > The bottleneck is entirely server-side, but I've seen download > speeds of 1 MB/s non-stop till all textures were there. With just a few tweakings to the texture fetcher (and in particular a setting that permits up to 32 concurrent HTTP fetches), I get much more than 1MB/s in the Cool VL Viewer... In fact, I'm more in the 10MB/s+ range while rezzing in heavily textured areas and the rezzing time is pretty low... This has been so for many months (well over a year actually) already. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1899: Avatar hand poses randomly get stuck in spread position
> On July 28, 2012, 2:15 a.m., Lance Corrimal wrote: > > I think the warning message should either go, or be modified to warn only > > once, or be changed to lldebug... the way it is now it floods the > > logfiles... i have 1900 repeats of that warning line in my log file, after > > being logged in for less than 5 minutes! on second thought, this flooding might be because I screwed up my test build... ... yep, that was it. - Lance --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/592/#review1241 --- On July 25, 2012, 3:12 p.m., Ansariel Hiller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/592/ > --- > > (Updated July 25, 2012, 3:12 p.m.) > > > Review request for Viewer. > > > Description > --- > > A proposed solution for STORM-1899 and the issue, where the handpose of > avatars randomly get stuck in the spread hand position. > > In the current implementation, this case might happen under the following > circumstances: > * Avatar uses an animation with hand pose A > * A request is issued to change hand pose to B > * Before the viewer has blended pose A over to pose B, the original pose A is > requested again > * In this case, the hand pose will not be properly (re)set and because > mNewPose == mCurrentPose, there will be no further blending, leaving the hand > in it's current pose > > The patch will properly reset the hand pose in this case and update the > visual parameters of the avatar. > > > This addresses bug STORM-1899. > https://jira.secondlife.com/browse/STORM-1899 > > > Diffs > - > > indra/llcharacter/llhandmotion.cpp 4d9106153407 > > Diff: http://codereview.secondlife.com/r/592/diff/diff > > > Testing > --- > > > Thanks, > > Ansariel Hiller > > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1899: Avatar hand poses randomly get stuck in spread position
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/592/#review1243 --- Ship it! Ship It! - Lance Corrimal On July 25, 2012, 3:12 p.m., Ansariel Hiller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/592/ > --- > > (Updated July 25, 2012, 3:12 p.m.) > > > Review request for Viewer. > > > Description > --- > > A proposed solution for STORM-1899 and the issue, where the handpose of > avatars randomly get stuck in the spread hand position. > > In the current implementation, this case might happen under the following > circumstances: > * Avatar uses an animation with hand pose A > * A request is issued to change hand pose to B > * Before the viewer has blended pose A over to pose B, the original pose A is > requested again > * In this case, the hand pose will not be properly (re)set and because > mNewPose == mCurrentPose, there will be no further blending, leaving the hand > in it's current pose > > The patch will properly reset the hand pose in this case and update the > visual parameters of the avatar. > > > This addresses bug STORM-1899. > https://jira.secondlife.com/browse/STORM-1899 > > > Diffs > - > > indra/llcharacter/llhandmotion.cpp 4d9106153407 > > Diff: http://codereview.secondlife.com/r/592/diff/diff > > > Testing > --- > > > Thanks, > > Ansariel Hiller > > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Compilation issues under MSVC2010: Windows guru help *badly* needed !
Greetings, folks ! I just ran into a problem that lets me quite clueless: I recently migrated the Cool VL Viewer build system from VS2005 to VS2010 and succeeded, two weeks ago, to compile v1.26.5.0 under VS2010. This week, I was about to make two new releases (v1.26.4.23 which is basically the same as v1.26.5.0 with just a few things added) and v1.26.5.1 which is the firts release with the v3.3.4 renderer backported (working just fine under Linux). But then I came around an issue dealing with Windows headers inclusion that I just can't figure out. When compiling (either v1.26.4.23 or v1.26.5.1), VS2010 fails for the llwindow library, with the following error (sources path edited to linden\ for clarity): llwindow.cpp linden\indra\llwindow\llwindowwin32.h(45): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(45): error C2143: syntax error : missing ',' before '&' linden\indra\llwindow\llwindowwin32.h(146): error C2061: syntax error : identifier 'COMPOSITIONFORM' linden\indra\llwindow\llwindowwin32.h(147): error C2061: syntax error : identifier 'CANDIDATEFORM' linden\indra\llwindow\llwindowwin32.h(148): error C2061: syntax error : identifier 'IMECHARPOSITION' linden\indra\llwindow\llwindowwin32.h(150): error C2061: syntax error : identifier 'RECONVERTSTRING' linden\indra\llwindow\llwindowwin32.h(177): error C2146: syntax error : missing ';' before identifier 'mWndProc' linden\indra\llwindow\llwindowwin32.h(177): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(177): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(237): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(237): error C2143: syntax error : missing ',' before '&' COMPOSITIONFORM & Co pertain to Imm.h and the errors around lines 45 and 177+ are related to undefined MSG and WNDPROC types (that seem ro pertain to WinUser.h). The weird thing is that I didn't change a single thing in v1.4.26.23 in llwindows/, neither in the cmake files when compared to v1.26.5.0 that (still) compiles just fine !!! I checked the Windows headers inclusion and they seem just fine, with, in llwindowwin32.h: #ifndef LL_LLWINDOWWIN32_H #define LL_LLWINDOWWIN32_H // Limit Windows API to small and manageable set. #define WIN32_LEAN_AND_MEAN #include #include .../... Adding #include after #include in llwindowwin32.h allows to get rid of the undefined COMPOSITIONFORM ... RECONVERTSTRING types, but adding #include doesn't solve the issue with MSG and WNDPROC not being defined, even if I use: #ifndef LL_LLWINDOWWIN32_H #define LL_LLWINDOWWIN32_H // Limit Windows API to small and manageable set. #define WIN32_LEAN_AND_MEAN #include #include #include #undef NOUSER #undef NOMSG #undef _WINUSER_ #include I always get: llwindow.cpp linden\indra\llwindow\llwindowwin32.h(50): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(50): error C2143: syntax error : missing ',' before '&' linden\indra\llwindow\llwindowwin32.h(182): error C2146: syntax error : missing ';' before identifier 'mWndProc' linden\indra\llwindow\llwindowwin32.h(182): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(182): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(242): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(242): error C2143: syntax error : missing ',' before '&' What is totally flabbergasting is that between v1.26.5.0 (which compiles fine) and v1.26.4.23, the diff is only 300Kb and NOTHING in it touches the cmake files neither the llwindow/ files !!! Plus, llwindowwin32.cpp (which also needs and includes llwindowwin32.h) compiles just fine, unlike llwindow.cpp (and yes, I also tried to add the same Windows includes in the latter than in the former, to no avail). Finally, I tried on two different build systems (a WinXP SP3 virtual machine and a genuine (non emulated) Windows 7 Ultimate system), to no avail (not a build system issue, apparenetly, especially since v1.26.5.0 still compiles just fine). Any clue of what is going wrong with this sh*tty VS2010 ? Many thanks in advance ! Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] [SOLVED] Re: Compilation issues under MSVC2010: Windows guru help *badly* needed !
Problem solved !... Man, what a sh*tty, Mickey Mouse OS Windoze (or "Windaube", in French, for puns amateurs) can be ... Its UTTER stupidity and hackiness NEVER cease to amaze me ! The reasons for all my troubles were that: - windows.h contains a "#pragam once" directive (instead of standard, robust and flawless #ifndef _HEADER_NAME_ / #define _HEADER_NAME_ / ... header here ... / #endif guards), which means that the pre-processor will *never* even *try* to include twice that header in nested header invocations. - Somehow (but I didn't yet figured out it all: to be frank, at this point I don't really care any more...), #define WIN32_LEAN_AND_MEAN leads the pre-processor to only include the sub-headers (included from windows.h) that contain definitions used in the file calling the "#include " (and beacuse of the #pragma once, if another, nested file includes this file and contains other definitions requiring sub-headers that have been skipped the first time, it is f*cked up !). - In v1.26.4.23 and v1.26.5.1 I added support for private memory pools, but in a more complete way than in LL's viewer (i.e. proper memory usage functions where added for Linux and MacOS-X in llsys.cpp to be used by the private pools manager in llmemory.cpp), and this lead me to add an '#include "sys.h"' into llmemory.h. And... llsys.h itself already contains an #include ... - In llwindow.cpp, the headers where included as follow: #include "linden_common.h" #include "llwindowheadless.h" #if LL_MESA_HEADLESS #include "llwindowmesaheadless.h" #elif LL_SDL #include "llwindowsdl.h" #elif LL_WINDOWS #include "llwindowwin32.h"<-- With the problem arising here #elif LL_DARWIN #include "llwindowmacosx.h" #endif ...and it comes out that llwindowheadless.h was itself including llmemory.h, which was including (due to my modifications) sys.h, which was including windows.h. Then when llwindowwin32.h was trying to include windows.h in its turn (or winuser.h, after I tried adding it to solve the issue), it failed because of the combined effect of #pragma once and #define WIN32_LEAN_AND_MEAN. The solution was to reorder the includes in llwindow.cpp to read: #include "linden_common.h" #if LL_MESA_HEADLESS #include "llwindowmesaheadless.h" #elif LL_SDL #include "llwindowsdl.h" #elif LL_WINDOWS #include "llwindowwin32.h" #elif LL_DARWIN #include "llwindowmacosx.h" #endif // SHITTY MSVC INCLUDE ISSUES WARNING: // include llwindowheadless.h* AFTER* llwindowwin32.h, else bad // things happen at compilation time ! #include "llwindowheadless.h" Note that I'm still lucky that llwindowheadless.h doesn't need definitions from sub-includes of windows.h that are skipped by the latter when it is included by llwindowwin32.h (if you still can follow all the indirections in this reasonning, lol !)... To prevent such issues in the future, I suggest that the viewer sources are ammended so that #include is *NEVER* done from header files, but only from the *.cpp files using headers files that require windows.h's inclusion; this may lead to have to manually add a few includes (windows.h sub-includes) in the *.cpp files (that might be skipped by windows.h because of the #define WIN32_LEAN_AND_MEAN if some definitions are used in the *.h file and not in the *.cpp file), but at least those includes won't be impacted in case of nesting by the "#pragma once" that hit me hard here, since even: #undef NOUSER #undef NOMSG #undef _WINUSER_ #include could not get past it and prevented the needed winuser.h definitions to be included at all !... I can't provide a patch, since LL won't use it (not having given up my privacy to fill up their stupid "contribution agreement" form and stuff...), but you may consider this info as LGPL (or anything fancying you) and produce the patch yourself. Henri. On Sun, 29 Jul 2012 10:40:02 +0200, I wrote: > Greetings, folks ! > > I just ran into a problem that lets me quite clueless: I recently migrated > the Cool VL Viewer build system from VS2005 to VS2010 and succeeded, two > weeks ago, to compile v1.26.5.0 under VS2010. > > This week, I was about to make two new releases (v1.26.4.23 which is basically > the same as v1.26.5.0 with just a few things added) and v1.26.5.1 which is the > firts release with the v3.3.4 renderer backported (working just fine under > Linux). > > But then I came around an issue dealing with Windows headers inclusion that > I just can't figure out. When compiling (either v1.26.4.23 or v1.26.5.1), > VS2010 fails for the llwindow library, with the following error (sources > path edited to linden\ for clarity): > > llwindow.cpp > linden\indra\llwindow\llwindowwin32.h(45): error C4430: missing type > specifier - int assumed. Note: C++ does not support default-int > linden\indra\llwindow\llwindowwin32.h(45): error C2143: syntax error : > missing ',' before '&' > linden\indra\
Re: [opensource-dev] New HTTP Library & Project Viewer
On Sun, 29 Jul 2012 10:07:18 +0200 Henri Beauchamp wrote: > On Sun, 29 Jul 2012 05:23:15 +0200, Carlo Wood wrote: > > > On Fri, 27 Jul 2012 16:59:18 -0400 > > holydoughnuts wrote: > > > > The implementation that I wrote for Singularity (not yet in the > > the official release) is more on the side of "blazing fast" :p. > > The bottleneck is entirely server-side, but I've seen download > > speeds of 1 MB/s non-stop till all textures were there. > > With just a few tweakings to the texture fetcher (and in particular > a setting that permits up to 32 concurrent HTTP fetches), I get much > more than 1MB/s in the Cool VL Viewer... In fact, I'm more in the > 10MB/s+ range while rezzing in heavily textured areas and the rezzing > time is pretty low... This has been so for many months (well over > a year actually) already. I agree that that would be an advantage for the user; but it's not clear to me if it is allowed (or will be in the near future) to have 32 concurrent fetches. The rationale that it SHOULD be allowed is that the user will download those textures anyway; so, you might as well allow them to get it quickly, in a short time: this has no influence on the average number of open file descriptors on the server. I understand that LL is afraid that once viewers can keep sockets open (for reuse) that the servers run out of filedescriptors. Of course, this is all to true. Therefore I propose to set a limit on the maximum number of UNUSED filedescriptors. However, there should be no limit or a much higher limit, on the number of connections that are actually in use. The question is then: when is a filedescriptor "unused"? Well, I'd say that for the sake of re-use, it can be considered unused if there hasn't been a new request for it for -say- a second. It's probably best to define multiple stages, that is: * Allow a maximum of 32 connections. * Allow up to 32 connections that are unused for 1 second. * Allow up to 8 connections that are unused for 10 seconds. * Allow up to 2 connections that are unused for 1 minute. * Allow 1 connection to be unused for 20 minutes (or whenever one leaves a region and it can be determined that this server won't be needed or used anymore). Of course this means that upon teleport to a new region with many unknown textures, the viewer will make 32 new SSH connections, but that is MUCH less than one new connection PER TEXTURE, as we have now. Then all those connections are reused until all textures have been downloaded (a few seconds). Other strategies are possible, like NOT immediately creating a new connection as long as the maximum of 32 connections haven't been used up yet, but waiting with that until there's a queue of requests building up. Bottom line is, I'm afraid that Linden Lab is going to take the (too) simplistic route as they often have done in the past, and do something very silly like: * Allow a maximum of 2 connections, and allow to keep them open indefinitely. I hope you see the difference :p I argue that something like that makes no sense and would hurt the user because they'd have to wait unnecessary long before everything downloads. -- Carlo Wood ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New HTTP Library & Project Viewer
I would agree with you if all decent HTTP servers (Apache, but not only), didn't have their own throttling algorithms are weren't able to just drop the excess of connections when they run out of sockets. But they do have such throttling mechanisms, so it's no issue at all and in fact, 32 is the max number of connection per IP an Apache server would accept by default (the admin can of course change this setting: it's not uncommon to encounter websites configured for up to 64 connections per IP). FYI, early HTTP fetches code was allowing up to 32 connections already, then it was lowered to 8, then raised back up to 16, and I since lost track of what maximum is currently hardcoded in LL's viewer... That's why I made it a configurable setting: if you start seeing timeouts or "busy" replies from the server in your viewer log, then you can still lower the setting. The default in the Cool VL Viewer is 16, but I have always used 32 myself and never came accross any issue, including in over-crowded sims (and I can enjoy a very fast rezzing experience): of course, you could argue that this is because everyone else in the sim is limited to 8 connections... And you could be right (hard to say: only LL could...). As for keeping only two persistent connections, this can seem a good idea, but on the viewer side it means that the free cores (on a quad core CPU, only one is always used at 100% for rendering, the three others are only (partially) used while decoding textures and for other threads, suchs as fetching/caching) are just sitting there, doing nothing as they wait for a texture to be downloaded from your only two "pipes"... and what happens when a connection stalls and timeouts ?... You loose half your bandwitdh (instead of only 1/32th) !... I would therefore recommend a higher number of persistent connections (16 sounds good and 8 an absolute minimum); alas such connections are precisely very limited (usually 4 per IP) in standard HTTP server configurations (they are considered costy, precisely because they are persistent while the traffic is only sporadic on normal web servers). This means that the grid's (SL and OpenSIM) texture HTTP servers would have to be configured specially to allow a higher limit per IP... On Sun, 29 Jul 2012 15:59:38 +0200, Carlo Wood wrote: > On Sun, 29 Jul 2012 10:07:18 +0200 > Henri Beauchamp wrote: > > > On Sun, 29 Jul 2012 05:23:15 +0200, Carlo Wood wrote: > > > > > On Fri, 27 Jul 2012 16:59:18 -0400 > > > holydoughnuts wrote: > > > > > > The implementation that I wrote for Singularity (not yet in the > > > the official release) is more on the side of "blazing fast" :p. > > > The bottleneck is entirely server-side, but I've seen download > > > speeds of 1 MB/s non-stop till all textures were there. > > > > With just a few tweakings to the texture fetcher (and in particular > > a setting that permits up to 32 concurrent HTTP fetches), I get much > > more than 1MB/s in the Cool VL Viewer... In fact, I'm more in the > > 10MB/s+ range while rezzing in heavily textured areas and the rezzing > > time is pretty low... This has been so for many months (well over > > a year actually) already. > > I agree that that would be an advantage for the user; but it's not > clear to me if it is allowed (or will be in the near future) to > have 32 concurrent fetches. > > The rationale that it SHOULD be allowed is that the user will > download those textures anyway; so, you might as well allow > them to get it quickly, in a short time: this has no influence > on the average number of open file descriptors on the server. > > I understand that LL is afraid that once viewers can keep sockets > open (for reuse) that the servers run out of filedescriptors. Of course, > this is all to true. Therefore I propose to set a limit on the > maximum number of UNUSED filedescriptors. However, there should be > no limit or a much higher limit, on the number of connections that > are actually in use. The question is then: when is a filedescriptor > "unused"? Well, I'd say that for the sake of re-use, it can be > considered unused if there hasn't been a new request for it for > -say- a second. It's probably best to define multiple stages, > that is: > * Allow a maximum of 32 connections. > * Allow up to 32 connections that are unused for 1 second. > * Allow up to 8 connections that are unused for 10 seconds. > * Allow up to 2 connections that are unused for 1 minute. > * Allow 1 connection to be unused for 20 minutes (or whenever > one leaves a region and it can be determined that this server > won't be needed or used anymore). > > Of course this means that upon teleport to a new region with > many unknown textures, the viewer will make 32 new SSH connections, > but that is MUCH less than one new connection PER TEXTURE, as we > have now. Then all those connections are reused until all textures > have been downloaded (a few seconds). > > Other strategies are possible, like NOT immediately creating a > ne
Re: [opensource-dev] New HTTP Library & Project Viewer
Does increasing the HTTP connection limit also increase the burden on the server and network? Increasing the HTTP connection limit on one client might improve the experience for one person. It might also diminish the experience for everyone else on the same server. Sheet Spotter -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Henri Beauchamp Sent: July 29, 2012 9:23 AM To: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] New HTTP Library & Project Viewer [...] FYI, early HTTP fetches code was allowing up to 32 connections already, then it was lowered to 8, then raised back up to 16, and I since lost track of what maximum is currently hardcoded in LL's viewer... That's why I made it a configurable setting: if you start seeing timeouts or "busy" replies from the server in your viewer log, then you can still lower the setting. The default in the Cool VL Viewer is 16, but I have always used 32 myself and never came accross any issue, including in over-crowded sims (and I can enjoy a very fast rezzing experience): of course, you could argue that this is because everyone else in the sim is limited to 8 connections... And you could be right (hard to say: only LL could...). [...] ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
