Age | Commit message (Collapse) | Author |
|
Change-Id: Ibd7c6ac56e56cf0e3e706a905603ef1a17a4579c
|
|
Change-Id: I3cfd5819be8075869906dac3b963b4d0b2cf2890
|
|
Change-Id: Id2aa869f05b09dc22676d63390ec10bf575571ef
|
|
Change-Id: I06ecb06df4df61fccc53477b5789a171e62248ec
|
|
Change-Id: Ic65795a1b7bfe0435292f87f27ae39e2c3069fed
|
|
Change-Id: I482d0a488e9de5b59ce74b9c4057b4103fb048dc
|
|
Change-Id: Ie5efb45d401721e844e3137474c1a7473a1ac144
|
|
Change-Id: I853ab39599fdc8d1b1eae5d2b2748f39535ebf64
|
|
Change-Id: I30e177b45b0e25d92fd7dea02ffe4e9c0731dce5
|
|
Make the GestureImageView constructors take a OnGestureListener, and
store that, Move the FlingListener class into
GestureImageViewTouchListener so that FlingListener has access to the
fields of GestureImageViewTouchListener. If the image is fully zoomed
out and can't be dragged, pass flings on up, to DocumentLoader's
gestureListener.
Change-Id: I574280de23bdab2772a361833f561dff3e182bcd
|
|
Change-Id: I52590908e6ba59c19aded2771d779c1cfa3a45ea
|
|
|
|
Change-Id: Ib4a57649ec98bcbce851687633f35e52771f137a
|
|
|
|
Change-Id: I66ae59fe88411f3f0d2423fd6f1412f7ac0e1a36
|
|
Change-Id: Ia3d5538feaf1fc0aad4a0f1d901ae7bd22eae61d
|
|
Change-Id: Ib1e76687054a254a9918a4391a1cb512c59c6515
|
|
Change-Id: I085024b6bfccf6846167a5de316912a395f4e301
|
|
Pass on to VirtualDevice where used to set the MapMode of the device
appropriately. Adapt DocumentLoader, use to scale the page rendering
to exactly fit the virtual device.
Change-Id: I4b0bc67e12114d3d9d493ff1aca2ef5d2cc78912
|
|
Change-Id: I0b1523b5c898375b5cf23294b0a9462a6a651e32
|
|
Render directly to a direct ByteBuffer allocated on the Java side.
Change-Id: I2d66e4146df77e92260918a78ef22cd9b8c95384
|
|
Change-Id: I9f44547fbc5e13daa297720dfd814d2192114125
|
|
Modify DocumentLoader correspondingly. Take Android bug 32588 into
account.
Ideal would be to extend the XDevice stuff, or something, so that one
could hand it a pre-allocated RGBA buffer into which the
drawing/rendering would go. Then one could get rid of the silly
convert-to-BMP phase, which prefixes the bitmap data with BMP and DIB
headers (and thus, I guess, has to copy and allocate another
copy). Will see.
Change-Id: I4597cd933db8faa8105dc8f19638d712d5d2238a
|
|
Change-Id: I916c36b3b55681cdf8f0d1ffd0236e54f3b67b86
|
|
Change-Id: Ie0735d4eb903b38a44bef8110bf520cfde54cb09
|
|
Now I get (a page of) the document rendered into a
bitmap. Unfortunately css.awt.XBitmap::getDIB() provides an in-core
24-bit (BGR) BMP file. (Yes, despite the name, it's not just the DIB,
but is prefixed with a BMP file header.) Android's Image class wants
RGBA. Hmm.
Change-Id: Ie0effef20751e1959644861af358d81538b6d6ea
|
|
Change-Id: Ifcfdd33631c257d2cf6f54fe0d00444200f48335
|
|
Change-Id: I8ad45f173c4f2b37aca6506d9021e8346c17db16
|
|
Change-Id: I2623625380b11f3d6bf720387504b23ccce529e1
|
|
Change-Id: I725255224ae7a38d7a7843516b7ac979f79e0207
|
|
Change-Id: Ibfafe0d6420ad59e12b9eed4847c89e57a18d679
|
|
Change-Id: Ic87be0146360c5e32f1f12f255c897e051c9a50c
|
|
Change-Id: I3183ed3da25bd0fbd2121f235f209edb51a21d2e
|
|
Change-Id: I81b3a451b5fd4eaf83ee525aa38df32686e38cfe
|
|
Change-Id: I9c652fc6940bd856aa8ba5f7e2daaae6a5502b3d
|
|
|
|
|
|
|