Lag when pinning button to sprite

Wanting to expand upon the use of Construct2/HTML5, I recently made the switch from wxwidgets to HTML5 form elements.

Having done so, I recently ran into a somewhat unfortunate issue that I hope someone will be able to help me alleviate.

It all began when I started implementing simple, draggable window sprites which I would then overlay with one or multiple buttons.

Pinning those buttons to the sprite worked rather well until I realized that, upon dragging the window, the button would always lag a bit behind.

Unfortunately, I cannot currently upload the .capx but it's something that is rather easy to reproduce.

1. Create a sprite

2. Create a button

3. Add pin behaviour to button

4. Add drag and drop behaviour to sprite

5. "On Start of Layout - Pin button to Sprite

The only solutions I could find so far are:

a) Replace buttons with sprites (would be a shame, considering the flexibility I get from CSS styled buttons.

b) Destroy and recreate the button whenever the sprite is dragged (doesn't work too well and is probably a huge resource hog)

Did you try not using the pin behavior and instead using a 'set position'?

Did you try not using the pin behavior and instead using a 'set position'?

Yea. First thing I tried.

Yields me the exact same amount of lag, unfortunately.

Buttons are form controls and aren't really designed to be used like that. Perhaps you could just use a sprite as a button.

Buttons are form controls and aren't really designed to be used like that. Perhaps you could just use a sprite as a button.

I think I'd rather blow up my computer by updating the state of the buttons every single pixel than converting my buttons to sprites, no offense.

List controls seem to work well, btw. No such behaviour, even when combined with sprites in that exact same fashion. Which kept me thinking, perhaps I should program a list control in such way that it will be indistinguishable from it's button brethren. Webkit browsers all appear to hide the proper button-down behaviour (e. g. you push a button and it visually changes states) anyways.

EDIT: Never mind. I seem to have imagined things last night. The list form control is just as laggy as all others.

It's a bit hackish but should work for now:

docs.google.com/file/d/0B4HbmIw0kk7FNDdTeFNkVERWd0k/edit

I'd appreciate any help you guys can give in fixing the horizontal offset.

I would also be interested in a possible explanation on why "Sprite2.X-Button.Width" inside Node Webkit will get rid of the vertical offset while Google Chrome will require me to add a "-2" to the formula.