fantastic5 — 2014-02-02T09:04:04-05:00 — #1
When i do mouse houver in cover or scroll down is too slow (in chrome).
Anyone know the problem?
paulob — 2014-02-02T09:38:25-05:00 — #2
Yes its the webkit filters which are known to slow the page down.
Either remove the filters or use them conservatively on the odd element and not on all those thumbnails.
fantastic5 — 2014-02-02T13:19:47-05:00 — #3
Thanks Paul, without -webkit-filter: brightness(1) contrast(1) saturate(1.3) works perfectly.
What you mean with this? "use them conservatively on the odd element and not on all those thumbnails.
paulob — 2014-02-02T17:10:25-05:00 — #4
I think the problem was that you used it on all those elements which slowed the page down so it really is an effect that you just want to use on one item perhaps. It may be that even one instance may slow the page down but I haven't done enough testing to find out yet
fantastic5 — 2014-02-03T09:18:13-05:00 — #5
Thanks. I solved my problem adding the properties in the images.
fantastic5 — 2014-02-03T15:48:25-05:00 — #6
I'm using this scroll:
But have a little delay from original scroll to scroll edited. There is possibility of removing that time? And see always scroll edited.
You can see scroll in my page.
paulob — 2014-02-04T16:49:17-05:00 — #7
pullo — 2014-02-05T01:44:13-05:00 — #8
I don't see any delay when I scroll your main content area.
Can you elaborate?
fantastic5 — 2014-02-05T07:56:11-05:00 — #9
Make Ctrl+R in home page and you see:
and after, you see this:
pullo — 2014-02-05T08:04:14-05:00 — #10
Ah, do you mean that a normal scroll bar is shown briefly, before the JS executes and transforms it into the custom version?
fantastic5 — 2014-02-05T08:19:19-05:00 — #11
pullo — 2014-02-05T15:43:43-05:00 — #12
What happens if you hide the normal scroll bars using CSS, by setting the following on the container:
Maybe then the JS will kick in and recreate them?
If not, you could remove the overflow declaration programatically before the main JS routine runs.