The effect you were seeing was a difference between hardware and
software compositing paths.
Chrome was promoting the content area to a hardware-accelerated
layer during animation, but dropping it back to software after the
animation was complete. There were little animations for the
checkmarks that were causing us to flip in and out of hardware mode
as you moused around.
Solution: force us to stay in hardware mode the entire time the
nav is open (translate: scale3d() is a well-known way to do this).
Bonus: the scaled text rendering looks better in hardware mode.
BUG: https://code.google.com/p/camlistore/issues/detail?id=284
Change-Id: I62f6c86d1ae12ba043f34c0659633bb5195dc50c
On at least OS X, the stat(2) call will use an existing node without
issuing Lookup. This introduces a filesystem inconsistency where a
delete removes an entry for further requests, but FUSE's cached access
of the node is still used for at least stat.
There's a call to Access directly against the node as retrieved from a
prior Lookup. By invalidating the nodes when they're deleted and
verifying this at Access time, we keep things more consistent.
This isn't exactly camlistore.org/issue/324 as described, but it was
causing one of the tests to fail on OS X
Change-Id: Ib90a1de79d6d3960f96bac5b4fb448c952c4ba66
If we ever return a particular value for a root, we should continue to
return the same value to provide a consistent view.
camlistore.org/issue/324
Change-Id: I7cfad02ad742b0e70e333f70779d64ba163d68a6
As blob.fetcherToSeekerWrapper.Fetch erroneously asserts that FetchStreaming
returns a ReadSeekCloser everytime, it had to be changed.
Move MaxBlobSize from blobserver to constants (new package).
Change-Id: I4b4f22c302cbec84d77d21454e0c9e8aebdf73e5
also changed osutil.HomeDir for windows so it looks like an abs path for
filepath.IsAbs
http://camlistore.org/issue/290
Change-Id: I1b32c1c13e7d23a421a6da2c0f9d6b8b07f48b8d
Move from one pool for all thumbnail resizing to per-ImageHandler
instace.
Uses the value of "maxResizeBytes" if specified in the "handlerArgs"
section of a "publish" or "ui" handler's low-level config.
If we end up wanting to share pools, i.e. if all published
handlers should share a pool, we'll need to do a bit more work.
Implements suggestion from https://camlistore.org/r/1803 review.
Further improves on https://camlistore.org/issue/316.
Change-Id: Ia93fad119b546064173ac3e2c7f0ab8509744628
The RAM limit is based on the expected amount of allocations not the
measured allocation.
Issue https://camlistore.org/issue/316
Change-Id: I3ccff6ddf880f3f9a90f6c27f15f9662fad02712
I meant to do this in Camlistore commit cc562aff, but that one only
updated to 1389e13 (Jan 23, 2013).
I was confused because the version of third_party/closure/updatelibrary.go
that was checked in prior to cc562aff did not correspond to the version of
Closure that was checked in. So when I ran updatelibrary.go, I got changes
and didn't realize I had to change updatelibrary.go too.
Change-Id: I3ba43a540a62caedbf7570a6d55382bd39a426dc
No more dynamic upload URL, which trips up half our new users behind
reverse proxies when the camlistored process doesn't know its
forward-facing URL.
The original camlistore stat + upload protocol was influenced by App
Engine's limitations at the time, and some of our indecision about
where the Camlistore design is going. We understand the Camlistore
design now, and App Engine's former limitations are gone. Time to
clean things up.
More REST-y now too.
See http://camlistore.org/issue/123
Change-Id: I92c6552f830b925cef379c204a982a2213bf2f4b