-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better image preloading order #10
Comments
that would be cool! |
yes this would be a great idea to implement. |
Well, good then I'm working on this feature these days ;) |
…t and reference to the instance data storage retrieval `get` method. It is then supposed to resort input sequence in better preloading order and return the reordered sequence Array. This one puts first the initial frame and adds one more opposite the initial one. This way it divides the range into two segments and then continues dividing them in halves again and again gradually increasing the image fidelity. #10
…e to start the (opening) animation right away without waiting for the preload to finish. #10
…sequences to set the transparent image `src` attribute, because it introduces a brief flash of void. So we apply it only for sprites. #10
…lems - didn't go well. Reverting (at least for tests comparison). #10
…and dual-orbit setups suffered a bit from the even spreading across all rows*frames. Therefore it has been adjusted to better fit multi-rows so that the initial row is completely spread first and the rest of rows follow. This results in much faster availability of the possibly animated initial row. #10
…o. Also the tested function has been run twice before - fixed. The fix introduced different way of receiving the result by using instance's `.data("images")` instead of calling the function to get the result directly - this however holds whole paths as strings, so adjusting the expected values to be strings instead of numbers for the `deepEqual` comparison. #10
…and dual-orbit setups suffered a bit from the even spreading across all rows*frames. Therefore it has been adjusted to better fit multi-rows so that the initial row is completely spread first and the rest of rows follow. This results in much faster availability of the possibly animated initial row. #10
…o. Also the tested function has been run twice before - fixed. The fix introduced different way of receiving the result by using instance's `.data("images")` instead of calling the function to get the result directly - this however holds whole paths as strings, so adjusting the expected values to be strings instead of numbers for the `deepEqual` comparison. #10
…r row 90° apart are loaded first and then the "resolution" increases until it's 1:1. #10
Folks, I soon abandoned the original idea (but that doesn't make it bad at all - it just seems far to linear to me now ;). Instead, I wanted to build up a solution, which would load the frames in more of a scattered fashion, where the loading "penalty" would be evenly spread amongst all. This way, instead of one large shrinking gap of missing frames, there will be many small shrinking gaps spread evenly across the entire 360° spectrum. Resulting in perceived lower rotation fidelity/quality/smoothness instead of an apparent gap. So, I tailored a mechanism, which aims to accomplish it. First it queues up one frame each 90° (very rough rotation, but already possible) and then it works with these 4 resulting segments. By progressively halving them, segments are gradually and evenly filled up, increasing the fidelity and smoothnes of the rotation. Speaking in degrees:
You can see it in action on http://test.vostrel.cz/jquery.reel/test/sampler.html - for sequences the bottom-most section "Images" features all frames in order of preloading (via new data key For multi-row and dual-orbit movies, the mechanism is the very same with just one difference, that the initial row is queued first and all remaining follow. I'm pretty happy with the outcome so far. What do you think? |
... and for those wanting to grab the code to test it themselves, it is being developed in a 10-preload-order branch. |
wow your approach does seem to load better, and it has sense. very very nice work. sidenote: performance wise it's always good to set the width and height tags of the image. so is there a way for jquery reel to add width and hight to the images created from jquery reel array. it can use the same width and height of the main "img" on which the jquery reel is initialised. thank's man. keep up the good work. |
I've made a little visualisation to help us better understand the so called Increasing Fidelity approach: From the vis I recognize one possible weakness - the directionality of the (clockwise) queuing. It is still too linear to me, but it'll do. @cindreta, you are right! Loading with defined dimensions is indeed faster, when the image is to be rendered (not our case, I'm afraid), but I guess it won't hurt and is worth the try. Thanks, it's a good one :) @cindreta, to your other question: yes, it should be faster. But frankly, saving 1 frame from let's say 36 total isn't a big deal I guess. On the other hand having the entire |
…e preload placeholder `<img>`s to possibly facilitate the speed benefit of loading images with pre-defined dimensions. Using stage dimensions. #10
…near()` (which just outputs the input) inside new `$.reel.preload` collection of possible preloading routines. User can now choose one of `"linear"` or `"fidelity"` (or any othe custom for that matter) preloading order using the new `preload` option. Incorrect values are corrected to the default `"fidelity"`. #10
As a part of this issue a new
As I want to leave the preloading logic ideally completely up to you, you can set up your own custom preload order function. It has to be defined as a member of
For the mode to be used, you then set the
Pull requests with better preloading orders will be warmly welcome! ;) |
…and dual-orbit setups suffered a bit from the even spreading across all rows*frames. Therefore it has been adjusted to better fit multi-rows so that the initial row is completely spread first and the rest of rows follow. This results in much faster availability of the possibly animated initial row. #10
…o. Also the tested function has been run twice before - fixed. The fix introduced different way of receiving the result by using instance's `.data("images")` instead of calling the function to get the result directly - this however holds whole paths as strings, so adjusting the expected values to be strings instead of numbers for the `deepEqual` comparison. #10
…r row 90° apart are loaded first and then the "resolution" increases until it's 1:1. #10
…e preload placeholder `<img>`s to possibly facilitate the speed benefit of loading images with pre-defined dimensions. Using stage dimensions. #10
…near()` (which just outputs the input) inside new `$.reel.preload` collection of possible preloading routines. User can now choose one of `"linear"` or `"fidelity"` (or any othe custom for that matter) preloading order using the new `preload` option. Incorrect values are corrected to the default `"fidelity"`. #10
…and dual-orbit setups suffered a bit from the even spreading across all rows*frames. Therefore it has been adjusted to better fit multi-rows so that the initial row is completely spread first and the rest of rows follow. This results in much faster availability of the possibly animated initial row. #10
…o. Also the tested function has been run twice before - fixed. The fix introduced different way of receiving the result by using instance's `.data("images")` instead of calling the function to get the result directly - this however holds whole paths as strings, so adjusting the expected values to be strings instead of numbers for the `deepEqual` comparison. #10
…r row 90° apart are loaded first and then the "resolution" increases until it's 1:1. #10
…e preload placeholder `<img>`s to possibly facilitate the speed benefit of loading images with pre-defined dimensions. Using stage dimensions. #10
…near()` (which just outputs the input) inside new `$.reel.preload` collection of possible preloading routines. User can now choose one of `"linear"` or `"fidelity"` (or any othe custom for that matter) preloading order using the new `preload` option. Incorrect values are corrected to the default `"fidelity"`. #10
…e preload placeholder `<img>`s to possibly facilitate the speed benefit of loading images with pre-defined dimensions. Using stage dimensions. #10
nice, than you man :) gonna go implement the new version right away |
Glad you like it. Merging it into development. |
Just missing annotations examples - the'll be in the beta. Changes: * Non-`wheelable` Reels now allow scrolling of the page when wheeling above the Reel instance. * New option `attr` allows to set custom attributes of the IMG tag (useful for re-using DOM nodes). * Instances being re-instantiated now perform automatic teardown (GH-62). * Proper image preload events unbinding on teardown (GH-64). * Option `scrollable` can disable page scrolling (if needed) on touch devices. * New event `"openingDone"` now announces the end of opening animation (GH-65). * Internal event `slide` renamed to `pan` (GH-51). * Actual frame number is manifested with a wrapper class name, e.g. `frame-8` (GH-69). * Improved order of preloaded images gradually increasing fidelity of the image, thus the name `"fidelity"` and this mode is now default. The former order is designated `"linear". Preloading mode is chosen by new `preload` option accepting a mode name. (GH-10). * Deprecated options `hotspot`, `tooltip` and `reversed` have been removed. * Bare click on left/right half of the image steps the Reel one frame forward/back. Set `steppable` to false to disable. Comes with `"stepLeft"` and `"stepRight"` events (GH-20). * Custom text/graphics can augment the frames using the brand new `annotations` feature (GH-36). * New complementary `.unreel()` function to revert effects of `.reel()` on the DOM. * Control event `play` now accepts optional `speed` parameter. * Mouse cursor is now customizable with the new `cursor` option. The new failsafe cursor is now `"move"`.
…. Sample with 6*20 frames revealed a insufficient covering of few frames following the first prioritized row. #10 To resolve this I added a switch, which makes each pass be first substracted from the base, then added, substracted, added... This way has no problems with covering even dark corners ;) Also the rounding now happens only on granule itself, not on the whole result, which had a negative effect of rounding negative numbers in a unsuitable way (-2.5 got rounded to -2, whereas I'd like -3 for the purpose).
======== Lovely new features: * in-picture annotations * new image preloading method * frame by frame stepping * new data change model * full documentation * jQuery 1.5+ New options: * `annotations`, `attr`, `cursor`, `steppable`, improved `images` New events: * `stepLeft`, `stepRight`, `openingDone`, improved `play` New methods: * `.unreel()`, improved `.reel()` Includes fixes for issues #10, #20, #36, #51, #62, #64, #65, #69, #103, #110, #111, #113, #115, #117, #122, #124, #125, #126 Enjoy!
Olivier de Broqueville expressed an idea to improve preloading of images by changing the order of loading the frames. He suggested loading the very first image, then the ones to the left and right and progressively continue.
For example (36 frames total, first frame is 1) the loading order would be:
Please vote for this issue!
The text was updated successfully, but these errors were encountered: