Also, I believe Sam and Ryan have both addressed
the wiki speed issues, and it is much faster now.
Ah, well, it really got better, down to around 1000 ms for the initial
GET for me.
Although, javascript and css not being cached (why?) still the reason
for awful time-to-display,
and occassional spikes of up to 3000 ms frustrate.
I think OpenGL’s GLAPI pages with their stable 600+/-100ms
time-to-display should be something to strive for.
Also it’s not like I decided to use OpenGL because of opengl.org’s
pretty looks, and neither the SDL’s situation differ any much from
that. There really isn’t any alternative in the niche, it isn’t a game
engine after all, so the focus shifts from pure marketing to catering
to developers’ need of good reference material, and that’s where the
wiki performance is critical.
That’s a site about a library, no? Kinda expect the most used part
would be the API documentation, examples and caveats, not some
flashbang about being great.This is a common complaint, and the common answer is: the wiki is community
driven, so it is up to the community to keep it up to date.
My complaint wasn’t about the wiki content - it was about its speed
issues, which are, for the most part, the reason of problems with its
content. And the speed issues aren’t something the community normally
can fix without forking the wiki.
Doing web-highload stuff for about seven years already I can certainly
help with that, but just the wiki access won’t enable me to.On Wed, Jul 17, 2013 at 12:58 AM, Alex Barry <alex.barry at gmail.com> wrote:
–
./lxnt
(but I am obviously biased)On Thu, Aug 8, 2013 at 8:10 AM, Sam Lantinga wrote: