• Content count

  • Joined

  • Last visited

  1. Jittery scrolling and how to handle texture frame properly.

    I've just tested it on my Android device and I don't appear to see any jitter! Thanks!
  2. Jittery scrolling and how to handle texture frame properly.

    Oh I have internet here so I am able to test it on my Android device.
  3. Jittery scrolling and how to handle texture frame properly.

    I assumed it was still jittery because you said so and I have to go now (so I was not able to test it). I'll have a look when I get home then because I assume you were joking?
  4. Jittery scrolling and how to handle texture frame properly.

    Thanks for the corrections and investing time in this! Do you have any clue as to why the jitter is still there?
  5. Jittery scrolling and how to handle texture frame properly.

    Thanks for your reply! I set the precision to high. But it doesn't seem to work. It's still jittery when using mobile or desktop devices. I made a fiddle here: If you pay attention to the vertically scrolling colours you will notice the occasional jitter. I'm not using two sprites and not even an easing formula and it's still jittery. But maybe I'm doing something completely wrong though.
  6. No matter what I try or how I implement things, I keep getting some jittery scroll movement. I was using the <canvas> tag before this, without PixiJS and it was a lot of jittery movement. Just one drawImage call per rAF-call would take far more than 16,6 ms. I used the <canvas> for drawing frames. But I also used the transform CSS property for instance. With and without CSS transitions. But currently I'm using PixiJS with a RenderTexture and the scrolling still seems somewhat jittery to me, though maybe less jittery. I'm not drawing vector graphics. I'm drawing images (PNG files actually). When an image has loaded I add it to a somewhat large RenderTexture (4096x4096). Because width of the images don't exceed 1024 pixels, I now store the images inside four columns of 1024 by 4096 pixels. I then have a sprite for which I create a Texture (which I recently found out to be just a reference to a BaseTexture combined with a certain frame). Each time I scroll I create a new Texture pointing to the same RenderTexture but using a different frame. Though at a certain point it seems I need two sprites with textures both pointing to the same RenderTexture but with different frames. Because, let's say, when the first frame starts at 4000 and I need about 800 pixels from the image (e.g. 800 could be window height or screen height) I need to have a frame pointing at the last 96 pixels of the first column within the RenderTexture and a frame which points to the other column, getting the remaining 704 pixels. Should this be a proper way of handling this? Or is there a faster way to handle this somehow? Maybe I could make sure to make the height of the columns within the RenderTexture are dividable by the current window height. Though then it would mean some column height would go unused (but then this would probably be true for all columns, so maybe not such of a big deal). And this reordering would then need to happen each time a resize occurs. I guess a large screen size (regarding height) would not work very well with how I'm handling this now? Any advice would be much appreciated By the way, I'm also using a small easing function which I call via setTimeout when there is movement. But the actual drawing takes place currently in the ticker function. It just calculates current scrolling speed, does not draw anything.