[Webkit-unassigned] [Bug 67109] [EFL] Weak scroll feature

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=67109





--- Comment #3 from Kamil Blank <k.blank at samsung.com>  2011-08-30 03:31:02 PST ---
(In reply to comment #2)
> The API needs some love IMO.
> 
>  * ewk_frame_scroll_add now seems to have a complete different code path depending on whether weak scrolling is enabled, and one of the code paths now relies on ewk_view (so far ewk_frame calls ewk_view as little as possible, usually only to propagate signals). It's a bit hard to follow the code with those 1, 2 and 3-letter variables with similar names.

I followed WebKit-EFL convention when choosing names of variables:
vw, vh - viewport
sx sy - scroll
fw, fh - frame
sdx, sdy - scroll delta

>  * It was not clear at first sight what ewk_frame_weak_scroll_moving_viewport_get was supposed to do.

Do you mean lack of comments or the function's name could be better?
I guess if you look at it as a part of weak scroll feature and you realize how this feature works it's quite understandable but of course I'm ready to improve it if necessary :)

>  * How is one expected to use this API in an application?

It's dedicated to be used during panning to avoid processing many scroll requests following each other.
Typical scenario:
//start panning
ewk_frame_weak_scroll_enabled_set(..., EINA_TRUE) - from now on only viewport will be moved, no scroll actions
ewk_frame_scroll_add(...)
ewk_frame_scroll_add(...)
ewk_frame_scroll_add(...)
...
ewk_frame_scroll_add(...)
// finish panning
ewk_frame_weak_scroll_enabled_set(..., EINA_FALSE) - now all previous scroll requests will be processed by WebCore but EWK won't move viewport which was already done - to be clear, it'll be just 1 request contains sum of skipped requests. 

>  * The purpose of this code seems to be to queue scroll requests and do them all at once at some point. If the performance gains are worthwhile, doesn't it make sense to make this the only possible behavior? How about processing the scroll requests in the main loop?

It can't be used as natural behavior because during weak scroll some actions will be missed due to skipping scroll events passing into WebCore like repaints, java script code. Due to this reason I don't think it's possible to queue these requests in normal usage.
This feature is a kind of enhancement - just like fast mobile scrolling - but not for general use.

>  * Does any other port implement this? If so, might it be something to add to WebCore?

I don't know about other ports doing such things. Moreover it looks like a specific feature which can be used by EFL port which uses internal backing store.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.