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
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
As far as I know, the code never uses the third level.
This reduces a particularly bad example of https://code.google.com/p/camlistore/issues/detail?id=319 from returning 1.8MB of data to a svelte 1.2MB.
Change-Id: Ibfe4ca3f1b175cd316f6f603950991c1a2fc8577
More secondary preimage resistance. Also better docs and less vague and less promoted Android
UI.
Feedback from Adam Langley, but likely misinterpreted.
Change-Id: I3bf1029b6fc07c0b8dab2af44926aa87b0d4cbad
We were observing UI jank, which ended up being due to GC. Even with chunking
and very small chunk sizes, it was hard to reliably get 30fps on my macbook.
Moving to a worker completely solves the problem. We stay at 60fps the entire
time the hashing is taking place, no matter how many files/how large, etc.
Also, switch to using Closure's crypto support, which has been added since
the upload code was originally written, since it hassupport for incremental
hashing, javascript typed arrays, and other niceties.
Change-Id: I018d6839b2cf037b8d6b03e1a0ea7164bc5a782d
a search result..
When you are paging, typically only one request is done, for the big
image. However, if you reach the end of the current search session,
more results are loaded.
The URL updates during paging, and if you navigate to this URL fresh
the search will be performed first.
Change-Id: Ia2b9bbb4a2eb41a3a75971d0dc1ff4f3d93b4acf
The detail view now loads with only two HTTP requests: one for the
piggy, and one for the big image. No other resources are loaded,
even the blob descriptions, because they are cached by SearchSession,
which is shared between the search ui and the detail ui.
Likewise, when you go back to the search results page, no additional
requests are done.
Also:
- When you press back on detail page, scroll position is now usually
restored (if you refresh between index and detail, it still won't
restore).
- Detail page live updates! It came for free with using SearchSession.
Change-Id: I58ada7bdd30afc2644860fbda6167fc5ce865b0d
This will also be used by the detail page to facilitate fast
flipping and live udpates.
Also fixed the thing where we discard the websocket responses and
re-query for all updates except the very first one.
Change-Id: Iac196670db967f1d41b20ce30641118ede61f3c2
Brad Fitzpatrick