Depends on the field, but it is very common in computer science and generally in natural sciences. Studying computer science, I don’t think I ever even wrote as much as a paper in German; everything’s English.
This is the first time we're hearing performance in that magnitude, and it's definitely not the intended frame rate. It sounds like your system is switching to software OpenGL rendering, rather than running directly on your GPU. Could you please share more details about your system on Github? https://github.com/mapbox/mapbox-gl-js/issues/new
I just updated my GPU drivers using the xorg-edgers PPA on Ubuntu 14.04 (https://launchpad.net/~xorg-edgers/+archive/ubuntu/ppa) and now it's a lot better. Dragging the map, there's a small delay before the map moves, but when it does it's smooth. I remembered that I was having problems with Google Maps, as well as other Web GL stuff, so I figure there was a bug in my drivers.
> I'm not sure why there's a bias factor of 2 in the "raster" fragment shader -- looks like it might have been added by accident.
Yes, that was an accident. Thanks for noticing! We definitely have a lot of information to share about the process. Regarding clipping, we're not sure yet whether what we have right now is the best thing; there will certainly be improvements in that area.
Thanks - yes, I initially tried this, but I believe the exported format is for mapnik2, whereas the mod_tile package I am using seems to be for mapnik 0.7. I didn't really know what I was doing at the time and figured that I would edit the XML files that already seemed to be working.
Basically the answer to all of these questions is that it's easier to decode in the browser. A UTFGrid is just plain JSON, so we can just run it through JSON.parse(). PNG uses zlib compression, so we can get that benefit for free when sending gzip over HTTP. Here's some more design rationale: http://developmentseed.org/blog/2011/09/21/how-interactivity...
As a side note, I send my PNG when needed in JSON (larger, with base64 encoding, I didn't try to make a comparison with ASCII art format) and I find that with getImageData getting the indexed colors is fast and easy. I was referring to bidirectional compression because PNG filter (applied before the deflate) uses the fact that pixels are often similar on both axes.
Of course, without a few tests and comparisons, I can't be sure I really gain in size, but I like to use the fact that my map is an image (faster to draw on the screen at some resolutions and image manipulation server side - my zero indexes are simply mapped to the transparent "color" as is common in most color palettes).
I have different constraints trough, as my map contains 3200x1600 pixels and not 64x64, so that I really need those compressions for instant display.
Because [] is not syntactic sugar for new Array.
The code the article wrote about doesn't work in any implementation that I know of.
I think the ESv3 spec wasn't very clear:
"Create a new array as if by the expression new Array()."
But the implementations (always?) did the right thing, and the ESv5 spec is more clear:
it adds "where Array is the standard built-in constructor with that name."
This comment and the GP suggest that the article is wrong. Is it? Can anyone confirm a JS implementation that manifests the described behavior (the Array constructor being called when parsing top-level [] in JSON)?
