We have an applet that displays item images and text. Our previous version scrolls vertically. You can see it at [login to view URL] We are making a new version that scrolls horizontally and currently the scrolling is not smooth. You can see this at [login to view URL] Our coder needs help finding where the problem is and perhaps in solving it. Please say whether your bid is just for identifying where the code needs to be changed, or whether it is for fixing the problem, and also estimate how soon you could have it done. I'm attaching source code and his explanatory notes are pasted below in the 'Deliverables' section.
## Deliverables
Notes: -------- [login to view URL] and [login to view URL] are the two files of note in this problem. Bitmap is called for the initial composition of the picture, from it's parts. If the composition's overall x is off, it could cause the image to be offset in the slider. Note that this does not handle the border masks, which are added by [login to view URL], later. Slider does the drawing and animation. * After construction it sets up the initial bitmaps and draws them. * Later images are largely handled by _l0, and _l3. The code here is mostly redundant, so must be updated at once, keeping things matching one another. * The onEnterFrame event handles is mostly responsible for the sliding, with BitmapEx.o being called as necessary to get new images. The problem manifests as the slider scrolling, pausing a half second or so, then jumping left about 30 pixles to it's final position (which, itself, seems about 30px too far left.) I suspect this may be an offset problem with the BitmapEx function, composing the images too wide and causing the final image offset issue. The problem would likely be in the widths not matching up properly, so the actual solution could be in [login to view URL] Another strong possibility is a problem with the scroll function not scrolling far enough. The start of the next loop causes it to "jump" to it's expected position when it's drawn there. In this case, both the start position and the distance scrolled would have to be tweaked a bit to compensate, and ensure that the images are left in a 3 image wide arrangement, without being cut off. If you need to diff against prior versions, set your diff to ignore whitespace. The indent was corrected in this version because the prior versions indent was too haphazard to really read/debug heavily. Earlier versions around 7.4.3 still had a large amount of old animation code commented out, which could be helpful to go over, even though the methods used in them aren't used any longer. There seem to have been significant changes in the interim, but you can somewhat follow the logic of what was happening. And an addition to the notes that came to mind: adtop and tower display are both used at various points to flag if the slider is in graphic mode (which it always is,) and if the theme is being drawn (which it is, in this case.) Presume they are always true, for the sake of this. _ftb and _fbb are the right and left image borders, attached to the image in [login to view URL] - I presume that's "frame top bitmap" and "frame bottom bitmap." They are attached, so by the time of the scroll, only the main object gets scrolled. You don't need to scroll them separately. (I'd intended to rename them more descriptively when all done, but left the variable names as is for now.) Which is currently left and which is right is commented. The _ftb and _fbb images are attached at 4 points in the code, so make sure to keep all the offsets in sync when updating. _ts is frequently used as an offset, I believe that's "text spacer" or something similar, from when the text was at the bottom. It has to be watched a bit to make sure it's in sync with the rest of the movement vars. Again, planned to fix this name/functionality in cleanup but left it as is at the moment. The problem may also be that the scroll area is too wide, and not a multiple of the image width. This would be causing the images to scroll, stop, then lurch to line up with the image area. 1) All deliverables will be considered "work made for hire" under U.S. Copyright law. Employer will receive exclusive and complete copyrights to all work purchased. (No 3rd party components unless all copyright ramifications are explained AND AGREED TO by the employer on the site per the worker's Worker Legal Agreement).
## Platform
Action Script. Current IE, Firefox, Chrome, Safari.