Construct 2 Camera Scroll on Forms produces a lag effect on HTML Elements

Construct 2 Camera Scroll on Forms produces a lag effect on HTML Elements

Hi everyone, when I use the camera to scroll in C2, it looks fine when I debug in chrome. Yay.

When I export to C3 and build for iOS, scrolling lags.

That is, the HTML elements only update every 0.5 seconds, where the Canvas may be updating every tick? This produces a horrible and gross scrolling effect.

Any one know how to resolve? I would LOVE to build my apps in C2/C3 but they require input forms...

WAIT! Upon posting I went back to chrome and I can indeed see the lag effect!

I wonder if I can just write better code for camera scrolling......

There is a gif of the problem.

It appears the setInterval for scrolling in the C2 engine is too slow? It doesn't match the speed of the camera. The frequencey is not the same?

How could I overcome this to get smooth scrolling text. It doesn't look so bad here but on an iPhone 7 it's AWFUL.

Forms aren't part of the canvas and aren't rendered at the same time.

The only way to fix it would be to make the forms out of sprites, tiled backgrounds, text objects, etc.

It looks like it’s lagging a frame behind to me.

As I recall, the order things run in construct is basically:

1. Update plugins

2. Run event sheet

3. Draw

4. Repeat

The edit box’s position is probably updated in 1, so if you set the scroll position at all in events then it will take till the next frame to update the editbox’s position, hence the lag.

Probably would make a nice bug report if you want to go that route.

For a more immediate solution you can position the editboxes manually with events. I don’t mean the set position action though. I’m pretty sure that still won’t update the physical position till the next frame.

Anyways you can try using some css to position it since there’s an action to apply some css to the object. I don’t know offhand which css to use but you should be able to find a list of them perhaps. Positions will be relative to the page instead of the layout so you’ll need to convert it with the layoutToCanvas expressions.

A second idea is to use a bit of js. If you set the id property of the editboxes you can access it in js with document.getElementById(“id”).

From there you’d need to look up the js properties exposed that you can use.

I apologize it’s a bit vague. I did post a similar example capx once before, but I doubt I’d be able to find it while on my phone.

Since this is in the C3 section, the easiest bet would be a bug report and hopefully it can be fixed in a timely manner.

This happens in C2/C3 the way.

I think what I'll do is custom create inputs. Which kinda sucks.

But. Hey.

I meant since it’s c3 it’s more likely to get fixed.

But a custom text input could be nice. It would give you more freedom to style it. Tedious, but gives more control.

Btw here’s the capx I mentioned above. It was solving a different problem but may have useful bits.

dropbox.com/s/iaunubjjay2b5ws/position_clip_dom.capx

I was going to rant about construct quirks/bugs and website issues but eh. I’m just a casual user. Maybe they could hire a dedicated bug tester instead of just users that encounter bugs and go through the effort to report them.

Here is a quick fix you can use in your project. Event 2 to be specific. Just put it after whatever scroll events you have.

dropbox.com/s/ymw2s6futtvpzm0/scroll_w_textbox_fix.capx

I put red boxes under the textboxes as a visual test. With event 2 enabled you don't see the red boxes when scrolling. When disabled you see the issue you have.

The only issue now is when the textboxes are half off the screen. That other capx should help with that but it's a problem for another day.

cheers.

So your method leads me to understand that the CAMERA LOOK AT feature is causing this issue.

If I move objects directly via X and Y positioning, it works.

I would suggest that the C2/C3 engine LookAt plugin is updated to re position DOM elements more promptly.

Big find here: Text elements can only be positioned at INTEGER values.

10, 15, 20 -- NOT 10.2, 15.00001, etc.

So I think this is what is causing the lag. The renderer is trying to put an HTML input at 202.2324 and it's freaking out.

I have now tried to round() the value to elimate the decimals... let's see.

Rounding did not help. HTML elements still lag like crazy.

Like I said above, it lags because they are positioned a frame behind. The reason is because the position is updated after the frame is drawn.

Yeah and it looks like shit. My client is pissed.